消息队列高手课
李玥
美团高级技术专家
52199 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 42 讲
进阶篇 (21讲)
消息队列高手课
15
15
1.0x
00:00/00:00
登录|注册

06 | 如何处理消费过程中的重复消息?

记录并检查操作
为更新的数据设置前置条件
利用数据库的唯一约束
实现幂等操作的方法
幂等操作的特点
幂等性概念
幂等性解决重复消息问题
Kafka的"Exactly once"
At least once
Exactly once
At least once
At most once
消费代码处理重复消息
消息队列的服务质量
三种服务质量标准
为什么大部分消息队列选择At least once
消息传递过程中的重复消息问题
如何处理消费过程中的重复消息

该思维导图由 AI 生成,仅供参考

你好,我是李玥。上节课我们讲了如何确保消息不会丢失,课后我给你留了一个思考题,如果消息重复了怎么办?这节课,我们就来聊一聊如何处理重复消息的问题。
在消息传递过程中,如果出现传递失败的情况,发送方会执行重试,重试的过程中就有可能会产生重复的消息。对使用消息队列的业务系统来说,如果没有对重复消息进行处理,就有可能会导致系统的数据出现错误。
比如说,一个消费订单消息,统计下单金额的微服务,如果没有正确处理重复消息,那就会出现重复统计,导致统计结果错误。
你可能会问,如果消息队列本身能保证消息不重复,那应用程序的实现不就简单了?那有没有消息队列能保证消息不重复呢?

消息重复的情况必然存在

在 MQTT 协议中,给出了三种传递消息时能够提供的服务质量标准,这三种服务质量从低到高依次是:
At most once: 至多一次。消息在传递时,最多会被送达一次。换一个说法就是,没什么消息可靠性保证,允许丢消息。一般都是一些对消息可靠性要求不太高的监控场景使用,比如每分钟上报一次机房温度数据,可以接受数据少量丢失。
At least once: 至少一次。消息在传递时,至少会被送达一次。也就是说,不允许丢消息,但是允许有少量重复消息出现。
Exactly once:恰好一次。消息在传递时,只会被送达一次,不允许丢失也不允许重复,这个是最高的等级。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

