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