消息幂等到底该在哪一层解决：生产端去重 vs 消费端幂等表 vs 中间件事务，你们线上把这笔账记在哪？

【背景】

先说一个我们踩过的坑，也是这次想发起这个话题的由头。

我们去年做支付对账链路：MySQL 8.0 + Kafka 3.5（KRaft，3 broker），生产端走 Kafka 事务 producer（enable.idempotence=true、transactional.id 固定），核心路径是「本地事务写 outbox → 发 Kafka → 消费者落业务表」。

线上出现了一次非常隐蔽的事故：DB 本地事务成功提交，但 Kafka 事务因为 broker 网络抖动被 coordinator 判定 aborted。结果是：

• 业务表里数据已经写了；
• Kafka 里没有这条消息；
• 消费者永远看不到，对账任务 24 小时后才报警。

这个「双送窗口 / 双失窗口」，用 Kafka 事务 producer 也救不了——因为 DB 提交和 Kafka commit 本质上是两个独立的 ACID 边界，没有跨系统的两阶段提交。

所以我想把问题再往前推一步：就算你不用 Kafka 事务，把幂等做扎实，这笔「重复」的账到底该记在哪一层？

【常见分歧：四种做法，四种账】

我见过的团队基本落在下面四种，每种都有真实代价：

1. 生产端去重（messageId + 发送侧本地表去重）

   • 好处：消费者简单，不用维护幂等表；
   • 代价：生产端要为「消息发出去但本地表没记」做兜底，等于把幂等表挪到了发送侧，问题没消失，只是换了个地方；跨实例部署时本地表去重失效。

2. Outbox + CDC（Debezium / Maxwell）

   • 好处：DB 提交和消息发送强一致，天然解决「DB 写了、消息没发」；
   • 代价：多一个 CDC 组件，消费端依然要处理「CDC 重放」带来的重复，幂等表还是躲不掉；运维成本陡增。

3. 消费端幂等表（最主流）

   • 好处：责任单一，生产端只管「至少一次」，消费端兜底「至多一次」；
   • 代价：幂等表的 key 怎么设计是门学问（messageId？业务流水号？两者复合？）；TTL 多久？跨 partition 乱序怎么办？表本身成了新的单点。

4. Kafka 事务 producer + 消费端 read_committed + EOS

   • 好处：Kafka 内部链路严格不重不丢；
   • 代价：和 DB / Redis / 外部 API 的交互依然要业务幂等，Kafka 事务只保证 Kafka 自己这一段。

【我的倾向与理由】

我的倾向是：幂等的主责任放在消费端，生产端只保证「至少一次」，不承诺「不重发」。

理由有三：

1. 责任单一原则：生产端可能有很多个（重试、failover、多实例），消费端通常只有一个消费者组，幂等表维护成本可控；
2. 幂等表的 key 应该用「业务流水号」而不是「messageId」——因为 messageId 在重发 / 重建 topic 时不稳定，业务流水号才是真正不可变的；
3. 消费端的幂等表本身要设计成「可降级」：表挂了可以临时切到「业务层查重」，而不是整条链路挂掉。

但我不确定这个倾向在以下场景是否成立：

• 消费端是外部 API（你自己控制不了幂等逻辑，比如第三方物流回调）——这时幂等只能记在生产端；
• 消息量极大（>100万 QPS），幂等表本身成了瓶颈——这时是否应该接受「允许重放，靠下游对账兜底」？

【想听大家在什么场景下怎么选】

抛几个具体问题，想听听你们线上的真实取舍：

1. 你们的幂等表 key 用 messageId 还是业务流水号？为什么？
2. 幂等表的 TTL 设多久？怎么决定这个值的？（太短有重复窗口，太长表膨胀）
3. 跨 partition 乱序时，你们的幂等表是怎么处理的？（版本号？时间戳？）
4. 有没有人把幂等完全放在生产端、消费端裸奔的？什么场景下你们觉得这是合理的？
5. 如果让你今天重做，你会选上面四种里的哪一种？为什么？

欢迎带上具体版本、QPS、团队规模来拍砖——空对空的架构讨论我见得够多了。