如何保证消息队列消息不被重复消费

最新推荐文章于 2025-06-21 22:59:18 发布
原创 最新推荐文章于 2025-06-21 22:59:18 发布 · 1.9k 阅读 · 7 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#队列

本文探讨了Kafka消息队列中如何避免消息重复消费的问题，通过实例讲解了利用数据库唯一键、Redis缓存和全局唯一ID等策略保证消费幂等性。

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

如何保证消息队列消息不被重复消费？

kafka消息重复消费场景

kafka实际上有个offset的概念，就是每个消息写进去，都有一个offset，代表他的序号，然后consumer消费了数据之后，每隔一段时间，会把自己消费过的消息的offset提交一下，代表我已经消费过了，下次我要是重启啥的，你就让我继续从上次消费到的offset来继续消费吧。

但是凡事总有意外，比如我们之前生产经常遇到的，就是你有时候重启系统，看你怎么重启了，如果碰到点着急的，直接kill进程了，再重启。这会导致consumer有些消息处理了，但是没来得及提交offset，尴尬了。重启之后，少数消息会再次消费一次。
在这里插入图片描述

如何保证消息重复消费后的幂等性

其实重复消费不可怕，可怕的是你没考虑到重复消费之后，怎么保证幂等性。
在这里插入图片描述
举个例子吧。假设你有个系统，消费一条往数据库里插入一条，要是你一个消息重复两次，你不就插入了两条，这数据不就错了？但是你要是消费到第二次的时候，自己判断一下已经消费过了，直接扔了，不就保留了一条数据？
一条数据重复出现两次，数据库里就只有一条数据，这就保证了系统的幂等性

幂等性，我通俗点说，就一个数据，或者一个请求，给你重复来多次，你得确保对应的数据是不会改变的，不能出错。

那所以第二个问题来了，怎么保证消息队列消费的幂等性？

其实还是得结合业务来思考，我这里给几个思路：

（1）比如你拿个数据要写库，你先根据唯一条件查一下，如果这数据都有了，你就别插入了，update一下好吧

（2）比如你是写redis，那没问题了，反正每次都是set，天然幂等性

（3）比如你不是上面两个场景，那做的稍微复杂一点，你需要让生产者发送每条数据的时候，里面加一个全局唯一的id，类似订单id之类的东西，然后你这里消费到了之后，先根据这个id去比如redis里查一下，之前消费过吗？如果没有消费过，你就处理，然后这个id写redis。如果消费过了，那你就别处理了，保证别重复处理相同的消息即可。

还有比如基于数据库的唯一键来保证重复数据不会重复插入多条，我们之前线上系统就有这个问题，就是拿到数据的时候，每次重启可能会有重复，因为kafka消费者还没来得及提交offset，重复数据拿到了以后我们插入的时候，因为有唯一键约束了，所以重复数据只会插入报错，不会导致数据库中出现脏数据

如何保证MQ的消费是幂等性的，需要结合具体的业务来看

仅做个人学习记录，内容源自石衫码农公众号

