消息丢失、重复、积压
消息丢失
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、发送者发送流量太大
上线更多的消费者,进行正常消费
上线专门的队列消费服务,将消息先批量取出来,记录数据库,离线慢慢处理