【背景】
我负责一个订单履约链路（Java 17 + Spring Boot 3 + Kafka 3.4 + MySQL 8.0），核心路径：支付回调 → 扣库存 → 调物流 API → 确认发货。用的是标准 Saga 编排：每步成功写本地事务日志，失败触发前序步骤的补偿。
去年 Q3 我们踩了一个坑：扣库存成功，但物流 API 超时（P99 从 200ms 飙到 12s），触发补偿链路——「回滚库存」成功，「回滚支付」调银行接口时遇到对方限流（HTTP 429），补偿操作本身失败了。最终靠值班同学手动调了 3 次银行接口才回滚成功，中间用户看到的状态是「支付已扣、订单已取消」，持续了约 40 分钟。
复盘时我问团队一个问题：「如果补偿操作本身失败，我们的兜底方案是什么？」 答案让我意外——没有统一答案。有人说靠告警人工处理，有人说靠 Kafka DLQ 重试，有人说靠定时对账。三种方案并存，没有优先级。
【常见分歧 / 几种做法】
我在不同团队见过 4 种主流方案，各有优劣：
方案 A：补偿失败 → 告警 + 人工介入
- 做法：补偿操作 catch 异常，写 alert，值班同学手动重试
- 优点：实现最简单，不需要额外基础设施
- 缺点：7×24 场景下依赖人的响应速度；去年我们那次 40 分钟窗口，如果凌晨 3 点发生，可能 2 小时才有人处理
- 适用场景：日补偿失败 < 5 次、业务允许 30min 中间态
方案 B：补偿失败 → 重试队列（Kafka DLQ / 本地 retry table）
- 做法：补偿操作失败后写入 retry topic，consumer 按指数退避重试（1s → 5s → 30s → 2min → 10min），最多 5 次
- 优点：自动化，不依赖人；指数退避能扛住对方临时限流
- 缺点：如果对方持续限流（比如银行系统故障 2 小时），5 次重试全失败后消息进 DLQ，又回到「人工介入」；且 retry 期间用户看到的中间态可能持续 20+ 分钟
- 适用场景：补偿操作是幂等的、对方故障是瞬态的（< 5min）
方案 C：补偿失败 → 本地 outbox + 定时对账 job
- 做法：补偿操作写本地 outbox 表（和主事务同 DB），outbox publisher 异步投递；同时有一个 5 分钟跑一次的「对账 job」扫描 outbox 表里 status=PENDING 超过 10 分钟的记录，重新触发补偿
- 优点：outbox 和主事务同库，不会「主事务成功但 outbox 写失败」（除非 DB 本身崩了）；对账 job 是最终兜底
- 缺点：对账窗口（5min × 2 = 10min）内用户看到中间态；outbox 表在补偿量大时会成为瓶颈（我们峰值 200 条/s）
- 适用场景：补偿操作频率高（> 100 条/s）、需要强一致性保证
方案 D：TCC（Try-Confirm-Cancel）+ Cancel 失败走本地事务日志 + 定时对账
- 做法：不用 Saga 的「先做后补偿」，而是 TCC 的「先冻结后确认」；Cancel 失败时写本地 cancel_log 表，定时 job 扫描未完成的 cancel_log 重新执行
- 优点：「冻结」阶段不真正扣减资源，Cancel 的幂等性天然更强（冻结状态可查询）
- 缺点：TCC 对业务侵入性大，每个参与方都要实现 Try/Confirm/Cancel 三个接口；去年我们评估过，改造成本约 3 人月
- 适用场景：资金类操作、库存类操作，且团队有 3+ 人月的改造预算
【我的倾向与理由】
我的倾向是 B + C 组合（短期重试 + 长期对账兜底），理由：
- 纯人工不可靠：我们统计了过去 12 个月的补偿失败事件（共 23 次），其中 7 次发生在凌晨 0:00–6:00，平均人工响应时间 47 分钟。这个 SLA 我接受不了。
- 纯重试不可靠：如果对方系统故障 > 10 分钟（比如银行维护窗口），指数退避 5 次（总共约 15 分钟）全部失败后，消息进 DLQ，又回到人工。所以重试是「第一道防线」，不是「最终兜底」。
- 对账是最终兜底：5 分钟跑一次的对账 job，扫描 outbox 里 PENDING > 10min 的记录，重新触发补偿。对账 job 本身是幂等的（靠 outbox 表的 idempotency_key），不会重复补偿。
- 关键参数：对账窗口 = 重试最大退避时间 × 1.5。我们重试最大退避是 10 分钟，所以对账窗口设 15 分钟。超过 15 分钟仍未成功的补偿，升级为 P1 告警 + 自动创建工单。
一个我还没想清楚的问题：对账 job 本身如果也失败了怎么办？ 目前的做法是对账 job 跑在独立进程，失败后靠 K8s 重启 + 告警。但「对账的对账」这个递归问题，我不知道有没有更优雅的方案。
【想听大家怎么选】
想听听各位在不同场景下的选择：
- 你们线上 Saga 补偿失败的兜底方案是什么？是 A/B/C/D 中的哪一种，还是其他方案？
- 对账的「最终一致性窗口」你们定多久？定这个数值的依据是什么（业务 SLA？用户投诉率？银行接口故障 P99？）
- 补偿操作本身需要幂等吗？你们怎么保证幂等（唯一键？状态机？幂等表？）
- 有没有遇到过「补偿的补偿」场景（比如回滚支付成功，但回滚库存失败了）？怎么处理的？
- 你们团队对「中间态暴露给用户」的容忍度是多少？有没有一个可量化的标准（比如「中间态持续 > X 分钟就触发 P0」）？
欢迎拍砖，也欢迎分享你们踩过的坑。