分布式事务,阿里为什么钟爱TCC

发布网友发布时间：20小时前

共1个回答

热心网友时间：19小时前

分布式事务的实现方式中，TCC（Try-Confirm-Cancel）模式较为知名，然而，这一模式在实际应用中存在诸多考量因素。此前，我曾撰写文章阐述了TCC模式的多方面缺点，并在事后删除了文章，原因是一位来自阿里巴巴的大佬通过加好友的方式指出了我对该模式观点的不准确之处。

对于分布式事务，TCC模式通过将事务分为尝试（try）、确认（commit）和取消（cancel）三个阶段来管理，旨在确保在所有分支事务成功后才进行全局提交，或在任一分支事务失败时回滚整个事务。以电商系统为例，包含订单、库存和账户服务，客户购买商品的流程涉及这三个服务的原子操作。

在尝试阶段，各个服务作为分布式事务的分支，需要执行本地事务的提交，同时转为中间态以保持资源的预留状态。例如，订单服务增加订单，库存服务冻结库存，账户服务冻结金额。这个过程中，服务必须在尝试阶段处理本地事务的提交，而提交的资源则转为中间态，即暂不完成全局事务提交。

确认阶段，数据从中间态转为最终态，比如账户金额从中间账户转移至最终账户。而取消阶段与确认阶段类似，涉及资源的回滚，如订单金额从中间账户退还给客户账户。

然而，TCC模式也存在一些问题和挑战。例如，如果在尝试阶段不提交本地事务，可能导致后续事务冲突，导致数据不一致。另外，代码实现时若尝试持有连接，虽然符合TCC的思想，但实践中不可行，因此被视为问题代码。

在处理问题代码时，需要注意解决如空回滚、幂等性、悬挂事务和业务代码侵入等问题。例如，通过记录事务控制表来处理空回滚，以确保事务状态的正确性和幂等性。同时，为了避免悬挂事务，可以在取消方法中记录事务回滚记录，以判断是否已执行过回滚操作。为解决业务代码侵入问题，优化TCC模式以减少对业务代码的直接干扰。

性能优化方面，阿里巴巴在TCC模式上进行了优化，包括异步提交和同库模式。异步提交策略允许在尝试阶段后，将确认和取消阶段异步执行，从而显著提升性能，但需注意短暂的数据不一致问题。同库模式则通过本地记录事务状态和优化通信模型，减少RPC调用次数，进一步提高性能。

总的来说，TCC模式虽存在一些问题，但通过优化和解决方案，其在分布式事务管理中仍具有一定的实用价值。阿里巴巴等大公司在TCC模式上进行的优化，例如异步提交和同库模式，显著提高了性能，使得TCC在实际应用中更具吸引力。