分布式事务-04:TCC实现过程及原理

上一篇：分布式事务-03:3PC 三阶段提交协议实现过程及原理

1.3pc理论基础

前面我们讲了分布式事务的基本概念，CAP理论等，也讲了2pc协议，3pc协议，我们可以暂时认为2pc协议，3pc协议他们是传统的事务处理机制，这一篇，我们讲一讲TCC（Try-Confirm-Cancel） 事务机制，相对于传统事务机制（X/Open XA Two-Phase-Commit），TCC的特别之处在于它不依赖资源管理器(RM)对XA的支持，而是通过对业务逻辑（由业务系统提供的）的调度来实现分布式事务。

在一个业务系统中，我们有A服务，提供一个操作Op,他对外提供服务时，由于网络原因，服务状态，数据库状态等原因，这个Op操作，是不能确定百分百可以成功的，怎么办呢？

我们可以用这样一种思路：对这个Op的操作，我们第一次调用时，只是当作一个临时操作（try），我们保留后续取消这个操作的权力，如果全局事务认为它该commit,那我们就对这个临时性操作做一个确定性的提交(confirm)，如果全局事务认为它该rollback，那我们就撤销这个操作(cancel)。 

在tcc事务机制中，每一个初步操作，最终都会被确认或取消。因此，针对一个具体的业务服务，TCC事务机制需要业务系统提供三段业务逻辑：

• 初步操作Try；
• 确认操作Confirm；
• 取消操作Cancel； 

2. tcc实现

2.1初步操作（Try）

TCC事务机制中的业务逻辑（Try），从执行阶段来看，与传统事务机制中业务逻辑相同。但从业务角度来看，却不一样。TCC机制中的Try仅是一个初步操作，它和后续的确认一起才能真正构成一个完整的业务逻辑。 

我们可以认为：传统事务机制的业务逻辑=tcc事务机制的try+tcc事务机制的confirm。

TCC机制将传统事务机制中的业务逻辑一分为二，拆分后保留的部分即为初步操作（Try）；而分离出的部分即为确认操作（Confirm），被延迟到事务提交阶段执行。

 TCC事务机制以初步操作（Try）为中心的，确认操作（Confirm）和取消操作（Cancel）都是围绕初步操作（Try）而展开。因此，Try阶段中的操作，其保障性是最好的，即使失败，仍然有取消操作（Cancel）可以将其不良影响进行回撤。 

2.2确认操作（Confirm）

确认操作（Confirm）是对初步操作（Try）的一个补充。当TCC事务管理器决定commit全局事务时，就会逐个执行初步操作（Try）指定的确认操作（Confirm），将初步操作（Try）未完成的事项最终完成。 

2.3取消操作（Cancel）

取消操作（Cancel）是对初步操作（Try）的一个回撤。当TCC事务管理器决定rollback全局事务时，就会逐个执行初步操作（Try）指定的取消操作（Cancel）,将初步操作（Try）已完成的操作全部撤回。 

在传统事务机制中，业务逻辑的执行和事务的处理，是在不同的阶段由不同的部件来完成的：业务逻辑部分访问资源实现数据存储，其处理是由业务系统负责；事务处理部分通过协调资源管理器以实现事务管理，其处理由事务管理器来负责。 

而在TCC事务机制中的业务逻辑处理和事务处理，其关系就错综复杂：业务逻辑（Try/Confirm/Cancel）阶段涉及所参与资源事务的commit/rollback；全局事务commit/rollback时又涉及到业务逻辑（Try/Confirm/Cancel）的执行 。

3.通俗解释

如果我们想在项目中落地tcc分布式事务，首先需要选择某种tcc框架整合到项目中，在传统的（有别于tcc模式）业务逻辑实现中，我们写业务，一个接口一般有一个实现（这里不要抠词语考虑多实现，我们只是为了更直观的展示用tcc和不用tcc两种模式下的显著区别），现在要改造为3个：Try、Confirm、Cancel ：

1）先是服务调用链路依次执行 Try 逻辑。

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

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

分布式事务主要就是应对下面这些可能遇到的情况：

- 某个服务的数据库宕机了；

- 某个服务自己挂了；

- Redis、Elasticsearch、MQ 等基础设施故障了；

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

- ......

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

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

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

那如果 Try 阶段某个服务就失败了，比如说底层的数据库挂了，或者 Redis 挂了，等等。此时就自动执行各个服务的 Cancel 逻辑，把之前的 Try 逻辑都回滚。保证大家要么一起成功，要么一起失败。

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

TCC 事务框架都是有日志模块的，主要用来记录一些分布式事务的活动日志的，可以在磁盘上的日志文件里记录，也可以在数据库里记录，来保存分布式事务运行的各个阶段的状态和相关数据，如果由于其他原因导致了服务出现问题，这时候日志就会起作用了。

4.tcc优缺点

1.实现tcc的业务成本，一个逻辑得写3套，分别对应try,confirm,cancel;

2.confirm和cancel操作的执行成本;

3.记录日志的成本和开销;

4.复杂业务，tcc的cc难以处理，难以实现;

5.如果框架不考虑幂等，事务内cc实现需要考虑幂等；

3 tcc适用场景

5.适用场景

1.强隔离性，严格一致性要求的业务；

2.执行时间较短的业务；

6.落地

后续文章，会详细介绍，如何在项目中整合落地tcc事务框架byteTcc。

本文部分内容参考：https://www.bytesoft.org/