TCC中，Confirm或者Cancel失败了怎么办？

面试记录 2026-09-23

题目：TCC 中，Confirm 或者 Cancel 失败了怎么办？

难度：medium

评分：⭐⭐⭐☆☆

我的回答

PEC 的提交或者回滚如果失败了，主流程第一个应该是记录，把这个事情整个记录下来，然后进行尝试，尝试重试，如果还是不行的话，就进行人工告警，消息告警，告警到人工去进行记录处理、接入处理。

点评

评分：⭐⭐⭐☆☆

优点：

• 正确把握了核心思路：记录 → 重试 → 人工兜底
• 流程方向正确：先记录失败现场，再自动重试，最后告警人工介入

不足：

• ❌ 未提到 幂等性（idempotency）——这是重试的前提条件，否则重试会重复扣款/重复发货
• ❌ 未提到 超时机制——重试次数和间隔必须有上限，不能无限重试
• ❌ 未提到 空回滚（empty rollback） 防御——Cancel 到达但 Try 从未执行
• ❌ 未提到 悬挂（dangling） 防御——Confirm 先到达被拒绝，随后 Try 又到达
• ❌ 未提到 对账/巡检 机制——人工兜底前的最后一道自动化防线
• ⚠️ 回答偏单薄：medium 难度应该覆盖"自动恢复 + 人工兜底"两条链路，且点出 TCC 的三大坑

补充：

• 完整失败处理链路：

1. 失败记录：写失败日志 + 更新事务状态表（状态=FAILED）
2. 幂等重试：Confirm/Cancel 必须幂等（基于业务单号唯一键），定时任务扫描 FAILED 状态重试
3. 超时兜底：重试 N 次（如 3 次）仍失败 → 标记为 NEED_MANUAL
4. 告警通知：通过短信/钉钉/飞书通知值班工程师
5. 对账巡检：日终对账系统兜底，发现不一致数据生成差错账
6. 人工介入：工程师查失败日志 + 事务状态表 + 资源状态，手工补偿

• TCC 三大坑（必须同时处理）：
• 空回滚：Try 未执行但 Cancel 到达 → 在 Try 标记表检查，未 Try 则 Cancel 直接返回成功
• 幂等：Confirm/Cancel 重试 → 三个方法都必须基于业务单号做幂等
• 悬挂：Confirm 先到被拒绝，Try 后到 → 在 Try 前检查事务状态表，已确认/已取消则拒绝 Try
• 超时回查机制：Seata TCC 框架会定期回查分支事务状态，确认是否成功

完整讲解

第一部分：知识重点剖析

核心考点定位：考察对 TCC 框架"失败处理机制"的完整认知——不止"重试+人工"，还要覆盖幂等、空回滚、悬挂三大坑。

知识点拆解：

1. 失败处理的完整链路（6 步）

   1. 失败记录：写失败日志 + 更新事务状态表（FAILED）
   2. 幂等重试：定时任务扫 FAILED → 基于业务单号幂等执行
   3. 超时兜底：重试 N 次仍失败 → 标记 NEED_MANUAL
   4. 告警通知：短信/钉钉/飞书通知值班
   5. 对账巡检：日终对账系统兜底，发现不一致生成差错账
   6. 人工介入：工程师查失败现场，手工补偿

1. 幂等性是重试的前提（最关键）

• Confirm/Cancel 重试时会多次执行，如果方法本身不幂等，就会重复扣款、重复发货
• 实现方式：基于业务单号（如 txn_id）建唯一键，重复请求直接返回上次结果
• 口诀：Confirm 幂等 + Cancel 幂等 + Try 幂等，三者缺一不可

1. TCC 三大坑（必须同时处理）

1. 超时回查机制

• Seata TCC 框架会定期回查分支事务状态
• 如果分支事务长时间未 Confirm，框架会主动询问："你成功了吗？"
• 业务方需要实现"状态查询接口"（如 queryConfirmStatus(txn_id)）

1. 对账系统的兜底作用

