系列目录：

• 《分布式事务（一）—— 事务的基本概念》

• 《分布式事务（二）—— 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分布式事务框架在运行
• 2. 然后你原本的一个接口，需要改造成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来记录日志。

---

后记
  个人总结，欢迎转载、评论、批评指正