消息队列常见面试题

1 选型
2 如何保证消息的消费顺序
3 如果解决重复消费问题
4 如何解决消息丢失问题

1.选型:
RabbitMQ: 采用队列模式(点对点模式),支持开发语言较多,
缺点: 性能较差,每秒几万到几十万的消息,消息一旦堆积性能急剧下降

RocketMQ: 采用订阅发布模式(所有订阅的消费者都会接收到消息),阿里出品,每秒能处理几十万的消息,能做到毫秒级响应,在意响应时延的采用RocketMQ,如金融系统和交易系统;
缺点: 小众化,兼容性没那么好;

kafka: 订阅发布模式,兼容性最好,设计上使用大量和批量思想,性能超好,消息处理速度每秒几十万条,但响应速度没那么好;
缺点: 异步和批量的设计,消息时延较高(攒一批,然后再发送),

ActiveMQ: 老牌开源队列, 性能较差,旧系统常见;

总结: 一般选kafka, 要求响应速度的选RocketMQ

2 如何保证消息的消费顺序
① 队列模式可以保证消费顺序,;
② 订阅模式无法保证消息顺序,如果要保证消费顺序,一个生产者对应一个消费者,每个实例一一对应;

kafka用来保证消息顺序的方式:
分区:  将每个主题划为多个分区,每个分区有唯一的标识符(分区号),每个分区中的消息按照写入顺序进行存储,
生产者发送顺序:   生产者将指定的消息发送至指定的分区,消息就会按照发送顺序被写入该分区中;
消费者消费顺序:  消费者以分区为单位进行消费,只消费自己所负责分区中的消息,

副本机制:   kafka通过副本机制提高可用性和容错性,一个领导者,其他为追随者,生产者将消息发送至领导者副本,消息将被复制到追随者副本,消费者只从领导者副本读取消息

3 如果解决重复消费问题
①重复投递, 生产者启用消息确认机制
②重复消费 消费者启用消息确认机制
③消费时采用幂等判断

4 如何解决消息丢失问题
生产阶段: 消息确认机制,发送完毕再确认
存储阶段: 配置broker参数, 在将消息写入磁盘后再给生产者返回确认消息;如果时集群至少将消息发送给两个以上的节点再给客户端返回确认消息;
消费阶段: 执行完所有业务逻辑再给kafka发送确认消息

kafka消息积压
设计:
①多个分区对应一个消费者时消费速度会变慢(反过来会浪费),最好 消费者数量=分区数
② 调整kafka参数: 缓存区大小,数据压缩,批次大小,等待时长
③ 消费者扩容增加消费速度

平时正常,然后紧急情况
① 临时扩容,增加消息容量,(增加机器,或者将消息导入一个新的更大的队列中)
② 找出消费端问题,恢复或提高消费能力