使用RabbitMQ最终一致性方案，一定要保证可靠消息
以下四种情况是消息队列在分布式情况下保证消息可靠的常见问题；
1、消息发送出去，由于网络问题没有抵达服务器
解决：
（1）做好容错方法（try-catch），发送消息可能会网络失败，失败后要有重试机制，可记录到数据库，采取定期扫描重发的方式；
（2）做好日志记录，每个消息状态是否都被服务器收到都应该记录；
（3）做好定期重发，如果消息没有发送成功，定期去数据库扫描未完成的消息进行重发；
2、消息抵达Broker，Broker要将消息写入磁盘（持久化）才算成功。此时Broker尚未持久化完成，宕机；
解决：
publisher也必须加入确认回调机制，确认成功的消息，修改数据库消息状态；
3、自动ACK状态下，消费者收到消息，但没来得及消费就宕机了；
解决：
一定开启手动ACK，消费成功才移除，失败或者没来得及处理就noAck并重新入队；
RabbitMQ的三种确认机制：
（1）Publish——》Broker：/confirm/iCallback
（2）Exchange——》Queue：returnCallback
（3）Queue——》Client：Ack机制
1、消息消费成功，事务已经提交，ack时，机器宕机，导致没有ack成功，Broker的消息重新由unack变为ready，并发送给其他消费者；相当于锁库存被消费了两遍，即库存扣了两遍；
2、消息消费失败，由于重试机制，自动又将消息发送出去；
3、成功消费，ack时宕机，消息由unack变为ready，Broker又重新发送；
解决：
（1）消费者的业务消费接口应该设计成幂等的，比如扣库存要有工作单的状态标志；
（2）使用防重表（redis/mysql），发送消息每一个都有业务的唯一标识，处理过就不用处理
（3）RabbitMQ每一个消息都有redelivered字段，可以获取是否是被重新投递过来的，而不是第一次投递过来的。
消息积压1、消费者宕机积压，没有人去消费了，但依旧源源不断生产消息，导致消息积压；
2、消费者消费能力不足积压；
3、发送者发送给流量太大，如秒杀业务
解决：
（1）上线更多的消费者（如：库存服务），进行正常消费
（2）上线专门的队列消费服务，将消息先批量取出来，记录数据库，离线慢慢处理。
消息顺序RabbitMQ：一个queue，多个consumer，这不明显乱了，但因为不同消费者的执行速度不一致，在存入数据库后，造成顺序不一致的问题
解决：在消息队列中，一个queue中的数据，一次只会被一个消费者消费掉
拆分多个queue，每个queue一个consumer，就是多一些queue而已，确实是麻烦，或者就是一个queue，但是对应一个consumer，然后这个consumer内部用内存队列做排队，然后分发给底层不同的worker来处理。
