跨服务"补偿/回滚"逻辑：TCC 框架、人工对账，还是接受最终一致+兜底

背景

带 3 年技术团队，负责过订单-库存-支付这条跨 3 个服务的链路。每次新同学问"跨服务失败了怎么回滚"，我都很纠结给什么答案——因为正确答案取决于业务能容忍多少不一致窗口，而不是技术选型本身。可偏偏选型又是面试必问、团队里最爱吵架的点。

社区里我看到的几种做法（也是分歧所在）

1. TCC 全家桶：Try / Confirm / Cancel 三阶段，强一致、语义干净。但每个资源都要写三个接口——库存、支付、营销、积分 5 个域就是 15+ 个补偿方法，Cancel 还要保证幂等，维护成本直接翻倍。
2. 本地消息表 / Outbox + 后台扫表对账：工程上最稳、最好落地，但代价是对账窗口内数据是"半成品"，读的人要能容忍这个中间态。
3. 干脆不补偿，接受最终一致 + 定时对账 + 人工兜底：最省事，可"人工"两个字在大促那几分钟就是事故。

我的倾向与理由

我倾向 做法 2，但会强制加三条纪律，否则 Outbox 就会退化成"发消息后祈祷"：

• ① 每个补偿任务可重入（业务幂等键，不是消息 ID）；
• ② 失败落死信表，不允许静默吞；
• ③ 告警阈值写死：补偿延迟 > 30s 触发 P2、> 5min 触发 P1，别等用户投诉才知道。

理由很朴素：TCC 的强一致收益，只在"钱"这条链路上真正值得；营销、积分、通知这类链路，最终一致 + 对账 + 兜底就够用了。把工程预算花在不需要的强一致上，是团队最贵的浪费。

想听大家怎么选

• 你们团队里"强一致"的边界线是怎么划的？按金额阈值、还是按服务类型（支付强、积分弱）？
• "人工兜底"你们有没有量化过 兜底 SLA？比如"15 分钟内人必须介入"，这个数字是怎么定出来的？
• 有没有人真的把 TCC 跑到大促 QPS 5000+ 还没翻车的？特别想听具体数字：Cancel 平均耗时多少、超时率多少。

欢迎贴你们团队的真实数字和踩坑，比抽象的"强弱一致"讨论有用得多。