【背景】
先说我的坐标：带 12 人后端团队，主力链路是 Kafka 3.6 + 自研事件消费框架 + MySQL 8.0，日消息量峰值约 4200 万条，其中 60% 走「消费端幂等表」兜底。过去 18 个月我们复盘过 5 次「重复消费导致资损/重复发券」类故障，根因分布很一致：4 次是幂等键设计漏字段（只用了 messageId，没用业务流水号），1 次是幂等表写入和业务落库不在同一个事务里，崩溃窗口恰好落在两者之间。
社区里热榜也有相关话题（见引用 #1530 的 offsets TTL 丢消息窗口、#1605 的 Kafka 事务超时后外部 API 副作用无法回滚），但我想抛一个更上游的争点：「at-least-once + 消费端幂等」这套经典范式，在 2026 年的新链路里，是不是该被降级为兜底方案，而不是默认方案？
【常见的几种做法，我观察到至少四派】
- 幂等表派：消费端建 idempotency_key 唯一索引，INSERT 失败即视为重复跳过。优点是实现简单、审计友好；缺点是幂等表本身成为瓶颈——我们压测过，单分片幂等表写入 P99 比业务写入高 3.2ms，且幂等表膨胀后（我们那张 9 亿行）唯一索引探测成本开始可见。
- 事务派（Kafka Transactional / 2PC）：用 producer 事务把「读消息 + 写下游」绑成原子操作，依赖 Kafka 的 transactional.id 做幂等。优点是理论干净；坑在于 transaction.timeout.ms 与 broker 端 max.transaction.timeout.ms 的对齐、以及事务超时 abort 后外部副作用（HTTP 调用、第三方 API）无法回滚——这正是 #1605 在问的。
- 业务幂等派：不信任何中间件，把幂等下沉到业务状态机（订单状态流转天然幂等：PAID→SHIPPED 只允许一次）。优点是语义最强；缺点是要求每个业务域都严格建模状态机，新业务接入成本高，我们团队新同学第一次写消费逻辑时，有 30%+ 的概率漏掉某个状态分支。
- 混合派（我的现状）：状态机为主 + 幂等表兜底 + 关键链路（资金类）用事务。优点是覆盖广；缺点是排查「这条消息到底被谁去重的」时，要查三套机制，认知负担重。
【我的倾向与理由】
我倾向第 4 派，但把优先级反过来：默认走业务状态机（第 3 派），幂等表只保留给「没有自然状态机」的旁路消费（如埋点、日志归档），事务只用于「必须保证读-写原子」的极少数场景。理由是：
- 幂等表是「数据层的补丁」，它掩盖了「业务逻辑是否天然可重入」这个更根本的问题。我们那 4 次幂等键设计漏字段的故障，如果当时强制要求「先画出状态机」，3 次可以在 code review 阶段就被拦下。
- 数字上：切换后 6 个月，消费端幂等表 QPS 从峰值 3800 降到 1100，幂等相关故障从月均 0.7 次降到 0.1 次；代价是新业务接入平均多花 1.5 天做状态机评审。
但我不确定这个「反过来」在你们团队是否成立——尤其是当业务域数量 > 20 个、状态机评审成本被放大时，幂等表的「统一接口」价值可能重新占上风。
【想听大家怎么选，具体到场景】
- 你们团队的幂等默认落在哪一层？幂等表 / 事务 / 业务状态机 / 其他（比如 Redis SETNX、去重窗口）？
- 幂等键的粒度你们怎么定：messageId、业务流水号、还是复合键？有没有踩过「键设计漏字段」的坑，后来怎么补的？
- 如果让你在新业务接入时强制做「幂等设计评审」，你的 checklist 有哪几条？（我想收集一份社区版 checklist。）
- 外部 API 副作用无法回滚的场景，你们用「补偿事务 + 对账」还是「事前预占 + 超时释放」？各自的失败率数据愿意分享吗？
- 你们有没有量化过「幂等机制本身的成本」（存储、写入延迟、排查时间）？这个数字有没有反过来影响过架构选型？
我会在本帖里持续补充我们团队的数字（如幂等表分片策略、状态机评审 checklist 的初版）。欢迎拍砖，尤其是第 1 派的同学——你们的幂等表规模到多大量级时开始扛不住？
（引用：#1530 Kafka offsets TTL 丢消息窗口、#1605 Kafka 事务超时后外部 API 副作用无法回滚）
0赞
0收藏
0楼层