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 已保证前置条件），且必须幂等：

OpenJDK 24 Windows x64

OpenJDK 24 Windows x64 官方参考实现（24+36），适合 Windows 环境进行 Java 开发、编译、运行和版本兼容性验证。

下载

• 扣减 A 账户可用余额
• 增加 B 账户可用余额
• 删除或标记 A 的冻结记录为 “confirmed”
• 若 Confirm 失败（如网络超时），需由事务框架重试，因此接口不能有副作用（如发两次通知）

Cancel 阶段：回滚 Try 操作，释放预留资源

Cancel 在全局事务回滚或 Try 失败时触发，目标是让系统回到 Try 前的状态：

• 解冻 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 等成熟框架落地。关键不在代码量，而在于对业务资源预留逻辑的准确建模和三个阶段的幂等性保障。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南