[置顶] 分布式事务解决方案之TCC Transaction 上篇

材料摘自龙果学院：http://www.roncoo.com/

一个完整的TCC事务参与方包括三部分：
主业务服务：主业务服务为整个业务活动的发起方，如前面提到的组合支付场景，支付系统即是主业务服务。

从业务服务：从业务服务负责提供TCC业务操作，是整个业务活动的操作方。从业务服务必须实现Try、Confirm和Cancel三个接口，供主业务服务调用。由于Confirm和Cancel操作可能被重复调用，故要求Confirm和Cancel两个接口必须是幂等的。前面的组合支付场景中的余额系统和红包系统即为从业务服务。

业务活动管理器：业务活动管理器管理控制整个业务活动，包括记录维护TCC全局事务的事务状态和每个从业务服务的子事务状态，并在业务活动提交时确认所有的TCC型操作的confirm操作，在业务活动取消时调用所有TCC型操作的cancel操作。
       可见整个TCC事务对于主业务服务来说是透明的，其中业务活动管理器和从业务服务各自干了一部分工作。
Try: 尝试执行业务

完成所有业务检查（一致性）

预留必须业务资源（准隔离性）

Confirm: 确认执行业务

真正执行业务

不作任何业务检查

只使用Try阶段预留的业务资源

Confirm操作满足幂等性

Cancel: 取消执行业务

释放Try阶段预留的业务资源

Cancel操作满足幂等性

TCC的优点和限制
 TCC事务的优点如下：
解决了跨应用业务操作的原子性问题，在诸如组合支付、账务拆分场景非常实用。

TCC实际上把数据库层的二阶段提交上提到了应用层来实现，对于数据库来说是一阶段提交，规避了数据库层的2PC性能低下问题。
       TCC事务的缺点，主要就一个：TCC的Try、Confirm和Cancel操作功能需业务提供，开发成本高。
       当然，对TCC事务的这个缺点是否是缺点，是一个见仁见智的事情。