目录
为什么要使用消息队列
目前我所在公司是一家互联网电商，开发电商小程序，我们订单的模块就用到了RabbitMQ，那为什么我们要使用RabbitMQ呢？
- 无需担心订单接口是否异常，用户下订单直接把订单发送到消息队列去，返回下单成功，订单接口订阅消息队列，消费消息，保存订单~
- 解耦：多个系统（B，C，D）调用同一系统（A），多个系统严重耦合，引入消息队列，A发送消息至消息队列，BCD订阅消息队列，无需关心任何其他因素。
- 异步：若系统A接收到一个请求，需要在在自己的本地写库，又需要在BCD系统写库，传统方式，A -> B -> C -> D ，速度极慢。引入消息队列时，A在本地写库，同时把消息发送至消息队列中，BCD同时写入数据库，时间大大算短。
- 削峰：减少高峰期对服务器的压力。大量请求（5000条请求/s）访问系统时，若系统B每秒只能处理1000请求，那么系统B就会崩溃挂掉了。引入消息队列，这5000条请求发送到消息队列中，系统B “慢慢 ”的消费这些消息，减少了其对服务器的压力。
消息队列的缺点
凡事都有利弊。
- 系统可用性降低
消息队列一旦挂掉，下游的接口或者服务则无法得到消息，那么该模块就宕机了。。。- 系统复杂性提高
消息的重复消费，消息丢失，消息的顺序性等等。。。- 系统的一致性
由图二，本来是A，B，C，D都完成之后才会相应给用户操作成功，现引入Rabbit MQ之后，A操作成功就会相应给用户，若BCD其中有服务宕机或操作异常造成的数据问题。。。
各大消息队列的优缺点
如何保证RabbitMQ的高可用
镜像集群模式
要开启镜像集群模式，需要在后台新增镜像集群模式策略，也就是要求把queue中的元数据和消息同步到所有其他的MQ节点中，也可以指定同步到指定数量的节点。
好处： 任何一个MQ节点宕机了，都不会影响整个集群数据的完整性，因为剩下的其他未宕机的MQ节点都有queue的完整数据，当进行消息消费的时候，连接其他的服务器节点一样也能获取到数据。
缺点：性能开销大，因为需要整个集群内部同步所有实例的数据；无法线性扩容，因为每一个服务器中都包含整个集群服务节点中的所有数据，这样一旦单个服务器节点的容量满了就不容易对容量进行线性拓展。
如何保证消息的幂等性
可以结合redis，Set 来实现消息的幂等性
生产者每次发送消息都会给消息赋一个唯一值。消费者消费消息时，记录消息的唯一值，下次消费消息的时候来判断唯一值是否存在。以此保证消息的幂等性。
如何保证消息不被丢失
- 生产者
rabbitmq提供了回调函数机制，confirm模式，生产者发送一条消息至队列，队列回回调生产者告知消息是否发送成功，若发送失败，执行消息重发。- rabbitMQ
开启持久化机制，消息持久化至磁盘- 消费者
开启手动确认机制，当消息处理完之后，手动确认发送Ack至rabbitmq。acknowledge-mode: manual
如何保证消息的顺序性
期望对数据库进行的操作是，数据1 -> 数据2 -> 数据3，理性很丰富显示很骨干，实际的顺序 数据2 -> 数据1 -> 数据3，那么数据就乱了。
解决方式：
把需要顺序消费的消息发送到同一queue，让一个消费者来订阅需要顺序执行的queue
推荐阅读