• TCC 不是 100% 可靠的，极端情况下（如 TC 故障 + 业务方宕机）仍可能不一致
• 对账系统是最后一道防线：日终/小时级扫描所有事务状态，发现不一致生成差错账
• 大厂金融系统标配：TCC + 对账 + 人工兜底

1. 工程最佳实践

• 使用 Seata TCC 框架（自动处理空回滚/幂等/悬挂）
• 自建 TCC 必须处理三大坑 + 超时回查 + 对账
• 失败重试次数建议 3-5 次，间隔指数退避（1s → 2s → 4s）
• 告警要分级：普通失败→钉钉，超时失败→电话/短信

第二部分：考察方向与延伸递进

考察方向：

• 深度：是否理解"重试"必须配合"幂等"才能安全
• 广度：能否列出 TCC 三大坑并给出解决方案
• 应用：能否设计完整的失败处理链路（不止重试+人工）

延伸递进面试题：

1. "TCC 的 Cancel 失败了，但是 Try 已经成功了，这时候业务数据处于什么状态？怎么恢复？"

• 要点：资源已被 Try 冻结但未 Cancel，状态悬挂。恢复：定时扫表查所有 Try 状态超过 T 的事务，强制 Cancel 并记录差错账

1. "Seata TCC 框架的'超时回查'是怎么工作的？业务方需要做什么？"

• 要点：TC 定时扫描未完成的分支事务，调用业务方的 queryConfirmStatus 接口；业务方要实现状态查询接口

1. "如果 TCC 框架都故障了，怎么兜底？"

• 要点：对账系统是终极兜底。日终对账对比所有事务的最终状态，发现不一致生成差错账，人工介入

第三部分：面试者参考回答（300-600 字口语化）

面试官您好，TCC 的 Confirm 或 Cancel 失败处理，我一般按"自动恢复 + 人工兜底"两条链路设计。 自动恢复链路分三步： 1. 失败记录：把失败现场写到事务状态表，状态标记为 FAILED，记录失败原因、尝试次数 2. 幂等重试：定时任务扫描 FAILED 状态的事务，调用 Confirm/Cancel 重试。但这里有个关键点——Confirm 和 Cancel 必须幂等，因为重试会多次执行，如果不幂等就会重复扣款、重复发货。实现方式是基于业务单号建唯一键，重复请求直接返回上次结果 3. 超时兜底：重试 3-5 次仍失败，标记为 NEED_MANUAL，进入告警链路 人工兜底链路分三步： 1. 告警通知：通过短信/钉钉/飞书通知值班工程师 2. 对账巡检：日终对账系统扫描所有事务状态，发现不一致生成差错账，这是最后一道防线 3. 人工介入：工程师查失败日志、事务状态表、资源状态，手工补偿 这里还有个关键——TCC 有三大坑必须同时处理： - 空回滚：Try 因网络问题从未执行，但 Cancel 因协调者崩溃恢复而到达。解决：在 Try 标记表检查，未 Try 则 Cancel 直接返回成功 - 幂等：Confirm/Cancel 重试。解决：三个方法都必须基于业务单号做幂等 - 悬挂：Confirm 先到达被拒绝（无 Try 记录），随后 Try 才到，资源被 Try 占用但事务已判失败。解决：在 Try 前检查事务状态表，已确认/已取消则拒绝 Try Seata TCC 框架已经自动处理了这三大坑，但业务自建 TCC 一定要自己处理。另外，Seata 还有"超时回查"机制——TC 会定期回查分支事务状态，业务方需要实现一个状态查询接口，告诉 TC "我到底成功了没有"。 工程最佳实践：Confirm/Cancel 失败重试建议 3-5 次，间隔指数退避（1s → 2s → 4s）；告警要分级，普通失败走钉钉，超时失败走电话/短信；对账系统是终极兜底，TCC 不是 100% 可靠，极端故障下靠对账发现不一致。 总结一句话：重试的前提是幂等，幂等的前提是三大坑都处理好，三大坑处理好的前提是业务方愿意投入。这也是为什么核心业务往往用 Seata TCC 而不是自建 TCC。