主题
面试速答（先看这里）
**一句话结论：**通过他这个通过精心设计的流程，你就能看得出他的设计尽可能确保数据的一致性。
60秒标准回答：
TCC 的过程是
通过他这个通过精心设计的流程，你就能看得出他的设计尽可能确保数据的一致性
TCC 方案本身不提供强一致性，它提供的是最终一致性！
**答题顺序：**结论 → 原理/机制 → 关键流程 → 场景与取舍 → 易错点
回答主线：
- **要点1：**TCC 方案本身不提供强一致性，它提供的是最终一致性！
- **要点2：**通过上面的TCC的流程我们可以知道，Try 阶段和 Confirm/Cancel 阶段之间是存在时间间隔的。
- **要点3：**所以，这种“中间状态可见”的特性，就违反了强一致性的定义。
**记忆锚点：**TCC → Try → Confirm → Cancel → TCC是强一致性还是最终一致性 → 尽可能确保数据的一致性
关键取舍：
- TCC 的过程是： Try阶段 ：尝试执行所有操作，并锁定所需资源以准备提交。
- Cancel阶段 ：如果任何Try操作失败，或者确认过程中遇到问题，执行Cancel操作来回滚所有的操作，释放锁定的资源。
易错提醒：
- Cancel阶段 ：如果任何Try操作失败，或者确认过程中遇到问题，执行Cancel操作来回滚所有的操作，释放锁定的资源。
加分表达：
- Confirm阶段 ：如果所有的Try操作成功，那么执行Confirm操作，最终提交事务。
追问准备：
- 围绕「TCC」：底层原理是什么？使用时有哪些边界和常见坑？
- 围绕「Try」：底层原理是什么？使用时有哪些边界和常见坑？
- 围绕「Confirm」：底层原理是什么？使用时有哪些边界和常见坑？
- 如果线上出现异常，你会如何定位、验证并规避？
典型回答
TCC 的过程是：
- Try阶段：尝试执行所有操作，并锁定所需资源以准备提交。
- Confirm阶段：如果所有的Try操作成功，那么执行Confirm操作，最终提交事务。
- Cancel阶段：如果任何Try操作失败，或者确认过程中遇到问题，执行Cancel操作来回滚所有的操作，释放锁定的资源。
通过他这个通过精心设计的流程，你就能看得出他的设计尽可能确保数据的一致性。
TCC 方案本身不提供强一致性，它提供的是最终一致性！
在分布式事务中，强一致性要求：
- 在任何时刻，从任何副本节点读取的数据，都是最新的、成功提交的数据。
- 事务的中间状态对用户是不可见的。
通过上面的TCC的流程我们可以知道，Try 阶段和 Confirm/Cancel 阶段之间是存在时间间隔的。在这个时间间隔内：
- 数据处于一种“中间状态”（如“资金已冻结但未扣款”）。
- 用户可能能看到这种中间状态（比如在银行APP里看到一部分钱被冻结了）。
所以，这种“中间状态可见”的特性，就违反了强一致性的定义。因此，从技术严格意义上讲，TCC 是最终一致性的。