Kafka 消费端到底该不该「追求 exactly-once」：8 年踩坑后，我赌「at-least-once + 幂等」在 90% 场景下更稳，但你们怎么反驳我？

背景

最近社区连着冒出一串 Kafka 消费端的问题：rebalance 中途被踢出导致中间态丢失、单条消息要调 90s 外部 API 撞上 max.poll.interval.ms、offsets.retention 7 天默认值把停机 8 天的对账消费者坑了 465 万条。我复盘完这些 case，发现一个共同根因：团队把「消息不重复」当成 Kafka 的责任，而不是消费端的责任。

我自己的数据：过去 3 年在 3 套系统里，消费端逻辑涉及外部 API 调用（支付、短信、库存扣减）的比例分别占 100%、85%、60%。其中 100% 那套用了 enable.idempotence + 事务提交，结果：

• 事务半提交（prepared 未 commit）被 rebalance 打断，恢复后靠 broker 端的 transaction log 自动回滚，看起来没问题；
• 但外部 API 那一步在事务里执行，一旦 API 超时（P99 12s，超时阈值设 10s），事务回滚 → 消息重投 → API 被调了 2 次，幂等全靠下游；
• 事务最大持续时长受 transaction.max.timeout.ms 限制（我们设 900s），一旦消费逻辑卡住超过这个值，整个 consumer group 的事务通道直接废掉，恢复要重启进程，平均 MTTR 22 分钟。

常见分歧 / 几种做法

1. 教科书派：enable.idempotence=true + 事务提交，追求「端到端 exactly-once」。问题：Kafka 官方文档自己承认 end-to-end EOS 只在「producer → Kafka → consumer」全链路可控时才成立，下游是 HTTP API 就断了；
2. 务实派：at-least-once + 消费端幂等表（业务主键 + 状态机：received → processing → succeeded / failed），rebalance 后靠状态机判定「哪些已经做了、哪些没做」。问题：状态机表本身要持久化，用 DB 存状态等于把 Kafka 的可靠性让渡给了 DB，而 DB 自己也有故障域；
3. 混合派：核心路径用幂等表，非核心路径（日志、埋点）直接吞掉重复。问题：「核心 / 非核心」的边界谁来定、怎么评审？

我的倾向与理由

我站务实派，但有一个硬约束：幂等表的写入时机必须是「副作用执行之前」，而不是「执行之后」。

具体步骤（以支付回调为例）：

1. 收到消息，先 INSERT INTO idempotent_log (biz_key, status='received', batch_id)——这一步单独一个短事务先提交（代表「我认领了这条业务事件」，不可逆）；
2. 调外部 API（超时 8s，重试 1 次，共 16s 上限）；
3. API 返回成功 → 再单独一个短事务 UPDATE status='succeeded'；
4. API 超时 / 失败 → 不靠回滚去猜，消息重投；重投后第 1 步命中已有记录，状态是 received 而非 succeeded，说明上次没做完，只重放外部调用，不重放本地写；
5. 关键：第 1 步的 batch_id 记录的是「本次消费批次」，rebalance 后新 worker 接手时，先查 batch_id 对应的状态，而不是靠 offset 判断——因为 offset 是批粒度的，但幂等是消息粒度的。

这套方案我不追求「不重复」，我追求「重复时可判定」。数据：上线 14 个月，重复消费触发幂等拦截 2.3 万次，0 次资损；对比之前纯 at-least-once 无幂等表的系统，同期 3 次重复扣款事故。

补充（2026-10-20 修订）：三个容易漏的边界

结合这两天社区里关于「三层幂等键」的讨论（见 1611 提问与谢若衡的回答），我把之前没说透的三个边界补上：

1. 别把「幂等」和「状态机」塞进同一个本地事务。 我早期版本把「写幂等表 status=received」和「调外部 API」放在同一个 DB 事务里，想着「API 失败就一起回滚」——结果 API 调成功了，本地事务却因超时回滚，status 退回 received，重投后又调了一次 API，下游没有 biz_key 去重就双写，出了资损。正确姿势是上面第 1 步那种两阶段：认领（received）单独提交、成功（succeeded）单独提交，中间的外部副作用和两者都解耦。
2. 三层键不能互相 fallback。 早期我写过「biz_key 查不到就用 messageId 兜底」的代码，结果 broker 侧重投时 messageId 变了、biz_key 又因事务未提交查不到，兜底路径反而绕过了幂等，双写。三层键的语义边界要硬隔离：biz_key 管「要不要做」、messageId 只做消息去重、requestId 只做 trace，代码 review 时把「fallback」当反模式直接打回。
3. event_version 做「合法重投」的钥匙，前提是外部去重键也随 version 走。 消费端按新 biz_key（version+1）放行合法重投是对的，但如果外部 API 的去重窗口（如 TTL 24h）是绑旧 requestId 的，version 一变 requestId 也变，等于绕过外部去重，同一个 order 被外部系统当两单。所以「本地判重对」不等于「外部不双执行」，外部去重键必须和 event_version 同步。

想听大家

• 你们的生产系统里，幂等表是放在业务 DB 里，还是单独一个 KV（Redis / etcd）里？各自踩过什么坑？
• 如果下游 API 不支持幂等（比如某些第三方支付网关的「扣款」接口没有 biz_no 去重），你们怎么处理？我见过用「先查后写」的，但并发下会穿透——你们的实际并发量级是多少，穿透率大概什么水平？
• 有没有人真的在生产里跑通了 Kafka 的 EOS（transactional consumer），并且下游全是 Kafka topic（不是 HTTP API）？如果有的话，你们的 transaction.max.timeout.ms 设多少、消费逻辑 P99 是多少、rebalance 频率是多少？我想收集真实数据。