河北网站建设搭建百度的企业网站
1.RabbitMQ如何保证消息不丢失
- 开启生产者确认机制，确保生产者的消息能到达队列
- 开启持久化功能，确保消息未消费前在队列中不会丢失（交换机，队列，消息都需要开启持久化功能）
- 开启消费者确认机制为auto,由spring确认消息处理成功后完成ack
- 开启消费者失败重试机制（比如设置最多重试次数为3），多次重试失败后将消息投递到异常交换机，交由人工处理
2.说一说消息重复消费问题
- 导致消息重复的原因一般是设置了消息重试机制。但是由于网络抖动或者消费者挂了，导致消息没有被确认还在消息队列中，然后重复发送导致的
- 解决这个问题最好的方法是用唯一标识去处理，消费时候去数据库查一下，如果这个消息的唯一标识已经存在了，那么就是已经消费过了
- 其次是可以用redis分布式锁或者数据库锁（乐观锁，悲观锁）去解决。
3.说一说RabbitMQ中死信交换机(RabbitMQ延迟队列)
- 延迟队列一般的应用场景有超时订单、限时优惠、定时发布等
- 延迟队列是用到了死信交换机和TTL(消息存活时间)实现的
- 消息超时未消费就会变成死信（死信的其他情况：拒绝被消费，队列满了）
- 死信会被放到死信交换机里面，由死信交换机绑定的队列去消费（死信交换机在创建消息队列的时候就需要去指定死信交换机是谁）。
- 延迟队列插件也可以实现延迟队列（DelayExchange），发送消息时，添加x-delay头，值为超时时间
4.消息堆积问题如何解决
- 增加更多的消费者，提高消费速度
- 在消费者内使用线程池，提高消息处理速度
- 使用惰性队列，把消息放在磁盘里面，获得更高的存储上限。但是这样受限于磁盘IO，时效性会降低。
5.RabbmitMq怎么解决高可用
- 采用镜像模式搭建集群，镜像的结构是一主多从，所有操作时主节点完成，之后同步给从节点。如果主节点宕机，镜像节点会成为新的主节点。但是如果在同步之前主节点就挂了，可能会造成数据丢失。
- 采用仲裁队列解决镜像集群可能出现的数据丢失问题，仲裁队列和镜像队列一样都是主从模式，主从同步基于Raft协议，强一致。且使用起来也很方便，只要声明队列的时候表示是仲裁队列即可。
Raft协议： Raft是一种旨在简化实现和理解的分布式系统共识算法。其核心在于通过选举一个“领导者”来处理客户端请求，并将这些请求作为日志条目复制到其他“跟随者”节点，以确保所有节点数据的一致性。每个节点在任一时刻都处于三种状态之一：领导者、跟随者或候选人（用于选举新领导者）。Raft通过任期（逻辑时钟）和严格的日志复制规则保证了即使部分节点故障，系统仍能保持一致性和可用性。简而言之，Raft使分布式系统能够高效、可靠地达成共识，确保数据一致性。
6.Kafka如何保证消息不丢失
需要从三个层面去解决这个问题：
- 生产者发送消息到Brocker丢失
– 设置异步发送，发送失败使用回调进行记录或重发
– 失败重试，参数配置，可以设置重试次数 - 消息在Brockert中存储丢失
发送确认acks,选择all,让所有的副本都参与保存数据后确认，但是这样效率最低，可以设置为1，只要集群首领收到消息，即可发送消息确认。 - 消费者从Brocker接收消息丢失
– 关闭自动提交偏移量，开启手动提交偏移量
– 提交方式，最好是同步+异步提交
7.Kafka中消息的重复消费问题如何解决的
- 关闭自动提交偏移量，开启手动提交偏移量
- 提交方式，最好是同步+异步提交
- 使用幂等方案
8.Kafka消费如何保证顺序性
在kafka中，一个topic的数据存储在不同的分区中，每个分区都有按照顺序存储的偏移量，这就导致如果一个消费者关联了多个分区，分区就不能保证连续性。
解决：
- 发送消息时指定分区号，将需要顺序消费的消息全部发送到同一分区
- 发送消息时，按照业务设置相同的key，核心依然是将需要顺序消费的信息全部发送给同一分区，以此保证消息消费的顺序性
9.Kafka高可用机制了解过吗
Kafka高可用机制主要体现在两个方面
集群：
一个kafka集群由多个broker3实例组成，即使某一台宕机，也不耽误其他broker继续对外提供服务
复制机制：
- 一个topic有多个分区，每个分区有多个副本，有一个leader,其余的是follower,副本存储在不同的broker中
- 所有的分区副本的内容是都是相同的，如果leader发生故障时，会自动将其中一个follower提升为leader,保证了系统的容错性、高可用性
- 分区副本分为两类
– 一类是ISR，需要同步保存数据的副本，leader挂掉之后，会优先从ISR选取，一般建议设置一到两个，因为是同步复制，多了影响效率
– 一类是普通副本，异步同步数据
10.说一说Kafka的数据清理机制
需要先说明kafka存储结构
- Kafka中topic的数据存储在分区上，一个分区如果过大就会进行分段存储，及一个分区下可能会存在多个文件段，一个文件段被称为segment
- 每个文件段都对应了三个日志文件：索引文件（xxx.index）、数据文件（xxx.log）、时间索引文件（xxx.timeindex）。每段的文件名相同，后缀不同
- 分段的好处是，第一能够减少单个文件内容的大小，查找数据方便，第二方便kafka进行日志清理。
再说明kafaka的两个日志的清理策略
- 根据消息的保留时间，当消息保存的时间超过了指定的时间，就会触发清理，默认是168小时（7天)
- 根据topic存储的数据大小，当topic所占的日志文件大小大于一定的阈值，则开始删除最久的消息。（默认关闭）
11.说一说kafka的高性能设计
- 消息分区： 不受单台服务器的限制，可以不受限的处理更多的数据
- 顺序读写： 磁盘顺序读写，提升读写效率（文件内容是追加写入的）
- 页缓存： 把磁盘中的数据缓存到内存中，把对磁盘的访问变为对内存的访问
- 零拷贝： 减少上下文切换及数据拷贝
- 消息压缩：减少磁盘IO和网络O
- 分批发送：将消息打包批量发送，减少网络开销
零拷贝
普通拷贝：
- 从硬件中的磁盘文件到内核空间的页缓存一次
- 从内核空间的页缓存到用户空间的kafka一次
- 从用户空间的kafka到内核空间的Socket缓冲区一次
- 从内核空间的Socket缓冲区到硬件中的网卡一次
共进行了四次拷贝
零拷贝：
- 从硬件中的磁盘文件到内核空间的页缓存一次
- 从内核空间的页缓存到硬件中的网卡一次
共进行了两次拷贝