问题背景：学生向老师请教问题。如果学生A正在向老师请教问题，那么后面的学生依次排队等候，直到轮到自己请教问题。这样的模式会使整个系统的效率较低，学生排队等待时间太久，而且排队学生过多，老师也会忙不过来。引入消息队列后，即右图的班长，班长负责将所有学生的问题汇总，即学生按照固定的格式将请教的问题写在纸上，并按照先后顺序交给班长，即可做自己的事情去了。老师可以从班长那里依次获取问题，并逐一进行解答。
解决的问题：
（1）学生不需要直接面对老师，学生和老师通过班长进行通信，即解决了耦合调用的问题。
（2）老师无需当场回答问题，可以按照自己的处理进度依次回答问题，即解决了异步通信的问题。
（3）当提问的学生数量过多，通过班长（MQ）可以抵御洪峰流量，达到保护主业务的目的。
总结：
（1）解耦
系统的耦合性越高，容错性就越低。以电商应用为例，用户创建订单后，如果耦合调用支付系统，库存系统，物流系统，任何一个子系统出了故障或者因为升级等原因暂时不可用，都会造成下单操作异常，影响用户使用体验。
在使用消息队列（MQ）解耦后，系统的耦合性就会提高了。比如物流系统发生故障，需要几分钟才能修复，在这段时间内，物流系统要处理的数据被缓存到消息队列中，用户的下单操作正常完成。当物流系统恢复后，补充处理存在消息队列中的订单消息即可，终端系统感知不到物流系统发生过几分钟故障。
（2）异步
A系统接收一个请求，需要在自己本地写入数据库，还需在B,C,D三个系统中写入数据库，如采用直接调用方式，最终的请求总延时非常高，用户体验感很差。如果使用了消息队列（MQ），系统A接收到请求后，只需连续发送3条消息到消息队列（MQ）中，即可返回响应给用户，而无须等待B,C,D三个系统的响应结果。
一个系统跟另一个系统之间进行通信的时候，假如系统A希望发送一个消息给系统B，让他去处理，但是系统A不关注B到底怎么处理或者有没有处理好，所以系统A将消息发送给消息队列（MQ），然后就不管这条消息的“死活”了，接着B从消息队列里取出消息进行处理即可。至于怎么处理，是否处理完毕，什么时候处理，都是系统B的事儿，与系统A无关。
（3）削峰
应用系统如果遇到系统请求流量的瞬间猛增，有可能将系统压垮。有了消息队列可以将大量请求缓存起来，分散到很长一段时间处理，这样可以大大提高系统的稳定性和用户体验。
流量削峰的经济考量：
业务系统正常时段的QPS如果是1000，流量最高峰时10000，为了应对流量高峰配置高性能的服务器显然不划算，这样可以使用消息队列对峰值流量削峰
小结：
优点：
缺点：
（1）系统可用性降低
系统引入的外部依赖越多，系统稳定性越差。一旦消息队列（MQ）宕机，就会对业务造成影响。
如何保证MQ的高可用？
（2）系统复杂度提高
MQ的加入大大增加了系统的复杂度，以前系统间是同步的远程调用，现在是通过MQ进行异步调用。
消息丢失怎么办？
重复消息怎么处理？
如何保证消息传递的顺序性？
（3）一致性问题
A系统处理完业务，通过MQ给B,C,D三个系统发消息数据，如果B系统，C系统处理成功，D系统处理失败。
如何保证消息数据处理的一致性？
项目中引入MQ导致系统的可用性降低，面试官想知道的是面试者针对可用性降低的思考和解决思路。
（1）RabbitMQ高可用---镜像集群
（2）RocketMQ高可用---双主双从
消息丢失的原因：
情况一：消息生产者没有成功发送到MQ。
情况二：消息发送给MQ，但是MQ宕机导致内存中的消息数据丢失。
情况三：消费者获取到消息，但消费者还没有来得及处理宕机了，但此时MQ中的消息已经删除，消费者重启后不能再消费之前的消息。
确保消息不丢失的方案：
总结：
消息丢失的原因：
如何保证消息不丢失：
消息重复的根本原因是网络不可达。
发送时消息重复
当一条消息已被成功发送到服务端，此时出现网络闪断，导致服务端对客户端应答失败。如果此时生产者意识到消息发送失败并尝试再次发送消息，消费者后续会收到两条内容相同的消息。
消费时消息重复
消息消费的场景下，消息已投递到消费者并完成业务处理，当消费方给MQ服务端反馈应答的时候网络闪断。为了保证消息至少被消费一次，MQ服务端在网络恢复后再次尝试投递之前已被消费方处理过的消息，此时消费者就会收到两条内容相同的消息。
解决方案：
消息的顺序性消费：
消息有序指的是按照消息的发送顺序来消费，例如一笔订单产生了3条消息，分别是订单创建，订单付款，订单完成。消费时，要按照顺序依次消费才有意义。与此同时，多笔订单之间有时可以并行消费的。
局部顺序消费：
本质上讲，分布式事务就是为了保证不同数据库的数据一致性。
消息的发送方在处理完自己的业务后，将消息首先保存到本地，并将消息状态置为1（代表消息未处理），接下来将消息发送到消息队列（MQ）中，消息的消费方监听到消息后，为了保证消息的幂等性（消息不被重复消费），首先判断是否为重复消息，若消息未被执行，则执行相应的业务逻辑，并将消息记录到本地数据库中，最后向MQ发送消息，以更改发送方消息的状态（将消息的状态置为2）。
特殊情况：若消息在发送方执行成功，但是在消息的消费方执行失败，此时两边业务系统的数据不一致。消息发送方的定时任务定时扫描消息发送方的本地消息表中teye=1（未处理的消息）的消息，并将该消息继续发送到消息队列（MQ）中，以供消费方重新消费。若消息未被成功消费，则定时任务一直发送消息到MQ中，这样可以保证所有消息一定会被消费。
总结：
（1）消息发送方：
（2）消息消费方：
