系列目录：
-
《分布式事务（一）—— 事务的基本概念》
-
《分布式事务（二）—— 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事务的使用总结
-
- 首先需要选择某种TCC分布式事务框架，各个服务力就会有这个TCC分布式事务框架在运行
-
- 然后你原本的一个接口，需要改造成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
4、TCC的优缺点
优点
- 解决了跨服务的业务操作原子性问题，例如组合支付，订单扣减库存等场景
- TCC的本质原理是把数据库的二阶段提交上升到微服务来实现，从而避免了数据库锁冲突的问题。
- TCC异步性能高，它采用了try先检查，然后异步实现confirm，真正提交的是在confirm方法中，可以实现最终一致。
缺点
- 对微服务的侵入性强，微服务的每个事物都必须实现Try，Confirm，Cancel等3个方法，开发成本高，后期维护改造的成本也高
- 为了达到事务的一致性要求，try，confirm，cancel接口必须实现幂等性操作。
- 由于事务管理器要记录事务日志，必定会消耗一定的性能，并使的整个TCC事务时间拉长，建议采取redis来记录日志。
后记
个人总结，欢迎转载、评论、批评指正
