RabbitMQ小结（八）面试题
1.为什么你要使用消息队列？
1）解耦
缺点：
系统间耦合性太强，如图所示，如果D系统也要接入系统A则需要修改系统A的原有代码，过于麻烦。
优点：
将消息写入MQ，需要消息的系统可以自行从MQ处订阅，而系统A不需要修改源码。
2）异步
传统模式：
缺点：
存在部分非必要的业务代码以同步的方式运行，过于耗费时间。
中间件模式：
优点：
将消息写入MQ，非必要的业务代码可以以异步的方式运行，节省了运行时间。
3）削峰填谷
将高并发的请求，放入队列，消费方实现一个一个来，分散机器负载压力——需要加中间业务状态。
2.消息中间件的缺点？
- 消息中间件出现问题，系统可能会随之出现问题。因此，系统可用性降低。——服务监测管理、高可用部署(主从、分布式)、持久化补充…
- 系统复杂性增加:要多考虑很多方面的问题，比如一致性问题、如何保证消息不被重复消费，如何保证保证消息可靠传输。因此，需要考虑的东西更多，系统复杂性增大；——幂等校验(解决重复消费)、消息确认机制、重试机制(一致性)、事务使用(封装TransactionTemplate)…
3.RabbitMQ跟RocketMQ的区别？
RabbitMQ：
交换器——routingkey——队列
RocketMQ：
点对点模式(一个消息一个接收方)；
发布订阅模式(一个消息可以传递给多个接收方)；
4.各种消息中间件的区别？
5.如何防止消息丢失？
1) 生产者防止丢失：
-
发送确认：
confirm回调，确认exchange跟持久化成功。
Return回调，定位异常路由(未成功到达queue)的消息，做异常补发或其它处理(启用异常队列、持久化到其它存储做定时任务补充)。 -
开启强事务，使用RabbitMQ(二阶段提交)事务——不建议，效率低下。
2）消费方防止丢失：
- 手动消费确认，利用RabbitMQ重试机制+重试时间乘法器做异常补充——一定要对消费服务加上监控(日志监控、队列消息监控…)
- 手动确认，异常落库+定时任务补充消费+AOP异常捕获
- 拒绝消息，回死信，用死信做统一异常消费补充
3）常用解决方案：
发送方，发送消息，消息落库(或缓存)，默认消息发送失败，消息confirm回调，将记录的发送消息更改状态为发送成功，同时采用公共定时任务做发送异常消息补充操作。消费方，采用监控+异常重试+重试时间乘法器+死信队列+死信补充消费，保证消息消费不丢失；同时保证RabbitMQ自身的服务高可用性。
6.如何防止消息重复消费？
业务设计唯一区分，做幂等校验。
比如：订单支付——订单id——判断支付状态，如果已经支付，则直接返回成功，不做任何重复操作，消费成功。
如果无法区分，比如商品服务减少库存的一个操作，则消费方针对消费记录做日志表记录，然后根据业务唯一区分id，做记录查询，如果存在则不再继续消费，直接返回成功；
具体业务具体分析，可采取不一样的幂等校验策略。
7.如何实现RabbitMQ高可用？
镜像集群模式。
与普痛集群模式的主要区别：
无论queue的元数据还是queue中的消息都会同时存在与多个实例上
8.如何实现延迟消费？
死信队列——延迟消费
延迟消费插件
9.生产者消息发送confirm ack、Return回调到底该如何处理？
日志记录+监控告警
持久化数据库记录
重发
10.使用MQ的业务场景？
1）一个操作完成需要通知多服务
2）并发量高，访问数据库压力大，调整业务，排队操作
3）业务计算量大，不适合同步等待，采用异步消息处理
4）服务间调用，异步消息通知，达成状态最终一致性
