TCC

TCC

上篇文章中我们说了一下两阶段提交和三阶段提交，今天说一下tcc，那么TCC又是什么呢？它能不能解决这些问题呢，TCC也分为三个阶段，try cancel 和confirm，它也是有个分布式协调者，首先启动事务，然后进行针对每个服务进行try操作，调用每个服务中定义的try接口，根据情况执行Commit或者cancel阶段，Commit就是各个服务进行提交事务，cancel就是各个服务进行回滚事务，tcc和两阶段差不多

这里我说一下使用tcc进行a账户转入b账户钱的时候各个接口的实现，用到分支事务记录表来保证幂等性：tryLog，confirmLog，cancelLog，ab服务的数据库都有这三个表

a服务

try

1. 判断trylog日志表中是否有try记录，有的话不再执行，这是幂等性的体现
2. 判断caonfirmlog和cancel是否有本次事务的记录，有的话直接return 解决悬挂问题
3. 扣减金额，然后冻结金额，成功后插入到tryLog日志表中
4. 然后调用b服务的转账方法

注意这里有个悬挂问题，就是由于网络超时等原因调用try的时候没有及时把结果返回给协调者，协调者调用了cancel，cancel完成后try才执行，这时候就产生了try的悬挂，解决办法就是第二个步骤，先判断是否事务记录表中有记录

confirm

confirmLog表不存在记录，tryLog表存在并且cancelLog表不存在记录，金额解冻并写入confirmLog表中

cancel

cancelLog表记录不存在，tryLog记录存在

如果confirmLog记录表不存在就解冻金额

然后余额加回来，并在cancelLog中添加日志信息

注意这里tryLog记录存在的话才会解冻并加回来金额，不存在记录就执行空操作，这就是空回滚。

b服务

try

1. 判断tryLog是否存在，不存在就添加tryLog日志信息

confirm

1. confirmLog表中不存在并且tryLog表中存在，就增加金额
2. 添加confirmLog表日志信息

cancel

1. cancelLog日志信息不存在并且tryLog信息存在，减账号金额
2. 添加cancelLog日志信息

总结

这篇文章主要讲了tcc的流程，并从a和b两个服务进行转账的时候是如何保证数据一致性的，这两个服务的try confirm 和cancel分别做了什么处理进行了简单的介绍，一般tcc使用框架hmily