分布式事务- TCC编程式模式

一、前言

严格遵守ACID的分布式事务我们称为刚性事务，而遵循BASE理论（基本可用：在故障出现时保证核心功能可用，软状态：允许中间状态出现，最终一致性：不要求分布式事务打成中时间点数据都是一致性的，但是保证达到某个时间点后，数据就处于了一致性了）的事务我们称为柔性事务，其中TCC编程模式就属于柔性事务，本文我们来阐述其理论。

二、TCC编程模式

TCC编程模式本质上也是一种二阶段协议，不同在于TCC编程模式需要与具体业务耦合，下面首先看下TCC编程模式步骤:

• 所有事务参与方都需要实现try,confirm,cancle接口。
• 事务发起方向事务协调器发起事务请求，事务协调器调用所有事务参与者的try方法完成资源的预留，这时候并没有真正执行业务，而是为后面具体要执行的业务预留资源，这里完成了一阶段。

• 如果事务协调器发现有参与者的try方法预留资源时候发现资源不够，则调用参与方的cancle方法回滚预留的资源，需要注意cancle方法需要实现业务幂等，因为有可能调用失败（比如网络原因参与者接受到了请求，但是由于网络原因事务协调器没有接受到回执）会重试。

• 如果事务协调器发现所有参与者的try方法返回都OK，则事务协调器调用所有参与者的confirm方法，不做资源检查，直接进行具体的业务操作。

• 如果协调器发现所有参与者的confirm方法都OK了，则分布式事务结束。
• 如果协调器发现有些参与者的confirm方法失败了，或者由于网络原因没有收到回执，则协调器会进行重试。这里如果重试一定次数后还是失败，会怎么样那？常见的是做事务补偿。

蚂蚁金服基于TCC实现了XTS（云上叫DTS），目前在蚂蚁金服云上有对外输出，这里我们来结合其提供的一个例子来具体理解TCC的含义，以下引入蚂蚁金服云实例：

“首先我们假想这样一种场景：转账服务，从银行 A 某个账户转 100 元钱到银行 B 的某个账户，银行 A 和银行 B 可以认为是两个单独的系统，也就是两套单独的数据库。

<