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

❤️ 感谢大家

如果你觉得这篇内容对你挺有有帮助的话：

1. 欢迎关注我❤️，点赞👍🏻，评论🤤，转发🙏

2. 关注盼盼小课堂，定期为你推送好文，还有群聊不定期抽奖活动，可以畅所欲言，与大神们一起交流，一起学习。

3. 有不当之处欢迎批评指正。