消息队列面试题经常在Java面试中涉及，下面重点详解常见的消息队列面试题。
什么是消息队列?
消息队列就是Message Queue，本质就是一个保存消息的队列。
如下图所示：
消息队列有哪些？
常见的消息队列有：ActiveMQ、RocketMQ、Kafka、Pulsar、RabbitMQ等等。
如下图所示：
消息队列如何做技术选型？
1.中小型公司
中小型软件公司不如互联网公司，数据量没那么大，选消息中间件，应首选功能比较完备的，推荐RabbitMQ。
RabbitMQ的社区十分活跃，可以解决开发过程中遇到的bug，这点对于中小型公司来说十分重要。
2.大型公司
根据具体使用在：RocketMq和Kafka之间二选一，最后根据业务场景选择，如果有日志采集功能，首选kafka了，电商金融首选RocketMQ。
消息队列MQ应用场景
1.异步处理
举一个用户注册的例子，比如：用户注册成功后，系统需要发送注短信注册成功通知，以及赠送注册成功的积分。
1）同步
同步的总耗时：10ms+100ms+100ms=210ms
由于短信通知与增加积分为非核心流程，为了提升系统响应性能，从而我把它改造为异步。
2）异步
改造后就变成上图，用户注册后写入消息10ms左右立即返回成功给客户端，无需等待耗时较久的同步就可以返回，从而极大的提升了系统的吞吐量。
2.应用解耦
使用了消息队列后，消息的发送方和接收方并不需要彼此联系，也不需要受对方的影响即解耦。
典型的上下游解耦如下图所示：
3.流量削锋
这种场景中系统的峰值流量往往集中于一小段时间内，所以为了防止系统在短时间内的峰值流量冲垮，往往采用消息队列来削弱峰值流量，相当于消息队列做了一次缓冲。
如下图所示：
4日志处理
日志处理是指将消息队列用在日志处理中，比如Kafka的应用，解决大量日志传输的问题。
如下图所示：
消息队列的主要传输模式
主要包含两种：一个是点对点，一个是发布订阅模型。
1.点对点
点对点的特点：每个消息只有一个消费者（Consumer），即一旦被消费，消息就不再在消息队列中。
2.发布订阅
发布订阅模型包含三个角色：主题（Topic）、发布者（Publisher）、订阅者（Subscriber）。
如下图所示：
点对点和发布订阅的区别
点对点：生产者发送一条消息到队列，只有一个消费者能收到。
发布订阅：和点对点方式不同，发布消息可以被所有订阅者消费。
消息队列的主要消息协议
1.JMS (Java Message Service)
- Sun公司早期提出的消息标准，为Java应用提供消息服务，规定了 Java 使用消息服务的 API
- 定义：JMS所定义的是API规范
- 跨语言跨平台：不支持
- 消息模型：点对点和发布-订阅
- 典型实现：ActiveMQ
2.AMQP(Advanced Message Queuing Protocol)
- 高级消息队列协议，是应用层协议的一个开放标准，为面向消息的中间件设计
- 定义： AMQP不从API层进行限定，而是直接定义网络交换的数据格式
- 跨语言跨平台：天然支持
- 消息模型：通过路由机制详细划分
- 典型实现：RabbitMQ
消息队列整体架构
上图为整体架构，会涉及三类角色：
1）Producer 消息生产者：负责产生和发送消息到 Broker；
2）Broker 消息处理中心：负责消息存储、确认、重试等，一般其中会包含多个 queue；
3）Consumer 消息消费者：负责从 Broker 中获取消息，并进行相应处理；
设计Broker主要考虑？
Broker作为消息的处理中心，从设计上主要会包含：
1消息的转储
在更合适的时间点投递，或者通过一系列手段辅助消息最终能送达消费机。
2.规范一种范式和通用的模式
以满足解耦、最终一致性、错峰等需求。
3.消息转发机制
其实简单理解就是：一个消息转发器，把一次RPC做成两次RPC。发送者把消息投递到broker，broker再将消息转发一手到接收端。
总结起来就是两次RPC加一次转储，如果要做消费确认，则是三次RPC。
以上就是常见的消息队列面试题及答案，更多的Java面试题及答案，请查看：1000+Java面试题及答案详解。
作者简介
陈睿|mikechen，10年+大厂架构经验，就职于阿里巴巴、淘宝、百度等一线互联网大厂。
关注作者「mikechen」公众号，获取更多技术干货！
