分布式事务方案：TCC方案

       TCC方案最大的特点是实时性高。这种方案不借助MQ，如果你的系统是基于dubbo等微服务架构，那么就必须依靠这种方案实现分布式事务了。

       一.TCC方案的实现

       1.一个完整的业务活动由一个主业务服务与若干从业务服务组成；
       2.主业务服务负责发起并完成整个业务活动，它是整个事务活动的主控制；
       3.从业务服务提供TCC型业务操作；
       4.业务活动管理器控制业务活动的一致性，它登记业务活动中的操作，并在业务活动提交时确认所有的TCC型操作的confirm操作，在业务活动取消时调用所有TCC型操作的cancel操作。

       二.TCC方案的特点

       1.TCC方案属于两阶段型的分布式事务方案，也属于补偿型的分布式事务方案；

       2.用到的服务模式：TCC操作、幂等操作、可补偿操作、可查询操作；

       3.强隔离性、严格一致性、实时性高，适用于对业务要求比较高的场景，比如处理账户、收费等业务；

       4.不与具体的服务框架耦合，在RPC架构中通用；

       5.位于业务服务层而非资源层，TCC方案的出现正是为了解决应用拆分带来的跨应用业务操作原子性的问题；

       6.可以灵活选择业务资源的锁定粒度；

       7.TCC里对每个服务资源操作的是本地事务，数据被lock的时间短，可扩展性好，可以说是为独立部署的SOA服务而设计的；

       8. TCC的Try、Confirm和Cancel操作功能需业务提供，开发成本高。

       三.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每项操作需要做的事情如下：

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

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

       3.业务活动管理器：业务活动管理器管理控制整个业务活动，包括记录维护TCC全局事务的事务状态和每个从业务服务的子事务状态，并在业务活动提交时确认所有的TCC型操作的confirm操作，在业务活动取消时调用所有TCC型操作的cancel操作。注意confirm和cancel操作要实现幂等性。