深入浅出系列-分布式事务Seata TCC模式

发布网友发布时间：2024-09-06 17:11

共1个回答

热心网友时间：2024-09-30 01:44

在Seata框架中，我们已经深入探讨了AT模式，但今天要转向另一种模式：TCC（Try-Confirm-Cancel）。它是蚂蚁金服为社区贡献的一种分布式事务处理策略。TCC的核心思想同样是二阶段提交，但与AT模式不同的是，它需要开发者自行设计业务逻辑，实现Try、Confirm和Cancel三个服务接口。

以用户购买商品为例，首先发起请求时，Business会通过Try接口在库存、订单和账户服务中预留资源，而不是直接操作，如库存冻结和账户余额冻结。接着，如果Try阶段所有服务都成功，TM会确认提交，调用Confirm接口执行实际操作，如减库存、创建订单和扣减余额。如果Try阶段有失败，会触发Cancel接口进行资源回滚。

TCC模式中存在一些特殊异常情况，如空回滚和幂等性问题。空回滚发生在Cancel先于Try执行，这时需要额外的事务控制表记录状态。幂等性保证了即使接口被多次调用，资源也不会被重复处理。悬挂则涉及Try和Cancel的执行顺序，需要在Try前检查Cancel或Confirm的状态。

相比AT模式，TCC的接入成本更高，因为它要求业务模型拆分为两阶段，代码实现复杂且侵入性强。然而，TCC通过业务层面的加锁优化了性能，减少了数据库锁的持有时间，提高并发性能。此外，TCC不需要依赖特定的数据库，开发者可以自由选择SQL实现。

总的来说，TCC模式更适合对业务灵活性和并发性能有较高要求的场景，但其复杂性也相应增加。在选择分布式事务模式时，需根据实际业务需求和复杂性进行权衡。"没有最好的，只有最合适的"，这是对分布式事务模式选择的最佳总结。