tcc模式通过业务层定义try-confirm-cancel三阶段、幂等设计与资源预留实现跨服务最终一致性，不依赖数据库锁或日志，核心在于业务契约：try检查并预占资源但不落库，confirm幂等提交，cancel幂等释放，由协调器保障事务推进与异常重试。
TCC 模式不是靠数据库层面的锁或日志来保障一致性，而是把事务控制权交还给业务层，通过人为定义的三个阶段（Try → Confirm / Cancel）+ 幂等 + 资源预留，实现跨库、跨服务的最终一致性。它不追求强一致，但能在高并发、网络不可靠的分布式环境下，以可接受的开发成本换取可靠的数据状态收敛。
TCC 的核心不在“技术框架”，而在“业务契约”
你得先想清楚：哪些资源要提前锁定？哪些动作必须可逆？哪些状态变更必须支持重复执行？这些问题的答案，决定了 TCC 是否能真正落地。
Try 阶段：做检查 + 预占，不落实际业务结果
这个阶段是整个 TCC 的“守门人”，目标是快速失败、轻量预占、避免脏写。
- 检查前置条件（如余额是否充足、库存是否够用），失败直接中断，不进 Confirm
- 对关键资源做逻辑锁定（例如：冻结账户可用余额、预扣库存数量、生成待确认订单）
- 所有操作必须是本地事务，写入当前服务的数据库（或缓存），不能依赖远程调用结果
- 不修改最终业务状态（比如订单状态不能设为“已支付”，只能是“预创建”或“待确认”）
举例：用户下单时，库存服务在 Try 阶段只是将商品 SKU 的「可售库存」减去本次数量，并标记为「预占中」；订单服务则插入一条 status=PREPARING 的订单记录——两者都未触发真实扣减或发货。
Confirm 阶段：只提交，不做校验，必须幂等
Confirm 是正向终态推进，前提是所有参与方 Try 全部成功。它不查余额、不验库存，只基于 Try 阶段预留的数据执行最终变更。
- 执行真正的业务动作（如：扣除冻结余额、将预占库存转为已售、订单状态更新为 CONFIRMED）
- 必须设计成幂等：同一笔事务 ID 多次调用 Confirm，结果不变（可通过唯一事务 ID + 状态机判断跳过重复执行）
- Confirm 失败需重试（TCC 框架通常内置异步重试机制），不能降级为 Cancel（因为 Try 已全部成功，Cancel 会破坏一致性）
注意：Confirm 不该再调用其他远程服务——它应是纯本地操作。若必须调用，该下游也得是 TCC 参与者，形成嵌套协调。
Java JDK 25下载Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
Cancel 阶段：释放资源，恢复 Try 前视图，同样必须幂等
只要任一 Try 失败，或 Confirm 超时/失败，协调器就会发起 Cancel。它的职责是“兜底还原”，不是“业务回退”。
- 解除 Try 阶段做的所有预占（如：解冻账户金额、释放预占库存、删除 PREPARING 订单）
- 若 Try 阶段写了日志表或消息，Cancel 也要清理对应痕迹
- 同样要求幂等：Cancel 调用多次，资源状态只从“已预占”回到“未预占”，不会变成负数或异常态
关键细节：Cancel 和 Confirm 不能互相干扰。例如，库存服务在 Cancel 时，要能区分“这笔预占是否已被 Confirm 过”——靠状态字段或版本号控制。
协调器与异常场景处理
TCC 需一个事务协调器（如 Seata 的 TC 组件）来跟踪全局事务生命周期：
- 记录每个分支的 Try 执行结果
- 在 Try 全成功后，异步触发所有 Confirm；任一失败则触发所有 Cancel
- 对 Confirm/Cancel 的超时、网络失败，自动重试（默认最多 3–5 次，可配置）
- 提供事务日志持久化（存在 DB 或 Redis），确保协调器重启后能继续推进
补充提醒：TCC 不解决“网络分区中协调器失联”的问题，但它把故障影响范围缩到最小——Try 阶段短、锁定粒度细、Cancel 可自主执行，比 2PC 更抗抖动。
基本上就这些。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
