【背景】 做消息中间件和分布式一致性这些年，我几乎在每一次消费端设计评审里都会撞见同一个问题：幂等去重到底落在哪一层？我手上一个订单履约消费者（Kafka 3.5，at-least-once，JDK 17），消费一条消息要落库 + 调外部接口，rebalance / 网络重试随时会重投。我们真踩过一次坑：只信 Redis SETNX 做去重，某次 Redis 主从切换 + 持久化没刷盘，同一个订单被消费了两次，下游多扣了一次库存，对账才发现。从那以后我对「幂等事实源放哪」格外较真。
【常见分歧 / 几种做法】 我调研、复盘下来，团队里基本是四种流派：
- 只信 DB：消费前查幂等表，唯一索引 (biz_key) 兜底，冲突即丢弃。简单，但每次消费多一次 SELECT + INSERT，高 QPS 下幂等表本身成了热点。
- 只信 Redis：SETNX biz_key 做前置去重，命中直接 ack。快，但 Redis 是缓存——会过期、会丢、会主从切换，把它当「最终事实源」等于把正确性押在缓存上。
- 状态机兜底：不引入额外幂等表，靠业务状态（订单 PENDING→PAID→SHIPPED）判断重复，重复消息因状态不满足直接 no-op。优雅，但前提是业务模型真的能表达「这一步做没做过」。
- 两层叠加：Redis 挡掉 99% 的重复（省 DB 写放大），DB 唯一索引做最终兜底（Redis 失效时还能收敛）。我见过最多的「标准答案」，但代价是两套逻辑都要维护，而且 Redis 和 DB 之间的一致性窗口是新的坑。
【我的倾向与理由】 一句话立场：幂等的「事实源」必须是持久化的（DB 唯一索引或可重放的状态机），Redis 只能做性能前置，绝不能做正确性兜底。 理由：
- 正确性不能依赖一个「可能被丢」的组件。at-least-once 的语义决定了重复一定会来，你的幂等层必须能扛住「去重存储本身失效」——而缓存天生不保证这一点。
- Redis 的价值在「挡」，不在「记」。它挡掉 99% 重复能显著降 DB 写放大，这是性能收益；但如果哪天 Redis 闪断 / 丢 key，系统必须还能靠 DB 唯一索引收敛到「恰好一次效果」，这是正确性底线。
- 状态机是最被低估的方案：业务若天然有「这一步是否已完成」的持久化状态，幂等表其实能省掉一半，重复消息靠状态判断 no-op，既省存储又把幂等语义和业务语义对齐了。
- 竞态要当心：SETNX 成功不代表业务已提交，若两次重复消息并发进来、都过了 Redis 检查（第一次 set 后还没 commit 就崩了），DB 唯一索引才是真正的最后一道闸。
【想听大家怎么选】 想听听不同场景下的真实取舍：
- 你们线上消费端到底是只做 DB 唯一索引、只做 Redis、还是两层叠加？
- 高 QPS（>5k/s）下，幂等表 / 去重 key 的存储和热点你们怎么解决？
- 有没有人真的只靠业务状态机做幂等、完全没引入额外去重存储？效果如何？
- Redis 和 DB 的「一致性窗口」（set 成功但还没 commit）你们踩过坑吗，怎么收敛的？ 欢迎把具体配置（key 结构、TTL、唯一索引定义、并发模型）贴出来，我们对着 case 聊。
0赞
0收藏
0楼层