分布式事务TCC

TCC（Try-Confirm-Cancel）是一种在业务层面实现的分布式事务解决方案，它通过业务逻辑的主动补偿来保证数据的最终一致性。与依赖数据库锁的强一致性方案（如2PC）不同，TCC将事务的控制权交给了业务代码，因此在高并发场景下具有更高的性能和灵活性。

🤔 TCC 是如何工作的？

TCC 的核心思想是将一个分布式事务拆分为三个明确的阶段，每个参与的服务都需要实现这三个阶段的逻辑。

1. Try（尝试）阶段

   • 目的：进行业务检查和资源预留。
   • 行为：检查业务参数是否合法、资源是否充足。如果检查通过，则“预留”或“冻结”所需资源，但不真正执行最终的业务操作。例如，在支付场景中，Try 阶段会冻结用户账户中的相应金额，而不是直接扣款。
   • 结果：所有参与者的 Try 阶段都成功，事务才能进入 Confirm 阶段；只要有任意一个失败，则直接进入 Cancel 阶段。

2. Confirm（确认）阶段

   • 目的：确认并执行最终的业务操作。
   • 行为：在所有 Try 阶段成功后，协调者会通知所有参与者执行 Confirm 操作。此时，参与者会使用 Try 阶段预留的资源，完成真正的业务逻辑。例如，将冻结的金额正式扣除，并更新收款方余额。
   • 特点：Confirm 操作必须保证幂等性，即无论被调用多少次，结果都是一致的，以应对网络重试等异常情况。

3. Cancel（取消）阶段

   • 目的：释放 Try 阶段预留的资源，进行补偿回滚。
   • 行为：如果任何一个参与者的 Try 阶段失败，或者在 Confirm 阶段出现异常，协调者会通知所有参与者执行 Cancel 操作。参与者需要释放 Try 阶段预留的资源，使系统状态恢复到事务开始之前。例如，解冻用户在 Try 阶段被冻结的金额。
   • 特点：与 Confirm 一样，Cancel 操作也必须是幂等的。

流程示例：电商下单

以用户下单为例，涉及订单、库存、支付三个服务：

• Try：订单服务创建“待确认”订单；库存服务预占商品库存；支付服务冻结用户余额。
• Confirm：所有 Try 成功后，订单状态更新为“已确认”；库存服务正式扣减预占的库存；支付服务正式扣款。
• Cancel：若任一 Try 失败（如库存不足），则订单服务取消订单；库存服务释放预占的库存；支付服务解冻用户余额。

📊 TCC 与 2PC 有何不同？

TCC 和 2PC（Two-Phase Commit）都是两阶段提交，但它们在实现层面和性能上有本质区别。

对比维度	2PC (Two-Phase Commit)	TCC (Try-Confirm-Cancel)
锁定机制	资源层（数据库）长期锁定	业务层短暂预留
一致性	强一致性	最终一致性
侵入性	无侵入（基于数据库XA协议）	高侵入（需改造业务代码）
性能	较低（同步阻塞）	较高（无长事务锁）
资源支持	仅支持XA协议的数据库	支持任意资源（DB, Redis, API等）

简单来说，2PC 是数据库层面的“强一致性”事务，会长时间锁定资源，影响并发性能。而 TCC 是业务层面的“柔性事务”，通过短暂的资源预留，大大提升了系统的可用性和吞吐量。

📌 TCC 的优缺点与适用场景

优点

• 高性能：没有长时间的资源锁定，并发度高，适合高并发场景。
• 高灵活：完全由业务代码控制，可以适配数据库、缓存、第三方API等多种异构资源。
• 一致性可控：通过明确的 Confirm/Cancel 补偿逻辑，可以保证数据的最终一致性。

缺点

• 开发成本高：每个业务操作都需要实现 Try、Confirm、Cancel 三个接口，代码量翻倍。
• 业务侵入性强：需要将原有的业务逻辑改造为“预留-确认”模式，对业务代码有较大改动。
• 实现复杂：开发者必须手动处理幂等、空回滚（Cancel先于Try执行）、业务悬挂（Try晚于Cancel执行）等复杂的边界情况。

适用场景

TCC 非常适合对性能和一致性都有较高要求的短流程核心业务，例如：

• 电商下单、秒杀
• 金融支付、转账
• 任何需要跨服务、跨资源类型且支持“资源预留”语义的业务场景。