TCC模式通过Try-Confirm-Cancel三阶段实现分布式事务：Try阶段预留资源并校验（如冻结金额）、Confirm阶段提交终态（扣减/增加余额）、Cancel阶段释放预留（解冻），各阶段均需幂等，Seata通过@LocalTCC和@TwoPhaseBusinessAction注解支持该模式。
在微服务架构中，TCC（Try-Confirm-Cancel）是一种常见的分布式事务模式，用于替代传统本地事务，解决跨服务数据一致性问题。Java 中实现 TCC 并非 Spring 原生支持，需结合框架（如 Seata、Hmily、ByteTCC）或手动编码完成。核心在于将业务逻辑拆分为三个阶段，并由事务协调器统一调度。
Try 阶段：预留资源，不做最终修改
Try 是事务的“预处理”阶段，关键要求是幂等、可回滚、不持久化终态数据。例如转账场景中：
- 检查账户余额是否充足（业务校验）
- 冻结用户 A 的待转出金额（如写入 account_freeze 表，状态为 “frozen”）
- 不扣减 A 的可用余额，也不增加 B 的余额
- Try 接口必须设计为幂等：重复调用不应导致多次冻结
Confirm 阶段：真正提交，释放 Try 预留资源
Confirm 在全局事务决定提交时执行，应尽量只做正向操作、避免校验（因 Try 已保证前置条件），且必须幂等：
- 扣减 A 账户可用余额
- 增加 B 账户可用余额
- 删除或标记 A 的冻结记录为 “confirmed”
- 若 Confirm 失败（如网络超时），需由事务框架重试，因此接口不能有副作用（如发两次通知）
Cancel 阶段：回滚 Try 操作，释放预留资源
Cancel 在全局事务回滚或 Try 失败时触发，目标是让系统回到 Try 前的状态：
立即学习“Java免费学习笔记（深入）”；
- 解冻 A 账户的冻结金额（恢复可用余额）
- 删除或标记冻结记录为 “cancelled”
- Cancel 也必须幂等：重复执行不能引发异常或数据错乱
- 注意：Cancel 不等于“反向 SQL”，而是业务语义上的撤销（如“取消预约”而非“insert 变 delete”）
集成 Seata 实现 TCC（推荐实践）
Seata 是目前 Java 生态最成熟的开源分布式事务解决方案，对 TCC 提供良好支持：
- 定义接口并添加 @LocalTCC 注解，声明 Try 方法及对应的 Confirm/Cancel 方法（通过 confirmMethod / cancelMethod 指定）
- Try 方法需加 @TwoPhaseBusinessAction，指定 actionName（全局唯一标识该 TCC 事务分支）
- 各服务引入 Seata client，配置 TC（Transaction Coordinator）地址
- 发起方使用 @GlobalTransactional 标记入口方法，Seata 自动协调所有参与者的 Try → Confirm/Cancel 流程
- 注意：Confirm/Cancel 方法需为 public，参数建议与 Try 一致（Seata 会透传上下文和业务参数）
手动实现 TCC 成本高、易出错，强烈建议基于 Seata 等成熟框架落地。关键不在代码量，而在于对业务资源预留逻辑的准确建模和三个阶段的幂等性保障。
