背景
我带团队做订单-支付-库存这条链路时，被问得最多的一句话就是：
"都 at-least-once 了，再加幂等不就行了吗？为什么还要上事务消息 / Outbox 表？"
这话听起来没毛病，也确实是我们早期 90% 场景的做法。但去年一次「支付成功、库存扣减消息在 broker 持久化前宕机」的故障，让我开始认真质疑：at-least-once + 幂等消费，到底在哪些边界上会失守？
几种常见做法与分歧
| 做法 | 核心思路 | 典型适用 | |------|---------|---------| | 纯 at-least-once + 业务幂等 | 消费端用唯一键 / 状态机去重，允许重复投递 | 通知、日志、异步通知类"丢了不致命"的旁路 | | Outbox（本地事务 + 轮询/Debezium） | 业务写库和写 outbox 表在同一个本地事务，CDC 再发到 MQ | 订单-库存-账户等"不能丢"的核心链路 | | Kafka 事务 / RocketMQ 事务消息 | broker 侧保证 prepare-commit 原子性 | 需要跨 partition 原子写、或要求消费端 exactly-once 的流处理 | | TCC / Saga 补偿 | 不用 MQ，用编排 + 补偿回滚 | 跨服务、跨数据库、业务语义复杂到"一条消息说不清"的场景 |
我的分歧观察：
- "幂等"经常被高估。 业务幂等能防"重复执行"，但防不了"漏执行"。at-least-once 保证至少投一次，但如果 producer 在 send() 返回前 crash，那条消息就永远丢了——幂等表帮不上忙，因为它压根没收到。
- Outbox 不是银弹。 它把"消息不丢"从 broker 侧挪到了本地事务侧，代价是 outbox 表的轮询延迟 + CDC 组件的运维复杂度。我们最初用轮询（500ms 间隔），P99 延迟直接多了 400ms+，业务方不接受。
- Kafka 事务消息的语义陷阱。 很多人以为开了
transactional.id就是 exactly-once，实际上它只保证"同一事务内的多 partition 写入是原子的"，消费端仍要自己做幂等。"exactly-once"是个端到端概念，不是 broker 单方面能给的。
我的倾向与理由
在核心资金链路上，我现在的判断标准是：
- 丢一条 = 资损 or 客诉 → 必须 Outbox 或事务消息，不能裸 at-least-once
- 丢一条 = 可以 T+1 对账补 → at-least-once + 幂等 + 对账兜底，够用
- 需要跨 3+ 个下游原子生效 → 评估 Saga，别硬塞一条消息
但我也承认，这个"够用 / 不够用"的边界，很大程度上取决于你的对账和补偿体系有多靠谱。如果每天凌晨跑全量对账、5 分钟内能自动补单，那 at-least-once 的"丢"其实被兜住了；如果对账只是"看看"，那丢一条就是真丢。
想听大家聊聊
- 你们团队怎么定义"丢一条消息的代价"？ 有没有量化的标准（比如"单条消息资损 > X 元就必须用强一致"）？
- Outbox 的轮询延迟你们怎么解的？ 纯 CDC（Debezium / Canaler）还是混合（关键消息走推送、旁路走轮询）？
- Kafka 事务消息你们实际用了吗？ 开了之后 consumer 侧的幂等逻辑有没有简化，还是照样要写？
- 有没有"当年觉得 at-least-once 够了，后来被一次故障打脸"的经历？ 想听故事 🙂
不预设标准答案，想看看不同业务规模（日单量 1k vs 1000w）下，大家实际怎么取舍的。