RabbitMQ 之消息丢失、积压、重复解决

本文探讨了如何保证消息的可靠性,针对消息丢失、重复和积压三种情况提出解决方案。针对消息丢失,建议采用重试机制、日志记录和确认回调;消息重复则通过幂等性设计和防重表来避免;消息积压时,可通过增加消费者、批量处理和离线服务来缓解。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

如何保证消息可靠性-消息丢失

在这里插入图片描述

  • 消息发送出去,由于网络问题没有抵达服务器。

    • 做好容错方法(try-catch),发送消息可能会网络失败,失败后要有重试机制,可记录到数据库,采用定期扫描重发的方式。
    • 做好日志记录,每个消息状态是否都被服务器收到都应该记录。
    • 做好定期重发,如果消息没有发送成功,定期去数据库扫描未成功的消息进行重发。
  • 消息抵达Broker,Broker要将消息写入磁盘(持久化)才算成功。此时Broker尚未持久化完成,宕机。

    • publisher 也必须加入确认回调机制,确认成功的消息,修改数据库消息状态。
  • 自动ACK的状态下。消费者收到消息,但没来得及消息然后宕机。

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

如何保证消息可靠性-消息重复

什么情况下出现消息重复:

  • 消息消费成功,事务已经提交,ack时,机器宕机。导致没有ack成功,Broker的消息重新由unack变为ready,并发送给其他消费者。
  • 消息消费失败,由于重试机制,自动又将消息发送出去。

解决方案:

  • 消费者的业务消费接口应该设计为幂等性的。要求消息体中必须要有一个bizId(对于同一业务全局唯一,如支付ID、订单ID、帖子ID等)作为去重和幂等的依据,避免同一条消息被重复消费。
  • 使用防重表(redis/mysql),发送消息每一个都有业务的唯 一标识,处理过就不用处理。
  • RabbitMQ的每一个消息都有redelivered字段,可以获取是否是被重新投递过来的,而不是第一次投递过来的。

如何保证消息可靠性-消息积压

什么情况下出现消息积压:

  • 消费者宕机积压。
  • 消费者消费能力不足积压。
  • 发送者发送流量太大

解决方案:

  • 上线更多的消费者,进行正常消费。
  • 上线专门的队列消费服务,将消息先批量取出来,记录数据库,离线慢慢处理。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值