消息丢失、重复、积压

消息丢失

1、消息发送出去因网络问题没抵达服务器

做好容错方法，使用try catch 发送消息，没发送成功的消息进行重试发送。每一个消息都做好日志记录，往数据库中创建一个mq_message表保存记录，定期扫描数据库，将失败的消息再发送一遍。

2、消息抵达broker，broker要将消息写入磁盘（持久化）才算成功。此时Broker尚未持久化完成，宕机。

publisher生产者发送消息后，setConfirmCallBack()>confirm()>服务器收到，加入确认回调机制，确认成功的消息，修改数据库消息状态。

3、自动ACK状态下。消费者收到消息，但没来得及消费然后宕机

一定开启手动ACK，消费成功才移除，失败或者没来得及处理就noAck并重新入队

1、做好消息确认机制（publisher, consumer[手动ACK]）

2、每一个发送的消息都在数据库做好记录。定期将失败的消息再次发送

消息重复

1、消息消费成功，事务已经提交，ack时，机器宕机。导致没有ack成功，broker的消息重新由unaced变为ready，并发送给其它消费者

2、消息消费失败，由于重试机制，自动又将消息发送出去（允许）

3、成功消费，ack时宕机，消息由unacked变为ready，broker又重新发送

​ 消费者的业务消费接口应该设计为幂等性的。

​ 使用防重表（redis/mysql），发送消息每一个都有业务的唯一标识，处理过就不用处理

​ rabbitMQ的每一个消息都有redelivered字段，可以获取是否是被重新投递过来的，而不是第一次投递过来的

消息积压

1、消费者宕机积压

2、消费者消费能力不足积压

3、发送者发送流量太大

​ 上线更多的消费者，进行正常消费

​ 上线专门的队列消费服务，将消息先批量取出来，记录数据库，离线慢慢处理