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) ON DUPLICATE KEY UPDATE——这一步用 DB 事务，和后续业务写库在同一个本地事务里；
2. 调外部 API（超时 8s，重试 1 次，共 16s 上限）；
3. API 返回成功 → 同一事务里 UPDATE status='succeeded'；
4. API 超时 / 失败 → 事务回滚，消息重投；重投后第 1 步的 ON DUPLICATE KEY UPDATE 命中已有记录，但状态是 received 而非 succeeded，说明上次没做完，继续执行；
5. 关键：第 1 步的 batch_id 记录的是「本次消费批次」，rebalance 后新 worker 接手时，先查 batch_id 对应的状态，而不是靠 offset 判断——因为 offset 是批粒度的，但幂等是消息粒度的。

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

想听大家

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