RocketMQ 幂等性 (消息重复处理)

最新推荐文章于 2024-08-25 17:31:09 发布
最新推荐文章于 2024-08-25 17:31:09 发布
阅读量420 收藏
点赞数 12
分类专栏： RocketMQ 文章标签： java-rocketmq rocketmq
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_41273137/article/details/141038541
版权

RocketMQ 无法避免消息重复，所以如果业务对消费重复非常敏感，务必

要在业务局面去重，有以下几种去重方式

1. 将消息的唯一键，可以是 msgId，也可以是消息内容中的唯一标识字段，例如订单 Id 等，消费前判断是否在

Db 或 Tair(全局 KV 存储)中存在，如果不存在则插入，幵消费，否则跳过。（实际过程要考虑原子性问题，判断

是否存在可以尝试插入，如果报主键冲突，则插入失败，直接跳过）

msgId 一定是全局唯一标识符，但是可能会存在同样的消息有两个不同 msgId 的情况（有多种原因），返种情况可能会使业务上重复消费，建议最好使用消息内容中的唯一标识字段去重。

2. 使用业务局面的状态机去重

JAVA代码搬运工
关注
专栏目录
MQ，究竟如何保证消息幂等？
shenjian58的博客
10-17 866
MQ的核心架构如何？MQ核心架构，它由发送端、服务端、固化存储、接收端四大部分组成。MQ如何保证消息必达?MQ消息必达，架构上有两个核心设计点：（1）消息落地；（2）消息超时、重传、确认...
「中间件」RocketMQ解决消息顺序和重复性消费问题整理（附测试代码）
zhenghhgz的博客
07-09 5398
前言 现在越来越多的产品采用的是分布式架构，部署的时候也同样是分布式部署，那么各个应用间的异步通信大多选择消息中间件MQ来处理，那么就回避不了两个问题： 1. 发送消息的顺序性 2. 消息被重复消费 目前在生产环境，使用较多的消息队列中间件有ActiveMQ，RabbitMQ，Kafka，RocketMQ等，本文的设计是以RocketMQ为例来解决这两个问题。 一、发送消息的顺序性 1、 什么是...
如何RocketMQ保障消息不丢失、不重复消费
weixin_42113716的博客
09-26 834
如何RocketMQ保障消息不丢失、不重复消费
RocketMQ重复消费的解决方案::分布式锁直击面试!
m0_72568513的博客
07-25 2267
需要结合业务,设计key值(redis中最主要的功能,都关系到key值的设计),抢锁的逻辑中,满足是业务数据,满足重复消费的重复数据.就可以实现这个key值的设计.目标: 多线程执行业务之前,先判断执行权限,抢锁,抢到锁的才能执行业务,抢不到的不执行.(当前案例中,抢锁,然后执行的业务逻辑是:orderAdd): 如果有一个消费者抢到锁了,执行了业务方法.执行完成后,没有释放锁的机制.如果引入等待重抢的机制,由于抢到锁的没有释放,会导致。上述整改的流程中避免了死锁问题,但是存在删除失败导致死锁的问题.
RocketMq解决消息重复消费的问题
weixin_47068446的博客
04-08 2808
1、消费端接收到消息的时候，调用redis提供的incr自增方法，以msgID作为key（具有唯一性），value则默认从1开始递增。2、当incr返回值为1时，设置其失效时间为两分钟以后（每个msgID保留两分钟足矣！），并且该消息需要被消费。2、新消息来的时候，查看该消息的msgID是否已记录，是则抛弃，否则消费。二、RocketMq一般用redis进行记录，该msg是否被记录。3、当incr返回的值大于1时，直接跳过，不消费。1、记录下每个消息的msgID。
解决RocketMQ消息重复消费场景
热门推荐
m0_37999219的博客
06-11 1万+
在broker端对Queue加锁（synchronized），Consumer监听的Queue存在已投递但未收到ack且未超时的消息，不允许获取锁，直到该Queue投递的消息全部ack或者消费超时，才允许新的Consumer获取锁，拉取消息。在broker端对Queue加锁（synchronized），Consumer监听的Queue存在已投递但未收到ack且未超时的消息，不允许获取锁，直到该Queue投递的消息全部ack或者消费超时，才允许新的Consumer获取锁，拉取消息。2、为什么在消费者做去重？
消息队列 RocketMQ 消息重复消费问题（原因及解决）
m0_65819602的博客
10-22 7625
Consumer 消费完消息并不是实时同步到 Broker 的，而是将 offset 先保存在本地map中，通过定时任务持久化上去。这就导致消息被消费了，但是此时消费者宕机了导致 offset 没提交，下次没提交 offset 的这部分消息会被再次消费 即使 offset 被提交到了 Broker，在还没来得及持久化的时候 Broker 宕机了，当重启的时候 Broker 会读取consumerOffset.json 中保存的 offset 信息，这就会导致没持久化 offset 的这部分消息会被再次消费
浅谈如何解决RocketMQ重复消费的问题
weixin_43506048的博客
10-30 8910
MQ重复消费是指同一个应用的多个实例收到相同的消息，或者同一个实例收到多次相同的消息，若消费者逻辑未做幂等处理，就会造成重复消费。 消息重复这个问题本质上是MQ设计上的atleastonce 还是exactlyonce的问题，消费者肯定想要exactly once，但MQ要保证消息投递的可靠性，对未ack的消息，会重复投递。因此消费者端要自己保证消费的幂等性，方法如：消费者收到消息后，从消息中获取消息标识写入到Redis或数据库，当再次收到该消息时就不作处理。消息重复...
RocketMQ——消息幂等问题
东天里的冬天
06-11 7665
一、缘起MQ消息必达，架构上有两个核心设计点：（1）消息落地（2）消息超时、重传、确认再次回顾消息总线核心架构，它由发送端、服务端、固化存储、接收端四大部分组成。为保证消息的可达性，超时、重传、确认机制可能导致消息总线、或者业务方收到重复的消息，从而对业务产生影响。举个栗子：购买会员卡，上游支付系统负责给用户扣款，下游系统负责给用户发卡，通过MQ异步通知。不管是上半场的ACK丢失，导致MQ收到重复...
RocketMQ(十)：rocketMQ的幂等性是什么？解决了什么问题？幂等性的两种解决方案的优势和缺点+rocketmq的死信队列？
weixin_46950473的博客
04-21 1424
前言：（简单聊聊） rocketMq为啥要花这么多精力去学习，可能就和现在比较火的注册中心：nacos一样，可能是一种前景或者是一种趋势罢了，现在技术迭代太快，今天学了hibernate，明天出mybatis，学了mybatis，出来plus，学完spring，出来cloud，总之学就完了，技多不压身，学不等于会，但是学可以扩充自己的思想可以知道更多的解决思路和解决方案，有了解决方案和思路，剩下的就是版本迭代，百度撑腰，各种大佬指点，最后终极版就是成型的“项目”了。瞎扯一下，不喜勿喷； 1.上图先？【一
RocketMQ解决幂等性问题
qq_43868329的博客
02-18 1631
RocketMQ解决幂等性问题 在什么情况下会发生RocketMQ的消息重复消费 　　1.当系统的调用链路比较长的时候，比如系统A调用系统B，系统B再把消息发送到RocketMQ中，在系统A调用系统B的时候，如果系统B处理成功，但是迟迟没有将调用成功的结果返回给系统A的时候，系统A就会尝试重新发起请求给系统B，造成系统B重复处理，发起多条消息给RocketMQ造成重复消费； 2.在系统B发送给Ro...
rocketmq幂等
08-23
RocketMQ 幂等是指在消息的生产和消费过程中，保证消息处理的幂等性。幂等性是指对同一操作的多次执行所产生的效果与一次执行的效果相同。 在 RocketMQ 中，我们可以通过以下方式实现消息的幂等性： 1. 唯一标识：...
RocketMQ(四)：重复消费、消息重试、死信消息的解决方案
从基础到源码解析的学习记录
11-30 5051
因为 Message ID 有可能出现冲突（重复）的情况。创建user表结构，num_no字段设置为唯一索引。控制重试次数，重试几次后，直接记录到数据库等等。application.yml配置文件设置。所以用业务唯一标识作为幂等处理的关键依据。Redisson分布式锁配置。所有Consumer。监听死信队列处理消息。什么情况下会出现堆积。
如何防止RocketMQ重复消费
weixin_49097844的博客
07-27 5390
利用数据库有条件的插入语句限制重复插入，查询消息系统验证消息是否重复，分布式锁，数据库约束+java异常处理机制
RocketMQ 如何保证消息不丢失，如何保证消息不被重复消费
扶摇而上九万里
08-09 6336
RocketMQ 如何保证消息不丢失，如何保证消息不被重复消费
RocketMQ~重复消息、消息堆积、回溯消费、如何防止消息不丢失
最新发布
Shangxingya的博客
08-25 828
我们需要给我们的消费者实现幂等解决重复消息，也就是对同一个消息的处理结果，执行多少次都不变。这个还是需要结合具体的业务的。你可以使用写入Redis来保证，因为Redis 的 key 和 value 就是天然支持幕等的。当然还有使用用数据库插入法，基于数据库的唯一键来保证重复数据不会被插入多条。不过最主要的还是需要，你要知道你的消息消费是否是完全不可重复消费、还是可以忍受重复消费的，然后再选择强校验和弱校验的方式。
JAVA面试题分享一百五十八：RocketMQ消息重复消费问题？
之乎者也·的博客
12-03 511
一般最好把去重操作直接放在了消费端，消费端处理消息的业务逻辑保持幂等性。消费者收到消息后，从消息中获取消息标识写入到Redis（分布式锁）或数据库（标识作为表唯一索引插入一条记录），当再次收到该消息时就不作处理。在broker端对Queue加锁（synchronized），Consumer监听的Queue存在已投递但未收到ack且未超时的消息，不允许获取锁，直到该Queue投递的消息全部ack或者消费超时，才允许新的Consumer获取锁，拉取消息。
【面试题】RocketMQ如何处理消息重复的问题呢？
zhaoliubao1的博客
04-01 406
消息去重：第二种是业务端，对重复的消息就不再消费了。这种方法，需要保证每条消息都有一个惟一的编号，通常是业务相关的，比如订单号，消费的记录需要落库，而且需要保证和消息确认这一步的原子性。如果消费端由于异常崩溃等原因未能发送消费确认，RocketMQ 会重新将消息投递给消费端，确保消息被正确消费。给这个消息做一个唯一主键（primary key）或者唯一约束，那么就算出现重复消费的情况，就会导致主键冲突，那么就不再处理这条消息。处理消息重复问题，主要有业务端自己保证，主要的方式有两种：业务幂等和消息去重。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

JAVA代码搬运工

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值