activemq消息丢失和重复消费_如何处理消费过程中的重复消息?

在消息传递中,由于重试可能导致重复消息,对使用消息队列的系统造成数据错误。大部分消息队列如RocketMQ、RabbitMQ、Kafka提供At least once服务质量,允许少量重复消息。解决重复消息的方法是让消费端操作具有幂等性,确保多次执行对系统影响相同。实现幂等性可通过数据库唯一约束、设置数据更新前置条件或记录并检查操作。大部分消息队列不采用Exactly once服务质量,因为即使做到Exactly once,consumer仍需处理幂等性问题以防止重复消费。

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

2a1fedd1cbb314b6ff0cd28f3e3516c5.png

在消息传递过程中,如果出现传递失败的情况,发送方会执行重试,重试的过程中就有可能会产生重复的消息。对使用消息队列的业务系统来说,如果没有对重复消息进行处理,就有可能会导致系统的数据出现错误。

比如说,一个消费订单消息,统计下单金额的微服务,如果没有正确处理重复消息,那就会出现重复统计,导致统计结果错误。

你可能会问,如果消息队列本身能保证消息不重复,那应用程序的实现不就简单了?那有没有消息队列能保证消息不重复呢?

消息重复的情况必然存在

在 MQTT 协议中,给出了三种传递消息时能够提供的服务质量标准,这三种服务质量从低到高依次是:

  • At most once: 至多一次。消息在传递时,最多会被送达一次。换一个说法就是,没什么消息可靠性保证,允许丢消息。一般都是一些对消息可靠性要求不太高的监控场景使用,比如每分钟上报一次机房温度数据,可以接受数据少量丢失。
  • At least once: 至少一次。消息在传递时,至少会被送达一次。也就是说,不允许丢消息,但是允许有少量重复消息出现。
  • Exactly once:恰好一次。消息在传递时,只会被送达一次,不允许丢失也不允许重复,这个是最高的等级。

这个服务质量标准不仅适用于 MQTT,对所有的消息队列都是适用的。我们现在常用的绝大部分消息队列提供的服务质量都是 At least once,包括 RocketMQ、RabbitMQ 和 Kafka 都是这样。也就是说,消息队列很难保证消息不重复。

说到这儿我知道肯定有的同学会反驳我:“你说的不对,我看过 Kafka 的文档,Kafka 是支持 Exactly once 的。”我在这里跟这些同学解释一下,你说的没错,Kafka 的确是支持 Exactly once,但是我讲的也没有问题,为什么呢?

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值