白话介绍TCC分布式事务

假设你已经了解了本地事务与分布式事务的区别（可以先阅读：一文搞定分布式事务），这里仅简单介绍一下分布式解决方案之一TCC。

TCC分布式事务机制是用来保证各个服务形成一个整体性的事务。

一个请求中的几个步骤，要么全部成功，如果任何一个服务的操作失败了，就全部一起回滚，撤销已经完成的操作。

TCC分布式事务分三个阶段Try-Confirm-Cancel：

首先需要选择某种TCC分布式事务框架，各个服务里就会有这个TCC分布式事务框架在运行。

然后你原本的一个接口，要改造为3个逻辑，Try-Confirm-Cancel。

• 先是服务调用链路依次执行Try逻辑

• 如果都正常的话，TCC分布式事务框架推进执行Confirm逻辑，完成整个事务

• 如果某个服务的Try逻辑有问题，TCC分布式事务框架感知到之后就会推进执行各个服务的Cancel逻辑，撤销之前执行的各种操作

这就是所谓的TCC分布式事务。

TCC分布式事务的核心思想，说白了，就是当遇到下面这些情况时，

• 某个服务的数据库宕机了

• 某个服务自己挂了

• 那个服务的redis、elasticsearch、MQ等基础设施故障了

• 某些资源不足了，比如说库存不够这些

先来Try一下，不要把业务逻辑完成，先试试看，看各个服务能不能基本正常运转，能不能先冻结我需要的资源。

如果Try都ok，也就是说，底层的数据库、redis、elasticsearch、MQ都是可以写入数据的，并且你保留好了需要使用的一些资源（比如冻结了一部分库存）。

接着，再执行各个服务的Confirm逻辑，基本上Confirm就可以很大概率保证一个分布式事务的完成了。

那如果Try阶段某个服务就失败了，比如说底层的数据库挂了，或者redis挂了，等等。

此时就自动执行各个服务的Cancel逻辑，把之前的Try逻辑都回滚，所有服务都不要执行任何设计的业务逻辑。保证大家要么一起成功，要么一起失败。

写到这里，本文差不多该结束了。等一等，你有没有想到一个问题？

如果有一些意外的情况发生了，比如说订单服务突然挂了，然后再次重启，TCC分布式事务框架是如何保证之前没执行完的分布式事务继续执行的呢？

所以，TCC事务框架都是要记录一些分布式事务的活动日志的，可以在磁盘上的日志文件里记录，也可以在数据库里记录。保存下来分布式事务运行的各个阶段和状态。

 

问题还没完，万一某个服务的Cancel或者Confirm逻辑执行一直失败怎么办呢？

那也很简单，TCC事务框架会通过活动日志记录各个服务的状态。

举个例子，比如发现某个服务的Cancel或者Confirm一直没成功，会不停的重试调用他的Cancel或者Confirm逻辑，务必要他成功！

当然了，如果你的代码没有写什么bug，有充足的测试，而且Try阶段都基本尝试了一下，那么其实一般Confirm、Cancel都是可以成功的！

 

如果自己公司没有研发TCC分布式事务框架的话，那一般就会选用开源的框架。

这里笔者给大家推荐几个比较不错的框架，都是国内开源出去的：ByteTCC，tcc-transaction，himly。

大家有兴趣的可以去他们的github地址，学习一下如何使用，以及如何跟Spring Cloud、Dubbo等服务框架整合使用。

只要把那些框架整合到你的系统里，很容易就可以实现上面那种奇妙的TCC分布式事务的效果了。

推荐阅读： https://mp.weixin.qq.com/s/cYDDqUNVlstvyiyBeu-GCg