手机网站设计字体多大,沧州做网站的公司,肇庆网站制作策划,吉首市建设局官方网站消息中间件篇
RabbitMQ
如何保证消息不丢失
面试官#xff1a; RabbitMQ如何保证消息不丢失
候选人#xff1a;
嗯#xff01;我们当时MYSQL和Redis的数据双写一致性就是采用RabbitMQ实现同步的#xff0c;这里面就要求了消息的高可用性#xff0c;我们要保证消息的不…消息中间件篇
RabbitMQ
如何保证消息不丢失
面试官 RabbitMQ如何保证消息不丢失
候选人
嗯我们当时MYSQL和Redis的数据双写一致性就是采用RabbitMQ实现同步的这里面就要求了消息的高可用性我们要保证消息的不丢失。主要从三个层面考虑
第一个是开启生产者确认机制确保生产者的消息能到达队列如果报错可以先记录到日志中再去修复数据
第二个是开启持久化功能确保消息未消费前在队列中不会丢失其中的交换机、队列和消息都要做持久化
第三个是开启消费者确认机制为auto由spring确认消息处理成功后完成ack当然也需要设置一定的重试次数我们当时设置了3次如果重试3次还没有收到消息就将失败后的消息投递到异常交换机交由人工处理
消息的重复消费问题如何解决的
面试官 RabbitMQ消息的重复消费问题如何解决的
候选人
嗯这个我们还真遇到过是这样的我们当时消费者设置了自动确认机制当服务还没来得及给MQ确认的时候服务宕机了导致服务重启之后又消费了一次消息。这样就重复消费了
因为我们当时处理的支付订单 | 业务唯一标识它有一个业务的唯一标识我们再处理消息时先到数据库查询一下这个数据是否存在如果不存在说明没有处理过这个时候就可以正常处理这个消息了。如果已经存在这个数据了就说明消息重复消费了我们就不需要再消费了
面试官 那你还知道其他的解决方案吗
候选人
嗯我想想~
其实这个就是典型的幂等的问题比如redis分布式锁、数据库的锁都是可以的
死信交换机
面试官 RabbitMQ中死信交换机RabbitMQ延迟队列有了解过嘛
候选人
嗯了解过
我们当时的xx项目有一个xx业务需要用到延迟队列其中就是使用RabbitMQ来实现的。
延迟队列就是用到了死信交换机和TTL消息存活时间实现的。
如果消息超时为消费就会变成死信在RabbitMQ中如果消息成为死信队列可以绑定一个死信交换机在死信交换机上可以绑定其他队列在我们发消息的时候可以按照需求指定TTL的时间这样就实现了延迟队列的功能了。
我记得RabbitMQ还有一种方式可以实现延迟队列在RabbitMQ中安装一个死信插件这样更方便一些我们只需在声明交换机的时候指定这个就是死信交换机然后在发消息的时候直接指定超时时间就行了相对于死信交换机TTL省略了一些步骤
消息堆积怎么解决
面试官 如果有100万消息堆积在MQ如何解决
候选人
我在实际的开发中没遇到过这种问题不过如果发生了堆积的问题解决方案也有很多的
第一提高消费者的消费能力可以使用多线程消费任务
第二增加更多消费者提高消费速度使用工作队列模式设置多个消费者消费同一个队列中的消息
第三扩大队列容积提高堆积上限
可以使用RabbitMQ惰性队列惰性队列的好处主要是
①接收到消息后直接存入磁盘而非内存
②消费者要消费消息时才会从磁盘中读取并加载到内存
③支持百万条的消息存储
高可用机制
面试官 RabbitMQ的高可用机制有了解过嘛
候选人
嗯熟悉的~
我们当时项目在生产环境下使用的集群当时搭建的是镜像集群使用了3台机器。
镜像队列结构是一主多从所有操作都是主节点完成然后同步给镜像节点如果主节点宕机后镜像节点会替代成新的节点不过在主从同步完成前主节点就已宕机可能出现数据丢失
面试官 那出现丢数据怎么解决呢
候选人
我们可以采用仲裁队列与镜像队列一样都是主从模式支持主从数据同步主从同步基于Raft协议强一致。
并且使用起来也非常简单不需要额外的配置在声明队列的时候只要指定这个是仲裁队列即可
Kafka
如何保证消息不丢失
面试官 Kafka是如何保证消息不丢失
候选人
嗯这个保证机制很多在发送消息到消费者接收消息在每个阶段都有可能会丢失消息所以我们解决的话也是从多个方面考虑
第一个是生产者发送消息的时候可以使用异步回调发送如果发送消息失败我们可以通过回调获取失败后的消息信息可以考虑重试或记录日志后边再做补偿都是可以的。同时在生产者这边还可以设置消息重试有的时候是由于网络抖动的原因导致发送不成功就可以使用重试机制来解决
第二个在broker中消息有可能会丢失我们可以通过kafka的复制机制来确保消息不丢失在生产者发送消息的时候可以设置一个acks就是确认机制。我们可以设置参数为all这样的话当生产者发送消息到了分区之后不仅仅只在leader分区保存确认在follwer区分也会保存确认只有当所有的副本都保存确认以后才算是成功发送了消息所以这样设置就很大程度保证了消息不会在broker丢失
第三个是有可能在消费者端丢失消息kafka消费消息都是按照offset进行标记消费的消费者默认是自动按期提交已经消费的偏移量默认是每隔5s提交一次如果出现重平衡的情况可能会重复消费或丢失数据。我们一般都会禁用掉自动提交偏移量改为手动提交当消费成功以后再报告给broker消费的位置这样就可以避免消息丢失和重复消费了
面试官 Kafka中消息的重复消费问题如何解决的
候选人
kafka消费消息都是按照offset进行标记消费的消费者默认是自动按期提交已经消费的偏移量默认是每隔5s提交一次当消费成功以后再报告给broker消费的位置这样就可以避免消息丢失和重复消费了
为了消息的幂等我们也可以设置唯一主键来进行区分或者是加锁数据库的锁或者是redis分布式锁都能解决幂等的问题
如何保证消息的顺序性
面试官 Kafka是如何保证消费的顺序性
候选人
kafka默认存储和消费消息是不能保证顺序性的因为一个topic数据可能存储在不同的分区中每个分区都有一个按照顺序的存储的偏移量如果消费者关联了多个分区不能保证顺序性
如果有这样的需求的话我们是可以解决的把消息都存储在同一个分区下就行了有两种方式都可以进行设置第一个是发送消息时指定分区号第二个是发送消息时按照相同的业务设置相同的key因为默认情况下分区也是通过key的hashcode值来选择分区的hash值如果一样的话分区肯定也是一样的
高可用机制
面试官 Kafka的高可用机制有了解过嘛
候选人
嗯主要是有两个层面第一个是集群第二个是提供了复制机制
Kafka集群指的是由多个broker实例组成即使某一台宕机也不耽误其他broker继续对外提供服务
复制机制是可以保证kafka的高可用的一个topic有多个分区每个分区有多个副本有一个leader其余的是follower副本存储在不同的broker中所有的分区副本的内容都是相同的如果leader发生故障时会自动将其中一个follower提升为leader保证了系统的容错性、高可用性
面试官 解释一下复制机制中的ISR
候选人
ISR的意思是in-sync replica就是需要同步复制保存的follower
其中分区副本有很多的follower分为了两类一个是ISR与leader副本同步保存数据另外一个普通的副本是异步同步数据当leader挂掉之后会优先从ISR副本列表中选取一个作为leader因为ISR是同步保存数据数据更加的完整一些所以优先选择ISR副本列表
数据清理机制
面试官 Kafka的数据清理机制了解过嘛
候选人
嗯了解过~~
Kafka中topic的数据存储在分区上分区如果文件过大会分段存储segment
每个分段都在磁盘上以索引(xxxx.index)和日志文件(xxxx.log)的形式存储这样分段的好处是第一能够减少单个文件内容的大小查找数据方便第二方便kafka进行日志清理。
在kafka中提供了两个日志的清理策略
第一、根据消息的保留时间当消息保存的时间超过了指定的时间就会触发清理默认是168消失7天
第二、根据topic存储的数据大小当topic所占的日志文件大小大于一定的阈值则开始删除最久的消息。这个默认是关闭的
这两个策略都可以通过kafka的borker中的配置文件进行设置
高性能的设计
面试官 Kafka中实现高性能的设计有了解过嘛
候选人
Kafka 高性能是多方面协同的结果包括宏观架构、分布式存储、ISR数据同步、以及高效的利用磁盘、操作系统特性等。主要体现有这么几点
消息分区不受单台服务器的限制可以不受限的处理更多的数据
顺序读写磁盘顺序读写提升读写效率
页缓存把磁盘中的数据缓存到内存中把对磁盘的访问变为对内存的访问
零拷贝减少上下文切换及数据拷贝
消息压缩减少磁盘IO和网络IO
分批发送将消息打包批量发送减少网络开销