【后端高阶面经：消息队列篇】27、高并发场景下怎么保证消息不会重复消费？
RickyIT的专栏
05-22 1203
在分布式消息系统中，重复消费是一个常见的挑战，尤其是在高吞吐量的消息队列如Kafka中。重复消费的成因主要包括生产者重试机制、消费者偏移量提交异常、Broker故障与分区重平衡以及消息中间件的特性。这些问题可能导致数据不一致、系统稳定性下降以及审计与对账的复杂性增加。 为了解决重复消费问题，幂等性设计是关键。在数据库层，可以通过唯一索引与约束、乐观锁控制来实现强一致性保障。在缓存层，可以使用分布式锁和布隆过滤器进行高并发去重优化。
04、如何保证消息队列中的消息不被重复消费
热门推荐
一诺
12-22 1万+
1、面试题 如何保证消息不被重复消费啊（如何保证消息消费时的幂等性）？ 2、面试官心里分析 其实这个很常见的一个问题，这俩问题基本可以连起来问。既然是消费消息，那肯定要考虑考虑会不会重复消费？能不能避免重复消费？或者重复消费了也别造成系统异常可以吗？这个是MQ领域的基本问题，其实本质上还是问你使用消息队列如何保证幂等性，这个是你架构里要考虑的一个问题。 面试官问你，肯定是必问的，这是你要考...
如何保证消息消费的幂等性？(面经)
m0_56653160的博客
06-19 659
保证消息消费的幂等性是一个重要的设计目标，尤其是在分布式系统中，消息可能会因为各种原因被重复发送或处理。
RabbitMQ中如何保证消息不被重复消费
weixin_61718800的博客
06-18 1034
简单业务：优先用 “唯一 ID + Redis 记录”，搭配消费逻辑幂等性（如 Redis 写操作、DB 唯一键 ）。高并发场景：在 ID 去重基础上，用分布式锁兜底，或依赖 MQ 手动 ACK + 死信队列控制重试。极端严格场景：组合 “ID 去重 + 幂等逻辑 + 分布式锁”，确保重复消费绝对不影响业务结果。本质上，消息重复消费无法完全避免（网络、系统故障是常态 ），但通过让消费逻辑 “幂等” + 精准记录 / 校验消费状态，可彻底屏蔽重复消费的影响～
消息队列的消费幂等性如何保证
kingwinstar的博客
08-09 481
什么是幂等？ 任意多次执行所产生的影响均与一次执行的影响相同就可以称为幂等 什么是消息幂等？ 当出现消费者对某条消息重复消费的情况时，重复消费的结果与消费一次的结果是相同的，并且多次消费并未对业务系统产生任何负面影响 为什么我们要保证幂等性，不保证幂等性，会不会有问题？ 这个问题其实没法准确回答。回答这个问题的根源得从业务场景上进行分析。比如正常业务情况下，我们是不允许同个订单重复支付,这种业务场景我们就需要确保幂等性。再比如日志记录，这种业务场景，我们可能就不需要做幂等判断。 因此是否要保证幂等性，得基于
MQ面试题-如何保证消息消费的幂等性？
weixin_36058228的博客
01-06 553
面试官心理分析 其实这是很常见的一个问题，这俩问题基本可以连起来问。既然是消费消息，那肯定要考虑会 不会重复消费？能不能避免重复消费？或者重复消费了也别造成系统异常可以吗？这个是 MQ 领域的基本问题，其实本质上还是问你使用消息队列如何保证幂等性，这个是你架构里要考 虑的一个问题。 面试题剖析 回答这个问题，首先你别听到重复消息这个事儿，就一无所知吧，你先大概说一说可能会有 哪些重复消费的问题。 首先，比如 RabbitMQ、RocketMQ、Kafka，都有可能会出现消息重复消费的问题，正常。因为 这问题
如何保证消息消费的幂等性
-
04-15 567
如何保证消息不被重复消费？ 或者说，如何保证消息消费的幂等性？ 业务场景 在本项目中，新增员工接口，会有邮件发送，在测试接口的过程中，我们可能会有重复增加的操作，相对应的消费者端会收到两个邮件。 但是我们的用户已经收到了入职邮件。 显然这种情况，我们在生产中是不希望发生的。(会被员工在背后骂的，这SB，真么又来了！)为了避免挨骂，我们还是要做点处理的。 专业点的说，用户对于同一操作发起的一次请求...
消息队列怎么保证数据不被重复消费
m0_52796585的博客
08-03 1750
这个平台汇集了近4000道精心设计的编程题目，覆盖了C、C++、JavaScript、TypeScript、Go、Rust、PHP、Java、Ruby、Python3以及C#等众多编程语言，为您的编程学习之旅提供了一个全面而丰富的实践环境。这款在线代码编辑器支持包括C、C++、JavaScript、TypeScript、Go、Rust、PHP、Java、Ruby、Python3以及C#在内的多种编程语言，无论您的项目需要哪种语言，都能在这里找到支持。请将此服务器仅用于学习和实验目的，以确保您的数据安全。
消息队列使用中防止消息重复消费的深度剖析
恩爸编程
01-12 1472
在分布式系统借助消息队列实现异步处理、解耦模块时，消息重复消费是个棘手难题。不同的消息队列产品有着各异的特性与机制，下面就结合 Kafka、RabbitMQ、ActiveMQ、RocketMQ 来聊聊如何攻克这一难关。
【基础篇-消息队列】——如何处理消费过程中的重复消息
小志的博客
06-21 595
消息队列中消息重复传递是常见问题，本文探讨了如何通过幂等性设计解决该问题。文章首先分析了三种消息传递服务质量标准（最多一次、至少一次、恰好一次），指出主流消息队列如Kafka、RabbitMQ等都只提供"至少一次"保证。为解决重复消息问题，提出了三种幂等性实现方法：1）利用数据库唯一约束防止重复操作；2）为数据更新设置前置条件；3）采用全局唯一ID记录并检查操作状态。其中前两种方法实现相对简单，第三种虽然通用性最强但实现复杂度高。这些方法不仅适用于消息处理，也可用于解决HTTP重复提交、
复习RabbitMQ消息队列，顺序消费，保证消息不丢，不重复消费，消息失败，推和拉的使用
qq_43206800的博客
03-16 1555
1 MQ有什么用？ 消息队列有很多使用场景，比较常见的有3个：解耦、异步、削峰。 1、解耦：传统各个模块之间都要时刻关注其他模块的是否更改或者是否挂掉等等，使用消息队列，可以避免模块之间直接调将所需共享的数据放在消息队列中，对于新增业务模块，只要对该类消息感兴趣，即可订阅该类消息 2、异步：不需要立即处理消息，，在之后需要的时候再慢慢处理。 3、削峰：访问量骤增时，消息队列的容量可以配置的很大，如果采用磁盘存储消息，则几乎等于“无限”容量，这样一来，高峰期的消息可以被积压起来，在随后的时间内进行平滑的处理完
高并发系统设计学习笔记(十七) 消息投递如何保证消息仅仅被消费一次
panjianlongWUHAN的专栏
08-06 302
目录 一、消息队列架构场景 二、消息为什么会丢失 1. 在消息生产的过程中丢失消息 2.在消息队列中丢失消息 3.在消费的过程中存在消息丢失的可能 三、如何保证消息只被消费一次 1.什么是幂等 2.在生产、消费过程中增加消息幂等性的保证 (1)生产端幂等性 ​(2)消费端幂等性 一、消息队列架构场景 比如你的电商系统需要上一个新的红包功能：用户在购买一定数量的商品之后，由你的系统给用户发一个现金的红包鼓励用户消费。由于发放红包的过程不应该在购买商品的主流程之内，所以你考虑..
消息队列如何保证消息幂等性消费
一瓶绿茶三元钱
01-05 1462
只是不同的消息队列发送的确认信息形式不同,例如RabbitMQ是发送一个ACK确认消息，RocketMQ是返回一个CONSUME_SUCCESS成功标志，kafka实际上有个offset的概念，每一个消息都有一个offset，kafka消费过消息后，需要提交offset，让消息队列知道自己已经消费过了。正常情况下，消费者在消费消息时候，消费完毕后，会发送一个确认信息给消息队列，消息队列就知道该消息被消费了，就会将该消息从消息队列中删除。可以看出，消息发送和消息消费两个步骤是有可能产生消息不幂等的问题。
探讨一下实现幂等性的几种方式
weixin_33749131的博客
05-14 1475
什么是幂等性？对于同一笔业务操作，不管调用多少次，得到的结果都是一样的。幂等性设计我们以对接支付宝充值为例，来分析支付回调接口如何设计？如果我们系统中对接过支付宝充值功能的，我们需要给支付宝提供一个回调接口，支付宝回调信息中会携带（out_trade_no【商户订单号】，trade_no【支付宝交易号】），trade_no在支付宝中是唯一的，out_trade_no在商户系统中是唯一的。回调接口实...
探讨确保消息消费幂等性的几种方式
weixin_44742132的博客
10-27 1655
什么是幂等性？对于同一笔业务操作，不管调用多少次，得到的结果都是一样的。幂等性设计我们以对接支付宝充值为例，来分析支付回调接口如何设计？如果我们系统中对接过支付宝充值功能...
RabbitMq(七) -- 常见问题：幂等性问题（消息重复消费）、消息丢失
weixin_39724194的博客
04-10 4123
/依赖注入 rabbitTemplate 之后再设置它的回调对象 // 此注解会在其他注解执行完成后再执行，所以rabbitTemplate先注入，再执行此初始化方法 @PostConstruct public void init() {// 设置rabbitTemplate的ConfirmCallBack为我们重写后的类 rabbitTemplate . setConfirmCallback(this);} /*** 交换机不管是否收到消息都会执行的一个回调方法。
消息消费的幂等性的解决方案
weixin_49025285的博客
07-11 1427
幂等性指的是一个操作可以被重复执行多次，而不会改变最初的操作结果。在消息队列的场景中，这意味着即便消息被重复消费，业务逻辑也应确保最终状态的一致性，不会因为消息的重复处理而产生错误或副作用。实现消息消费的幂等性是分布式系统设计中的关键环节，需要综合考虑业务需求、系统架构和技术选型，采取最适合的策略组合，以确保系统的稳定性和业务流程的正确性。面对不同的问题，灵活运用上述解决方案，可以有效应对挑战，保障系统的健壮性和性能。
RabbitMQ消费消息幂等性问题
学亮编程手记
10-29 594
消息队列不会被重复消费
最新发布
07-31
<think>我们正在讨论消息队列如何避免重复消费的问题。根据引用内容，消息队列的重复消费主要源于消息重试机制（如ack确认失败后的重发）。解决方案的核心在于保证消息处理的幂等性。 参考引用： [1] 提到：消息队列为了保证可靠性，采用ack确认机制，失败时会重试，导致可能重复消费。例如银行扣款短信重复发送。 [2] 提到：使用唯一标识和消费确认机制来避免重复消费。 [3] 提到：RabbitMQ的ack机制会触发重复消费，需要我们在设计上避免。 因此，我们可以从以下几个方面来避免重复消费： 1. 幂等性设计：确保同一消息多次消费的结果与一次消费相同。 2. 消息去重：通过记录已处理消息的唯一标识，避免重复处理。 具体措施： a. 数据库唯一约束：对于有唯一业务标识的消息（如订单ID），在数据库中设置唯一索引，重复插入会失败。 b. 状态机：在业务逻辑中引入状态机制，只有处于可处理状态时才处理消息（如订单状态只有为“未支付”时才允许支付）。 c. 去重表：记录已处理消息的唯一ID（如消息ID或业务ID），每次消费前先查询该表，若已存在则跳过。 d. 分布式锁：处理消息前尝试获取锁（如基于Redis的setnx命令），保证同一消息在同一时刻只能被一个消费者处理。 下面以订单支付为例，展示如何通过去重表实现幂等性： 假设我们有一个订单支付的消息，消息中包含订单号（order_id）和支付金额（amount）。 步骤： 1. 在数据库中创建一个去重表（例如：message_processed），用于记录已处理的消息ID（或业务唯一标识）。 2. 消费者收到消息后，先查询去重表，检查该订单号是否已经处理过。 3. 如果未处理，则进行支付处理，然后将订单号插入去重表（在一个事务中完成业务处理和去重表的插入）。 4. 如果已处理，则直接确认消息（ack），不再处理。 代码示例（伪代码）： ```java public void handleMessage(Message message) { String orderId = message.getOrderId(); // 检查去重表 if (isProcessed(orderId)) { // 已经处理，直接确认消息 message.ack(); return; } // 未处理，则进行支付业务处理 try { // 开启事务（假设使用关系型数据库） startTransaction(); // 处理支付（更新订单状态为已支付） processPayment(orderId, message.getAmount()); // 记录到去重表 insertProcessedRecord(orderId); // 提交事务 commit(); // 确认消息 message.ack(); } catch (Exception e) { // 回滚事务，并拒绝消息（不确认，可能会重发） rollback(); message.nack(); } } ``` 注意：去重表的设计需要根据消息队列的特性来定。如果消息队列本身支持消息ID（如RabbitMQ的deliveryTag），我们可以用消息ID作为去重表的唯一标识。但要注意，不同的消息队列实现中，消息ID可能不唯一（例如不同通道或不同队列的同一条消息重发时可能ID不同），因此更推荐使用业务唯一标识（如订单号）。 另外，引用[3]提到RabbitMQ没有绝对的消息顺序，所以如果消息顺序对业务有影响，还需要考虑顺序问题（但不在本题讨论范围）。 总结避免重复消费的关键点： - 保证消息处理的幂等性（无论多少次，结果一致）。 - 利用唯一标识进行去重（业务唯一标识或消息ID）。 - 在业务处理中结合数据库事务和去重操作，确保原子性。 相关问题： 1. 如何设计一个高可用的消息队列系统？ 2. 消息队列如何保证消息不丢失？ 3. 除了重复消费，消息队列还有哪些常见问题及解决方案？</think>### 消息队列避免重复消费的机制与解决方案 在分布式系统中，消息队列的重复消费是常见挑战（如银行扣款短信重复发送[^1]）。其根源在于**消息重试机制**：当消费者处理失败或ACK未及时返回时，消息队列会重发消息[^1][^3]。以下是核心解决方案： --- #### 一、幂等性设计（核心策略） **原理**：确保同一消息多次消费的结果与一次消费相同 **实现方式**： 1. **唯一标识法** ```java // 消息结构示例 class OrderMessage { String messageId; // 全局唯一ID（如雪花算法生成） String orderId; BigDecimal amount; } ``` - 消费者处理前检查消息ID是否已存在数据库/缓存 - 伪代码逻辑： ```java if (!idempotentCache.contains(messageId)) { process(message); // 业务处理 idempotentCache.set(messageId, TTL); // 记录ID并设置过期时间 } ``` 2. **业务状态机** - 例：订单状态流转 `未支付 → 已支付 → 已完成` - 处理支付消息时，先查询当前状态： ```sql SELECT status FROM orders WHERE id = ${orderId} -- 仅当状态为"未支付"时才执行扣款 ``` --- #### 二、消息队列层控制 | 机制 | 实现方式 | 适用场景 | |---------------------|--------------------------------------------------------------------------|------------------------------| | **消费者ACK确认** | RabbitMQ等：消费者处理成功后手动发送ACK，失败时NACK触发重试[^3] | 需要精确控制重试次数的场景 | | **消息去重过滤** | RocketMQ：Broker端基于Message Key去重 | 高吞吐场景 | | **事务消息** | Kafka：两阶段提交（Half Message + Commit）保证生产消费一致性 | 金融交易等强一致性要求场景 | --- #### 三、分布式锁方案 ```java // 基于Redis的分布式锁示例 public void handleMessage(Message msg) { String lockKey = "LOCK:" + msg.getOrderId(); try { if (redis.setnx(lockKey, "1", 30)) { // 获取锁 processOrder(msg); // 业务处理 } } finally { redis.del(lockKey); // 释放锁 } } ``` **优势**：保证同一订单的并发操作串行化 **注意**：需设置合理的锁超时时间防止死锁 --- #### 四、消息轨迹追踪 1. 记录消息生命周期： ```mermaid graph LR A[生产者发送] --> B[Broker存储] B --> C[消费者接收] C --> D{处理成功？} D -->|是| E[记录消费状态] D -->|否| F[重试队列] ``` 2. 实现方案： - 日志系统：ELK收集消息处理日志 - 链路追踪：SkyWalking/TraceId跟踪消息流 --- #### 五、最佳实践组合 1. **常规场景** `唯一ID + 数据库唯一索引` ```sql CREATE TABLE message_records ( id VARCHAR(64) PRIMARY KEY, -- 消息ID created_at TIMESTAMP ); ``` 2. **高频交易场景** `Redis原子操作 + 布隆过滤器` ```java // 布隆过滤器伪代码 if (!bloomFilter.mightContain(messageId)) { bloomFilter.put(messageId); process(message); } else { checkDatabase(messageId); // 二次确认 } ``` 3. **金融级场景** `事务消息 + 业务状态机 + 对账系统` > 实际案例：某支付系统通过`消息ID+Redis+每日对账`，将重复支付率从0.1%降至0.001%[^2]。 --- #### 总结 | 方案 | 复杂度 | 可靠性 | 适用场景 | |---------------------|--------|--------|------------------------| | 幂等性设计 | ★★☆ | ★★★ | 通用场景 | | ACK确认机制 | ★★★ | ★★★ | RabbitMQ/Kafka | | 分布式锁 | ★★★☆ | ★★★☆ | 高并发订单处理 | | 消息轨迹+对账 | ★★★★ | ★★★★ | 金融/支付核心系统 | **根本原则**： 1. 消息队列无法100%避免重复，需在**消费端实现幂等** 2. 根据业务容忍度选择方案（如短信通知可放宽，支付交易需严格） 3. 定期审计：通过离线对账发现漏网之鱼[^2]
评论 2
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值