面试准备：MQ消息队列常见面试题汇总

1.为什么要使用消息队列？

简单来说就是：解耦、异步、削峰。
消息队列可以对系统异步功能进行剥离，减少功能耦合，提供开发效率；
消息队列可以削峰限流，确保下游消费者稳定运行。
参考：Java架构直通车——MQ应用场景与JMS规范

2.消息队列推、拉模式区别？

• push模式
  服务端主动发数据到客户端，这就需要服务端保存push状态（哪些客户端发送成功，哪些没有发送成功），push状态是集中保存在服务端的，负载均衡也由服务端进行统一处理。
• pull模式
  客户端主动从服务段（定时）拉取数据，这就需要客户端保存pull状态（以便在故障重启的时候恢复），pull状态是分散保存在客户端的，负载均衡由客户端之间做调配（比如使用zookeeper）。

kafka是通过一个提交日志记录的方式来存储消息记录，采用拉模式，而RabbitMQ则采用队列的方式，属于推模式。

3.消息队列有什么缺点？

系统可靠性降低，解耦后，多个系统通过消息中间件交互，消息中间件挂了整个系统就挂了；
系统开发复杂度提升，需要考虑消息的处理，包括消息幂等性（重复消费问题），消息保序性（一个订单多条消息问题），以及消息中间件本身的持久化和稳定性可靠性；
消息一致性问题，如果一个功能发给多个系统，要所有系统都执行成功才算成功时，需要确保一个功能多个消息的完整一致性；

4.消息如何保证幂等性？

参考：MQ 生产端可靠性投递和消费端幂等性保障方案
参考：Java架构直通车——幂等性接口设计

5.消息队列为什么会出现重复消费？

kafka实际上有个offset的概念，就是每个消息写进去，都有一个offset，代表他的序号，然后consumer消费了数据之后，每隔一段时间，会把自己消费过的消息的offset提交一下，代表我已经消费过了，下次我要是重启啥的，你就让我继续从上次消费到的offset来继续消费吧。

但是凡事总有意外，比如我们之前生产经常遇到的，就是你有时候重启系统，看你怎么重启了，如果碰到点着急的，直接kill进程了，再重启。这会导致consumer有些消息处理了，但是没来得及提交offset，尴尬了。重启之后，少数消息会再次消费一次。

6.消息如何保证可靠性？

参考：MQ 生产端可靠性投递和消费端幂等性保障方案

7.如何保证消息顺序？

• 对于activeMQ，可以通过exclusive方式让一个queue始终被一个consumer消费；或者messageGroup方式；
• 对于rabitMQ， 一个queue对应一个consumer才行，多个consumer对应一个queue就容易错乱；
• 对于kafka，partition的消息是保序的。然后它强制要求一个partition只能投递给同组内的一个consume（即partition出只能有一个consumer，不能投递给同组内两个consumer，只是同组内的consumer却可以消费多个partition），所以不存在多个消费者错乱的问题。然后生产者可以设定一个key，同一个key的可以发送到同一个partition中，这样同一个key的消息在partition中是保序；
  如果kafka在消费端开启多线程,也会出现乱序。可以在消费端加队列，按照业务保序增加内存队列，这样队列中的消息与partition中顺序是一致的，然后多线程从队列中取数据，每次取一个完整顺序的消息进行处理即可。

8.消息队列积压怎么办

消息发送主要涉及三方:producer/consumer/broker,所以发生消息积压要从这三方来看。

• 发生消息积压后，producer端服务降级，关闭一些非核心业务，减少消息的产生。
• 扩容consumer实例，注意扩容后必须同步扩容主题中的分区（也叫队列）数量，确保 Consumer 的实例数和分区数量是相等的，因为在队列中的消费是单线程的，如果只扩容了consumer实例，没有扩容队列数量，则不会有效果的。
• 其实不用太关注消息队列，因为消息队列本身的处理能力要远远大于业务系统的处理能力。主流消息队列的单个节点，消息收发的性能可以达到每秒钟处理几万至几十万条消息的水平，还可以通过水平扩展 Broker 的实例数成倍地提升处理能力。

9.Kafka架构？

参考：Kafka概述

10.RabbitMQ架构？

参考：Java架构直通车——RabbitMQ集群架构模式