面试记录 2026-10-19
题目：TCC 是强一致性还是最终一致性？
难度：medium
标签：arch/distributed/transaction, distributed/tcc, distributed/flexible, difficulty/medium
评分：⭐⭐☆☆☆（2/5）
我的回答
tcc 实际上是最终一致性,因为 tcc 在执行过程中是有一定的时间的中间态的,虽然会根据错误补偿,但不能保证真正的原子性;
2PC 则是先预提交,在进行等待,每一个都执行没问题后才进行 commit 并没有中间态的存在
点评
优点：
- 判断"TCC 属于最终一致/准强一致"方向正确
- 抓住"有中间态、靠补偿"这一关键
- 能主动与 2PC 对比
不足：
- ❌ "2PC 没有中间态"是明显错误：Prepare 后参与者已执行本地事务但未提交、且持有锁，这本身就是中间态
- 未解释 TCC 的隔离性靠业务资源冻结（Try）保证，而 2PC 靠数据库锁
- 未提 TCC 三坑：空回滚、幂等、悬挂
- 未说明为什么 TCC 常被称为"准强一致"（业务补偿可能失败，需重试到终态）
补充：
- TCC 通常归为"准强一致/最终一致"：Confirm/Cancel 可能失败，靠重试 + 幂等收敛
- 2PC 的中间态：prepared 状态 + 锁持有，协调者崩溃即悬挂
- TCC 隔离性：Try 冻结资源，业务自己保证不可重复使用；2PC 隔离性由数据库锁保证
- 三坑解决方案：空回滚（Try 标记表）、幂等（业务唯一键）、悬挂（事务状态表校验）
完整讲解
第一部分：知识重点剖析
核心考点定位：考察对 TCC 一致性定位的准确理解，以及它与 2PC 在中间态/隔离性上的真实差异。
知识点拆解：
- TCC 的一致性定位：准强一致/最终一致。Try 只是预留资源，Confirm/Cancel 可能失败，必须靠重试和幂等最终收敛，期间存在可见中间态。
- 2PC 的中间态：Prepare 后参与者写入 redo/undo 但未提交，持有锁等待 Commit/Rollback；协调者崩溃即进入不确定阻塞。
- 隔离性差异：TCC 靠业务资源冻结（如冻结余额）实现隔离；2PC 靠数据库行锁/全局锁实现隔离。
- TCC 三坑：空回滚（Cancel 先于 Try）、幂等（重复 Confirm/Cancel）、悬挂（Cancel 后 Try 才到）。
- 适用场景：核心账务、跨库、需要细粒度资源控制的场景。
第二部分：考察方向与延伸递进
考察方向：
- 深度：TCC 的隔离性来源与三坑
- 广度：TCC vs 2PC vs Saga 的一致性差异
- 应用：什么业务该用 TCC
延伸递进面试题：
- "TCC 的 Try 和 2PC 的 Prepare 有什么本质区别？"
- 要点：Try 是业务资源预留（可自定义），Prepare 是数据库层事务准备；前者不持数据库锁，后者持锁。
- "TCC 空回滚怎么防？"
- 要点：Cancel 前查 Try 标记表，无 Try 记录则直接返回成功（幂等空回滚）。
- "TCC 悬挂怎么防？"
- 要点：Cancel 时写事务状态，Try 到达时先查状态，已取消则拒绝执行。
第三部分：面试者参考回答
【一句话结论】
面试官您好，TCC 我一般归为准强一致、最终一致，因为它有可见中间态，而且 Confirm/Cancel 可能失败。
【三点展开】
第一，Try 只是冻结资源，比如把余额从可用转到冻结，钱还没真正扣；Confirm 才真扣，Cancel 才释放，所以中间态是存在的。
第二，它靠业务补偿最终收敛，不是数据库的原子提交，因此必须处理空回滚、幂等、悬挂三个坑。
第三，2PC 也有中间态——Prepare 之后参与者已执行但未提交、还持有锁，协调者崩溃就悬挂，所以不能说 2PC 没有中间态。
【一句边界】
当然，TCC 的隔离性靠业务自己冻结资源保证，做不到 2PC 那种数据库级隔离，业务设计不到位就会超卖。