消息丢失
消息发送出去，由于网络问题没有抵达服务器
1.做好容错方法(try-catch)，发送消息可能会网络失败，失败后要有重试机制，可记录到系统数据库，采用定期扫描重发的方式。
2.做好日志记录，每个消息状态是否都被服务器收到都应该被记录
3.做好定期重发，如果消息没有发送成功，定期去数据库扫描未成功的消息进行重发
消息抵达Broker，Broker要将消息写入磁盘才算成功，此时Broker尚未持久化完成，宕机。
publisher必须加入确认回调机制，确认成功的消息，修改数据库消息状态
自从ACK状态下，消费者收到消息，但没来得及消费便宕机
一定开启手动ACK，消息成功才移除，失败或者没来得及处理就noACK并重新入队。
消息重复
消息消费成功，事务已经提交，ack时，机器宕机，导致没有ack成功，Broker的消息重新由unack-> ready，并发送给其他消费者。
消息消费失败，由于重试机制，自动又将消息发送出去。
成功消费，ACK时宕机，消息由unack变为ready，Broker又重新发送
消费者的业务消费接口应该设计成幂等性的，比如扣库存工作单的状态标志
使用 防重表(redis, mysql) 唯一索引，发送消息每一个都有业务的唯一标识，处理过就不用再处理。
RabbitMQ的每一个消息都有redelivered字段，可以获取消息是否是被重新投递的。
消息积压
消费者宕机积压
消费者消费能力不足积压
发送者发送流量太大
上线更多的消费者，进行正常消费。
上线专门的队列消费服务，将消息先批量取出来，记录数据库，离线慢慢处理。