很多人第一次听到这个问题是在某大厂的消息队列方向一面上，面试官问得轻描淡写：“消息重复消费怎么解决？”你以为他在考Redis，其实他考的是你对整个分布式系统里数据一致性、幂等设计、缓存可靠性这几个层面的理解深度。今天我把这个问题从头到尾拆一遍，顺便把方案选型背后的逻辑说清楚，下次再被问到就不会只会说“setnx”三个字母了。
1. 先把问题想透：重复消息从哪来，会捅出什么篓子
1.1 消息重复产生的三个入口
消息系统里“至少一次”（at-least-once）是最常见的投递语义，Kafka默认就是这个，RocketMQ默认也类似。也就是说，一条消息从生产者到消费者的完整链路中，被成功消费“至少”一次，但不保证恰好一次。这不是设计缺陷，而是为了换取可用性和性能做出的取舍。
重复消息主要从三个环节进来：
- 生产者重试：生产者发送消息时网络超时了，它不确定Broker是否收到，于是重试。实际上Broker已经落盘了，只是响应丢了，这条消息就被写入了两次。
- Broker重投：消费者消费成功后还没来得及提交位移，服务重启或者网络抖动，Broker认为没消费成功，在恢复之后重新推送同一条消息。
- 消费者业务重试：消费者代码里捕获异常进行重试，或者用了消息队列自带的重试队列，同一个消息被处理多遍。
这些情况在真实生产环境里非常常见，不是你代码写得仔细就能避免的。我见过不少团队在测试环境啥问题没有，一上线双十一流量进来，消费者超时重试一开，订单表直接出现两条一模一样的订单——这种事故级别的基本都是因为消息端到端的幂等没做好。
1.2 幂等和去重，别混为一谈
很多文章把这两个词混着用，但严格来说它们不是一回事：
- 幂等（Idempotency）：同一个操作执行一次和执行多次，系统状态最终一致。它关注的是“重复执行不产生副作用”。
- 去重（Deduplication）：从一堆消息里识别出已经处理过的消息，然后丢弃或跳过。它关注的是“同一份数据不重复入库”。
去重是实现幂等的手段之一，但幂等不一定非得靠去重实现。比如一个“把账户余额设置为某个固定值”的更新操作，天然是幂等的——你执行一次和一万次，最终余额都是那个值；但“把账户余额增加100元”这个操作就不是幂等的，执行两次就多加了100。所以你看，到底用去重还是用其他幂等手段，得先看业务操作本身的语义。
面试时如果能把这个区分讲清楚，说明你不是背答案，而是真理解了这个问题的本质。
2. 数据库方案：最朴素却最让人放心的兜底
2.1 唯一索引：让数据库帮你挡下重复
最直接的做法是给业务表的某个关键字段建唯一索引。比如订单流水，你把“消息ID”或“业务唯一单号”作为唯一键插入一张独立的消费记录表，或者直接作为业务表的一个业务字段加唯一索引。重复消息到达时，插入操作会触发数据库唯一键冲突，你捕获这个异常后直接返回成功即可。
这里有一个非常关键的细节：不要先查再插。很多新手写代码喜欢先按消息ID查一下表，查不到再插，这在并发场景下有问题——两条一模一样的消息同时进来，都查不到，于是都去插入，最终还是要靠唯一索引兜底。所以正确姿势就是直接插，让数据库的唯一约束来替你做决定。用一句通俗的话说：查了再插是“先问后做”，并发下容易问错；直接插是“干了再说，干不了就说明之前干过”。
伪代码大概是这个样子：
try: insert into t_order_record(order_id, message_id, order_data) values(#{orderId}, #{messageId}, #{data}) catch DuplicateKeyException: log.info("duplicate message, ignore") return success唯一索引方案的优点是绝对可靠、简单直观，数据不会错，死都死不了。缺点也很明显——数据库是系统的性能瓶颈，每来一条消息都要插入一次，高并发量级上来之后数据库先扛不住。
2.2 状态机 + 版本号：把更新做成天然幂等
有些场景不需要额外建表，业务表本身就能扛住重复。最典型的做法是状态机约束：比如订单状态从“待支付”到“已支付”再到“已发货”，每次更新都带一个前置状态条件。
update t_order set status = 'PAID', version = version + 1 where order_id = #{orderId} and status = 'PENDING'如果返回的影响行数是1，说明更新成功；影响行数是0，说明状态早已不是“待支付”，这条消息要么是重复的，要么操作顺序错了，直接忽略或者抛异常让上层感知。这种方式本质是乐观锁，你不需要额外引入Redis，也不需要建去重表，完全利用业务自身的字段完成幂等控制。
还有更通用的版本号做法：表里加一个version字段，每次更新都核对version，更新成功再version+1。重复消息带着旧version来更新，必然匹配不上，自然被拒。
状态机方案的妙处在于它不止拦截重复，还能拦截乱序。假设支付完成消息先到，发货消息后到，但支付消息重试了又到一次，这时候用状态机约束，只有当前状态是“PENDING”才允许变成“PAID”，第二次重复的支付消息来了之后发现状态已经是“PAID”，直接跳过，逻辑完全正确。
2.3 数据库方案的适用边界
数据库方案适合对数据一致性要求极高、并发量相对可控的场景。比如金融支付、订单交易，这些数据丢了就是事故，而且单条消息处理成本本来就不低，多一次DB写入不值得心疼。
但如果你们系统单日消息量过亿，每一条都要插入去重表，那DB的写入压力会很恐怖。这时候就要考虑缓存方案或者布隆过滤器了。
3. 缓存方案：高性能去重的两个主流姿势
3.1 Redis SETNX：最快的拦截器
利用Redis的原子性去做重复校验，是互联网公司最普及的做法。核心就是利用SETNX命令——只有在key不存在时才能设置成功。以消息ID为key，谁抢到了key，谁就获得了这条消息的处理权。
具体流程：
- 消费者收到消息，拼接去重键，比如
dedup:order:msg_{messageId}。 - 执行
SET key uuid EX 3600 NX，返回OK说明首次处理，返回空说明是重复消息。 - 首次处理的才执行真正的业务逻辑。
- 业务执行完毕，删除key，释放标记。
SET dedup:order:msg_20250311001 550e8400 NX EX 3600- key存在且不是自己的值，说明重复，直接ACK丢弃。
- key存在但是自己的值，说明可能是上一次执行到一半挂了，Redis里的标记没删，需要额外处理。
有两个关键细节在面试里很容易被追问：
第一个：SETNX之后业务处理失败了怎么办？如果业务抛异常，你要不要删key？我的建议是：如果这个失败是可重试的（比如下游接口超时），先不删，让消息队列自动重投，重投之后SETNX还是会失败（key还在），处理就被卡死了。所以对于可重试的失败，正确处理方式是先删掉当前这个key，再抛异常给消息队列触发重投，或者自己延迟重试。这里一定要想清楚你自己的重试机制是靠MQ还是靠业务代码，别两边都搞导致逻辑互相冲突。
第二个：key的过期时间设多久？设太短，消息处理时间超过过期时间，同一条消息重试时key已经没了，就被当成新消息处理了，起不到去重作用。设太长，Redis内存浪费严重。一般建议设置成“业务峰值处理时间的3~5倍”，比如你平时消息处理峰值耗时200ms，最长可能有2秒，那就把过期时间设为30秒甚至1分钟。宁可多留一点，不要卡得太死。
3.2 布隆过滤器：海量消息的轻量去重网
Redis SETNX的问题是每条消息都需要在Redis里存一个key。日订单量100万，就要存100万个key，Key的内存开销在数据量大时非常难扛。这种情况下，布隆过滤器是一个很合适的选择。
布隆过滤器本质是一个很长的二进制数组加上若干哈希函数。插入一个消息ID时，通过K个哈希函数算出K个位置，把对应位全部置为1；查询时同样算出K个位置，只要任何一个位置是0，那这个消息肯定没来过；如果全是1，那这个消息“可能”来过——因为不同元素哈希之后可能重叠，也就是存在误判。
参数设计上有现成的公式，通常给定预估数据量n和期望误判率p，可以算出数组长度m和哈希函数个数k：
- m = -(n * ln p) / (ln 2)^2
- k = (m / n) * ln 2
举个例子：预估1000万条消息，期望误判率1%，需要大约 9585万 bit，也就是约12MB，配上7个哈希函数，内存占用非常可观地小。
布隆过滤器最大的优点就是省钱省内存，特别适合用户行为日志、埋点数据这种量级巨大、容忍少量丢数据的场景。缺点也有两个：一是存在误判，万一某条新消息的哈希位恰好都被置了1，它会被当作重复消息丢掉；二是不能删除，bit位一旦置1就没法恢复，所以布隆过滤器是有记忆的，如果业务上有“某条消息合法失效之后不应该再去重”这种需求，纯布隆过滤就做不了。
生产环境常见的做法是“布隆过滤器挡前面，Redis精确去重挡后面”：先用布隆过滤器快速筛掉绝大概率重复的数据，留下的少量疑似重复再去查Redis的精确SETNX，两层结合，既控制成本又保证精度。
3.3 缓存方案容易踩的坑
缓存方案最大的隐患是可用性。如果Redis集群抖动或宕机，SETNX直接报错，这时候如果代码里写的是“拿不到锁就抛异常”，那么大量正常消息都会被阻塞，引发消费积压；如果写成“拿不到锁就放行”，重复消息会直接穿透到下流。两种处理都不完美，所以生产环境一般会对Redis做哨兵或集群高可用部署，并且在代码层面加降级逻辑：Redis挂了就降级到数据库去重表，虽然性能下降但至少不会让重复数据进入业务系统。
另一个坑是Redis和DB的一致性问题。去重标记在Redis里删掉了，但业务数据还没完全落库，这时候消息重试就会造成重复。要解决这个问题，要么让业务操作和去重标记删除在同一个事务边界内（通常做不到，因为跨系统），要么接受“可能偶尔重复”，靠数据库的唯一索引做最终兜底。所以你看，缓存去重承担的是拦截绝大多数重复流量的职责，数据正确性最终还是数据库把住关卡。
4. 架构级方案：一套能打的生产环境组合拳
4.1 三层防重架构：缓存拦截 + 去重表兜底 + 状态机校验
单靠某一个方案都不够稳。我给一个可以在生产环境直接落地的推荐组合：
第一层，Redis SETNX做前置拦截，处理大部分重复流量，key的设计要考虑业务空间隔离。
第二层，业务表或独立去重表加唯一索引，如果Redis被穿透了或者宕机了，数据库能拦住最后的漏网之鱼。
第三层，业务自身的状态机校验，比如订单状态流转判断，就算前面两层都失手了，状态不对的业务更新也不会成功。
这套组合拳下来，重复消息误入业务系统的概率已经低到可以忽略。同时每一层各司其职：Redis管性能，DB管可靠，业务状态机管最终一致性。面试的时候能把这个分层逻辑讲出来，比单纯背方案强非常多。
4.2 让消息处理本身变得幂等
有些场景不需要去重，因为操作本身就是幂等的。比如你收到的消息内容是“把用户编号为10086的积分设置为1000”，你直接执行set操作，执行几次结果都一样，根本不用去重。
再比如你处理一个统计分析任务，消息里面带的是一个日期，你对当天的数据做“覆盖写入”而不是“追加写入”，那重复的统计任务最多是浪费一点计算资源，不会产生错误数据。
所以设计阶段优先考虑“能不能让操作天然幂等”，这个思路比所有去重方案都更彻底。做法包括：用更新时间覆盖旧数据而不是累加、用PUT覆盖语义而不是增量语义、在计算逻辑里采用确定性的函数，等等。你能把这个思路聊出来，面试官会觉得你对系统设计有整体认知，而不是局部地应付一个问题。
但话说回来，真实业务里不可能所有操作都是天然幂等的，最常见的“账户余额加100”这种就明显不是。这时候还是要靠去重/幂等等手段兜底。
4.3 分库分表后的去重键设计
系统上了规模之后去重表本身也要分库分表。此时去重键的设计要带上分片键，否则一个消息落到哪个分片不确定，去重就失效了。比如订单消息的去重键建议设计为orderId + messageId，分片键用orderId，这样同一个订单的所有消息走同一个分片，唯一索引才能正确生效。
Redis里的key设计也要考虑集群环境。Redis Cluster对key的分布是通过hash slot计算的，如果你只拿messageId做key，同一订单的不同消息可能落在不同节点；但去重只关心messageId是否重复，不需要同一个订单的消息落在同一个节点，所以一般没问题。只有当你需要“同一订单串行处理”时，才需要用orderId做key的前缀让它们路由到同一个节点。
5. 面试实战视角：怎么回答才能脱颖而出
5.1 对方想听到什么
这个问题在面试里通常出现在“算法与设计”这个维度，考察的是候选人在分布式环境下对一致性问题的把握。面试官手上其实有一张评价表，你在回答里有没有出现下面几个要点，决定了你这一轮的档次：
- 能不能意识到重复消息来自at-least-once投递语义，而非代码bug。
- 能不能区分“接口幂等”和“消息去重”这两个概念。
- 能不能针对不同业务场景给出不同的方案，而不是一套Redis打天下。
- 能不能说明每个方案的局限性和取舍，而不是只讲优点。
- 有没有考虑过缓存和数据库的最终一致性，Redis挂了怎么办。
5.2 一个比较完整的回答框架
我建议你这样组织回答，大概三分钟，节奏清晰：
先点出问题本质：“消息队列默认是at-least-once，重复不可避免，所以消费端必须做幂等或去重。”这是定调。
然后按层次抛出方案：数据库唯一索引方案适合强一致场景；状态机乐观锁方案适合状态流转；Redis SETNX适合高并发场景；布隆过滤器适合海量消息且容忍误判的场景。
再说组合策略：生产环境一般不是单一方案，而是Redis前置拦截 + 数据库唯一索引兜底 + 业务状态机校验三层组合。
最后提一嘴边界和取舍：缓存方案有可用性风险，可能漏判，数据库方案可靠性高但性能瓶颈明显，选型取决于业务QPS和数据一致性等级。
能把这几层都铺开，面试官基本会觉得你是有实战经验的，而不是只刷过八股。
5.3 我曾经踩过的真坑
我总结几个实际项目里遇到过的坑，都是文档上不会写的：
第一个是“幂等键设置成消息ID还是业务ID”的问题。有些消息是聚合消息，一批数据汇总后产生一条消息，业务处理后可能拆解成多个子操作。这种情况你用消息ID做幂等键不够，因为真正的重复发生在子操作层面。建议幂等键用“业务主键 + 操作类型”的组合，不要直接用消息ID。消息ID只能代表这条消息不重复，不代表这条消息里的业务数据不重复。
第二个是消费者的并发度问题。你用了SETNX去重，但如果消费线程池是32个线程，同一个订单的两条消息同时到达，两个线程同时SETNX同一个key，只有线程A成功，线程B会当做重复消息丢掉。这时候如果业务上需要“同一订单的消息必须串行处理”，你得在消费逻辑里做本地锁或者分布式锁，保证同一个key的消息串行执行。
第三个是测试环境的假象。很多团队在测试环境用假消息ID比如UUID，每次重启都生成新的UUID，导致测试环境永远测不出重复消费问题。正确做法是在测试环境就模拟真实消息ID，把生产环境的重复消息回放一遍，验证你的幂等逻辑到底有没有效。
这三个坑每一个都是我实际在项目里遇到过的，特别是第一个，不细想真的会踩。
6. 我来做个小结式的收尾
这个问题看起来是在问“消息队列幂等去重”，实际上是在考察你对分布式系统里“可靠性”和“一致性”这两个主题的理解深度。从最底层的数据库唯一索引，到中间层的状态机版本号，再到高并发场景的Redis和布隆过滤器，每一层都有自己的适用场景和性能边界，没有一套方案能通吃所有业务。
结合我个人做过的项目经验，我的建议是：不要一上来就选最高端的方案，先看业务量级和数据一致性要求。日活百万以下，一张带唯一索引的去重表就够用了，别整那些花活；日活千万以上，再把Redis和布隆过滤器加进来，做成层层防护的结构。面试时也一样，先给通用方案框架，再结合具体业务场景做选型判断，比背一个标准答案要打动人得多。
如果你正在准备面试，最后送你一条实操建议：找一个你自己负责过的真实接口，想想它如果被重复调用3次，系统会变成什么鬼样子，再针对性地设计一套幂等方案。你能把这个真实案例讲顺了，这个问题你就算彻底过关了。
