分布式事务在分布式架构中是一个难以躲开的话题。
常见的方案有三种，分别是

一、结合MQ消息中间件实现的可靠消息最终一致性
二、TCC补偿性事务解决方案
三、最大努力通知型方案

第一种方案：可靠消息最终一致性，需要业务系统结合MQ消息中间件实现，在实现过程中需要保证消息的成功发送及成功消费。
即需要通过业务系统控制MQ的消息状态。

第二种方案：TCC补偿性，分为三个阶段TRYING-CONFIRMING-CANCELING。每个阶段做不同的处理。
TRYING阶段主要是对业务系统进行检测及资源预留 CONFIRMING阶段是做业务提交，通过TRYING阶段执行成功后，再执行该阶段。
默认如果TRYING阶段执行成功，CONFIRMING就一定能成功。 CANCELING阶段是回对业务做回滚，在TRYING阶段中，如果存在分支
事务TRYING失败，则需要调用CANCELING将已预留的资源进行释放。

第三种方案：最大努力通知xing型，这种方案主要用在与第三方系统通讯时，比如：调用微信或支付宝支付后的支付结果通知。
这种方案也是结合MQ进行实现，例如：通过MQ发送http请求，设置最大通知次数。达到通知次数后即不再通知。

本文就第二种TCC型事务进行深入讲解。

在当前如火如荼的互联网浪潮下，如何应对海量数据、高并发成为大家面临的普遍难题。广大IT公司从以往的集中式网站架构，
纷纷转向分布式的网站架构，随之而来的就是进行数据库拆分和应用拆分，如何在跨数据库、跨应用保证数据操作和业务操作的一致性、
原子性，又成为需要解决的新的问题。从分布式事务的需求来源来看：

1、跨数据库

数据库拆分(水平、垂直)带来的分布式事务->保证跨库操作的原子性

基于单个JVM

2、跨应用

应用拆分带来的分布式事务->保证跨应用业务操作的原子性

跨JVM

跨应用的业务操作原子性要求，其实是比较常见的。比如在第三方支付场景中的组合支付，用户在电商网站购物后，要同时使用余额和
红包支付该笔订单，而余额系统和红包系统分别是不同的应用系统，支付系统在调用这两个系统进行支付时，就需要保证余额扣减和红
包使用要么同时成功，要么同时失败。

TCC事务的出现正是为了解决应用拆分带来的跨应用业务操作原子性的问题。当然，由于常规的XA事务(2PC，2 Phase Commit, 两阶段提交)
性能上不尽如人意，也有通过TCC事务来解决数据库拆分的使用场景(如账务拆分)，这个本文后续部分再详述。

故从整个系统架构的角度来看，分布式事务的不同方案是存在层次结构的。

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

1、Try：尝试执行业务。
完成所有业务检查(一致性)
预留必须业务资源(准隔离性)
2、Confirm：确认执行业务。
真正执行业务
不做任何业务检查
只使用Try阶段预留的业务资源
3、Cancel：取消执行业务
释放Try阶段预留的业务资源

一个完整的TCC事务参与方包括三部分：

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

TCC的优点和限制

TCC事务的优点如下：
解决了跨应用业务操作的原子性问题，在诸如组合支付、账务拆分场景非常实用。
TCC实际上把数据库层的二阶段提交上提到了应用层来实现，对于数据库来说是一阶段提交，规避了数据库层的2PC性能低下问题。

TCC事务的缺点，主要就一个：
TCC的Try、Confirm和Cancel操作功能需业务提供，开发成本高。
当然，对TCC事务的这个缺点是否是缺点，是一个见仁见智的事情。

一个案例理解

TCC说实话，TCC的理论有点让人费解。故接下来将以账务拆分为例，对TCC事务的流程做一个描述，希望对理解TCC有所帮助。
账务拆分的业务场景如下，分别位于三个不同分库的帐户A、B、C，A和B一起向C转帐共80元：分布式事务之说说TCC事务

1、Try：尝试执行业务。
完成所有业务检查(一致性)：检查A、B、C的帐户状态是否正常，帐户A的余额是否不少于30元，帐户B的余额是否不少于50元。
预留必须业务资源(准隔离性)：帐户A的冻结金额增加30元，帐户B的冻结金额增加50元，这样就保证不会出现其他并发进程扣减
了这两个帐户的余额而导致在后续的真正转帐操作过程中，帐户A和B的可用余额不够的情况。

2、Confirm：确认执行业务。
真正执行业务：如果Try阶段帐户A、B、C状态正常，且帐户A、B余额够用，则执行帐户A给账户C转账30元、帐户B给账户C转账50元的
转帐操作。
不做任何业务检查：这时已经不需要做业务检查，Try阶段已经完成了业务检查。
只使用Try阶段预留的业务资源：只需要使用Try阶段帐户A和帐户B冻结的金额即可。

3、Cancel：取消执行业务
释放Try阶段预留的业务资源：如果Try阶段部分成功，比如帐户A的余额够用，且冻结相应金额成功，帐户B的余额不够而冻结失败，则需要对帐户A做Cancel操作，将帐户A被冻结的金额解冻掉。

小结

到底要不要使用TCC到底要不要使用TCC事务，取决于以下几点：
是否真正有保证跨应用业务操作的原子性需求。
研发上能否投入资源开发相对应的TCC接口。
当然还有最后一点，能否搞定一个稳定的、高可用的、扩展性强的TCC事务管理器。
一个问题，如果TCC事务在Try阶段所有参与方(从业务服务)成功了，但是Confirm阶段部分参与方(从业务服务)成功，如何处理？

TCC参考资料

《大规模SOA系统中的分布式事务处理》：蚂蚁金服CTO程立早年的一篇关于分布式事务的PPT，里面有关于大规模SOA系统中包括TCC在
内的各种分布式事务处理方案，是支付宝在分布式事务实践的经验精华。
《Atomic Distributed Transactions: a RESTful Design》：ATOMIKOS公司的Guy Pardon和另一位作者一同写的一篇关于TCC
事务设计方案的论文，对TCC的实现细节描述较为清楚。