TCC分布式事物实现原理

目前在做订单系统由于以来的服务比较多以及订单本身的业务逻辑也是很多难免遇到事物处理

这里我采用的是TCC分布式机制  

其实很简单就是通过代码方式来 commit 和 RollBack 和 Cancel

1. TCC的机制 
明眼一看就知道，TCC应该是三个英文单词的首字母缩写而来。没错，TCC分别对应Try、Confirm和Cancel三种操作，这三种操作的业务含义如下：Try：预留业务资源Confirm：确认执行业务操作Cancel：取消执行业务操作 稍稍对照下关系型数据库事务的三种操作：DML、Commit和Rollback，会发现和TCC有异曲同工之妙。在一个跨应用的业务操作中，Try操作是先把多个应用中的业务资源预留和锁定住，为后续的确认打下基础，类似的，DML操作要锁定数据库记录行，持有数据库资源；Confirm操作是在Try操作中涉及的所有应用均成功之后进行确认，使用预留的业务资源，和Commit类似；而Cancel则是当Try操作中涉及的所有应用没有全部成功，需要将已成功的应用进行取消(即Rollback回滚)。其中Confirm和Cancel操作是一对反向业务操作。

简而言之，TCC是应用层的2PC(2 Phase Commit, 两阶段提交)，如果你将应用看做资源管理器的话。 
详细来说，TCC每项操作需要做的事情如下：Try：尝试执行业务。完成所有业务检查(一致性)预留必须业务资源(准隔离性)Confirm：确认执行业务。真正执行业务不做任何业务检查只使用Try阶段预留的业务资源Cancel：取消执行业务释放Try阶段预留的业务资源 用一张图来说明TCC的机制：

一个完整的TCC事务参与方包括三部分：主业务服务：主业务服务为整个业务活动的发起方，如前面提到的组合支付场景，支付系统即是主业务服务。从业务服务：从业务服务负责提供TCC业务操作，是整个业务活动的操作方。从业务服务必须实现Try、Confirm和Cancel三个接口，供主业务服务调用。由于Confirm和Cancel操作可能被重复调用，故要求Confirm和Cancel两个接口必须是幂等的。前面的组合支付场景中的余额系统和红包系统即为从业务服务。 
业务活动管理器：业务活动管理器管理控制整个业务活动，包括记录维护TCC全局事务的事务状态和每个从业务服务的子事务状态，并在业务活动提交时确认所有的TCC型操作的confirm操作，在业务活动取消时调用所有TCC型操作的cancel操作。 
可见整个TCC事务对于主业务服务来说是透明的，其中业务活动管理器和从业务服务各自干了一部分工作。 
 

2. TCC的优点和限制 
TCC事务的优点如下：解决了跨应用业务操作的原子性问题，在诸如组合支付、账务拆分场景非常实用。TCC实际上把数据库层的二阶段提交上提到了应用层来实现，对于数据库来说是一阶段提交，规避了数据库层的2PC性能低下问题。 TCC事务的缺点，主要就一个： 
TCC的Try、Confirm和Cancel操作功能需业务提供，开发成本高。 
当然，对TCC事务的这个缺点是否是缺点，是一个见仁见智的事情。