分布式事务（四）——TCC补偿模式解决方案

系列目录：

《分布式事务（一）—— 事务的基本概念》
《分布式事务（二）—— CAP和Base理论》
《分布式事务（三）—— 两阶段提交解决方案（2PC）》

一、常见分布式事务解决方案

两阶段提交（2PC，Two-phase Commit）
TCC补偿模式
基于本地消息表实现最终一致性
基于可靠消息最终一致方案
最大努力通知

二、TCC补偿模式解决方案

TCC是（Try Confirm Cancel）的缩写，每个单词代表了事务处理的不同阶段。其主要的思想是放弃了数据库事务的commit和rollback的方法，转而用状态的逻辑来区分不同的阶段，简单来说，就是把原来的一个业务处理的方法，拆分成三个方法，即try、confirm、和concel三个方法，在实际调用的过程中，首先调用try方法，看各个业务能否执行成功，如果都能成功，那就用confirm来确定，如果不能成功，就用cancel来取消。
看上去，Tcc好像和2PC有点像，但是在本质上有很大的区别，2PC是利用数据库事务来实现的，而TCC是利用数据的中间状态来实现的，比如在库存扣减的业务中，在数据库设计的时候，一般会增加一个freeze字段来区分商品的冻结的库存，在try的过程中，只是将freeze的数值增加，将库存冻结，在confirm的过程中，才会真正的降低库存，在cancel中会将冻结的数值返回去。达到数据的一致性。总体来说，TCC在业务数据上做状态的标志，没有使用数据库的事务，和2PC有本质的区别。

TCC的设计图如下：
在这里插入图片描述

1、落地TCC事务的不同阶段：Try - Confirm - Cancel

TCC事务的实现阶段一：Try
在这个阶段中，主业务流程处理后，会调用从业务流程的Try方法来执行相关的业务，将数据执行到中间状态。
TCC事务的实现阶段二：Confirm
所有的业务都ok的话，调用Confirm方法确认事务。
TCC事务的实现阶段三：Cancel
如果有服务执行没有成功，则调用Cancel来取消

2、TCC事务的使用总结

1. 首先需要选择某种TCC分布式事务框架，各个服务力就会有这个TCC分布式事务框架在运行
1. 然后你原本的一个接口，需要改造成3个逻辑： Try-Confirm-Cancel
- 先是服务调用链路依次执行Try逻辑
- 如果都正常的话，TCC分布式事务框架推进执行Confirm逻辑，完成整个事务
- 如果某个服务的Try逻辑有问题，TCC分布式事务框架感知到之后会推进执行各个服务的Cancel逻辑，插销之前执行的各个操作

TCC分布式事务的核心思想，就是在遇到服务器宕机，依赖的资源不可用的情况下，利用一下的操作来保证事务的最终一致性：

先来Try一下，不要把业务逻辑完成，先试试，看各个服务能不能正常运转，能不能先冻结需要的资源。
如果Try都ok，也就是说，底层的依赖的资源都ok，那就执行Confirm逻辑，真正的实现业务。
如果Try失败了，就调用Cancel逻辑来回滚。

3、TCC事务遇到意外情况的终极解决方案

如果遇到一些意外的情况，比如服务突然宕机，TCC事务框架如何才能保证之前没有执行完的分布式事务继续执行呢？
其解决方法如下：

TCC事务框架都要记录一些分布式事务的活动日志，可以在磁盘上的日志文件里面记录，也可以在数据库里面记录，保存下来分布式事务运行的各个阶段的状态。
万一某个服务的Cancel或者Confirm逻辑执行一直失败，TCC事务框架会通过活动日志记录各个服务的状态，然后通过重试的方法，来实现最终的执行成功，如果多次以后还是没有，可以采取发邮件等方式来通知人员处理。
常用的TCC框架，seata、go-seata