消息队列中的重复消息问题是常见的挑战,大多数消息队列提供的服务质量标准是"At least once",即至少一次,允许少量重复消息出现。为了解决重复消息带来的影响,消费代码需要具备幂等性,即多次执行对系统的影响与一次执行相同。文章介绍了三种常用的实现幂等操作的方法:利用数据库的唯一约束、为更新的数据设置前置条件、记录并检查操作。这些方法不仅适用于解决消息队列中的重复消息问题,也可用于其他场景中解决重复请求或调用的问题。作者还提到了MQTT协议中的服务质量标准,以及Kafka支持的事务和Exactly once特性。同时,强调了团队的重要性,指出Kafka团队善于包装和营销新特性。最后,作者提出了一个思考题,探讨为什么大部分消息队列选择提供"At least once"的服务质量,而不是级别更高的Exactly once。整体而言,本文深入探讨了消息队列中的重复消息问题及解决方法,对于处理消费过程中的重复消息具有重要的参考价值。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《消息队列高手课》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(118)

  • 最新
  • 精选
  • 微微一笑
    解决一个问题,往往会引发别的问题。若消息队列实现了exactly once,会引发的问题有:①消费端在pull消息时,需要检测此消息是否被消费,这个检测机制无疑会拉低消息消费的速度。可以预想到,随着消息的剧增,消费性能势必会急剧下降,导致消息积压;②检查机制还需要业务端去配合实现,若一条消息长时间未返回ack,消息队列需要去回调看下消费结果(这个类似于事物消息的回查机制)。这样就会增加业务端的压力,与很多的未知因素。 所以,消息队列不实现exactly once,而是at least once + 幂等性,这个幂等性让给我们去处理。

    作者回复: 👍👍👍

    2019-08-03
    249
  • oscarwin
    我觉得最重要的原因是消息队列即使做到了Exactly once级别,consumer也还是要做幂等。因为在consumer从消息队列取消息这里,如果consumer消费成功,但是ack失败,consumer还是会取到重复的消息,所以消息队列花大力气做成Exactly once并不能解决业务侧消息重复的问题。

    作者回复: 👍👍👍

    2019-08-03
    13
    215
  • linqw
    学习完如何处理消费过程中的重复消息,写下自己的理解,老师有空帮忙看下哦 1、使用数据库的唯一索引防止消息被重复消费,感觉如果业务系统存在分库分表,消费消息被路由到不同的库或表,还是会存在问题。 2、为更新的数据设置前置条件,可以在消息中附带属性,比如当前账户的总金额,或者表中多加一个版本号字段,配合数据库行锁,类似乐观锁的概念,Java CAS,比较内存中的旧值是否和预先的旧值相等,如果是替换成新值。存在的问题和1类似。 3、记录并检查操作,在每个消息中维护一个全局唯一的ID,根据全局唯一ID进行判断消息是否已经被消费。存在的问题,全局唯一ID的实现有一定的复杂度,需要确保检查消费状态、更新数据、以及更新消费状态三个操作原子性,解决方式涉及到分布式锁和分布式事务,并且对高性能、高并发也有一定的影响。 4、尝试回答下课后习题①设置成Exactly once从消息队列的角度来看,为了确保消息没有被丢失或者重复,队列需采取一定的类似回查的手段,检测消费者是否有收到消息进行处理,在一定程度上会导致队列堆积等一系列问题,并且队列实现的复杂度上升。②从消费者的角度而言,因为消费者端和Broker Service端都是会各自集群,消费者端可能会存在网络抖动,导致Broker Service为了确保消息不丢失和重复,需要一直进行回查类似的操作,但是由于网络问题,导致队列堆积。 5、有个疑问如果队列的实现是At least once,但是为了确保消息不丢失,Broker Service会进行一定的重试,但是不可能一直重试,如果一直重试失败怎么处理了?

    作者回复: 第一个问题,一般来说分库分表也不会有问题,为什么?因为,使用我们的方法,对于一条具体的消息,总是会落到确定的某个库表上,它的重复消息也会落地同样的库表上,所以分库分表不是问题。 第五个问题,有的消息队列会有一个特殊的队列来保存这些总是消费失败的“坏消息”,然后继续消费之后的消息,避免坏消息卡死队列。这种坏消息一般不会是因为网络原因或者消费者死掉导致的,大多都是消息数据本身有问题,消费者的业务逻辑处理不了导致的。

    2019-08-03
    9
    32
  • Dovelol
    老师好,想问下关于幂等的情况,像设置帐户余额为100元,或者给余额为500的加100,如果有中间状态的变更或者ABA问题,也能算是幂等操作吗?

    作者回复: 确实这个例子解决不了ABA问题,如果要解决这个问题,只能使用版本号的方式。

    2019-08-07
    2
    27
  • 年年
    这课买的太值了,是本平台最吸引我的一门课,一口气看了八篇

    作者回复: 感谢支持!

    2019-08-14
    6
    23
  • 游弋云端
    我的理解如下: 1、按照您给的公式:At least once + 幂等消费 = Exactly once,所以对于消息队列来讲,要做到Exactly once,其实是需消费端的共同配合(幂等消费)才可完成,消息队列基本只提供At least once的实现; 2、从给的几种幂等消费的方案看,需要引入数据库、条件更新、分布式事务或锁等额外辅助,消息队列如果需要保障Exactly once,会导致消费端代码侵入,例如需要消费端增加消息队列用来处理幂等的client端,而消费端的形态可是太多了,兼容适配工作量巨大。故这个Exactly once留给用户自己处理,并且具有选择权,毕竟不是所有业务场景都需要Exactly once,例如老师讲的机房温度上报的案例。

    作者回复: 👍👍👍

    2019-08-03
    18
  • leslie
    对于老师说的为何都是支持At least once:是不是与以下几种情况相关;不对之处还望老师指出,因为我是刚好最近有时会有些异常数据联想到的也算是学习此课的初衷之一。 1.硬件异常或者系统异常导致的数据丢失:这里想咨询老师一下,消息队列为何不能做成像数据库一样的用undo log和redo log去避免硬件的这种异常。 2.就像为何网络协议中一样TCP和UDP的区别:消息反馈可能不是每一个反馈一次,有时是一批反馈异常,传输中可能会出现丢包或者顺序不一致。 最近几个刚好同时在学:刘超老师的网络协议、操作系统以及您的消息队列觉得之间有彼此的关系;能力有限,故而仅仅是猜测,只能通过不断的向各位老师学习才能不断的找出问题提升自己,不足之处还望老师提点-谢谢。

    作者回复: A1:主要是出于性能考虑。 A2:大部分消息队列在实现的时候,都是批量收发的,但是,采用基于位置的确认机制,是可以保证顺序的。

    2019-08-03
    2
    13
  • a、
    因为目前消息队列,在发送消息给客户端的时候,一般需要客户端ack之后才能确定,这条消息是不是真的被消费了。 1.如果客户端设置的是自动ack,那么mq就能保证只发送一次,但是这样会因为客户端消费消息不成功,而导致消息丢失 2.如果客户端都设置手动ack,这样又有一个问题,如果mq发送消息给客户端成功了,客户端也已经消费完成了,就在准备ack的时候,和mq失去了联系,这时候mq是不知道,这条消息是否真的被消费了,只能选择重发消息。 所以我觉得:如果消息队列保证了只发一次,那么消息队列就无法保证消息由于客户端消费失败而不丢失,就好像分布式系统中的cap理论,只能保证其中的两种,而无法三个都保证。

    作者回复: 架构设计就是在取舍之间选择最合适的实现方式。

    2019-08-03
    2
    11
  • 李先生
    我有个疑问,如果使用redis来实现幂等,那么在redis中设置的唯一id肯定要设置失效时间的。比如失效时间设置为10s,在这10s之内可以保证拥有唯一id的消息只被消费一次。那么10s之后又出现一个相同的唯一id,由于redis中这个唯一id已经失效,这个消息将再次被消费。这种如何处理呢?

    作者回复: 你说的这个情况确实是这样,但10s(或者更长时间)之后再出现一个重复ID的情况是非常罕见的,所以也就无所谓的。 其实,很多工程上解决问题的方法,理论上都存在缺陷。比如几乎所有一致性算法都解决不了拜占庭将军问题,很多分布式事务理论也不能保证所有情况下的数据一致性。 但这些方法确实能解决实际问题,这才是我们需要关注的。

    2020-03-12
    2
    9
  • 张三丰
    文中有句话想跟老师确认下,如下: ”t0 时刻:Consumer A 收到条消息,检查消息执行状态,发现消息未处理过,开始执行“账户增加 100 元”; t1 时刻:Consumer B 收到条消息,检查消息执行状态,发现消息未处理过,因为这个时刻,Consumer A 还未来得及更新消息执行状态。” 1.这是因为每个队列配置多个消费组导致的吧? 2.通常情况下配置多个消费组是为了提升消费能力? 3.如果配置多个消费组是为了提升消费能力,那么为什么每个消费组配置多个消费者?反正每个消费组只有一个消费者能成功消费到消息。每个消费组只配置一个消费者不行吗?

    作者回复: 这个情况不需要配置多个消费组,只要主题中配置了多个分区,同一个消费组内也会出现这种情况。

    2019-10-21
    3
    8
收起评论
显示
设置
留言
99+
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部