TCC分布式事务

深碍√TFBOYSˉ_ 2023-07-01 07:28 12阅读 0赞

**首先讲解下两段提交协议与三段提交协议以及弊端**  
**两段提交协议：**一个是准备阶段，一个是提交阶段，准备阶段锁定资源，但并不提交，提交阶段要么成功要么失败，是强事务  
**三段提交协议：**在两段提交协议中增加了一个询问阶段，询问阶段可以确保尽可能早的发现无法执行操作而需要中止的行为，但是它并不能发现所有的这种行为，只会减少这种情况的发生，属于强事务  
  
**两阶段提交协议弊端(缺点)：**如果协调者宕机，参与者没有协调者指挥，则会一直阻塞。  
**三阶段提交协议**与**两阶段提交协议**相比，具有如上的优点，但是一旦发生超时，系统仍然会发生不一致，只不过这种情况很少见罢了，好处就是至少不会阻塞和永远锁定资源  
  
详情地址：[https://blog.csdn.net/qq\_41854137/article/details/84869850][https_blog.csdn.net_qq_41854137_article_details_84869850]  
  
  
  
  
**在整个微服务中可以使用两个方式来解决分布式事务问题：TCC或者消息中间件（RocketMQ、RabbitMQ等等）**  
消息中间件我在博客中已经有详细说明：[https://blog.csdn.net/qq\_39291929/article/details/80030841][https_blog.csdn.net_qq_39291929_article_details_80030841]

**TCC分布式事务（柔性事务）**

阿里巴巴提出了新的TCC协议，TCC协议将一个任务拆分成Try、Confirm、Cancel，正常的流程会先执行Try，如果执行没有问题，再执行Confirm，如果Try执行过程中出了问题，则执行操作的逆操作Cancel，从正常的流程上讲，这仍然是一个两阶段的提交协议，但是，在执行出现问题的时候，有一定的自我修复能力，如果任何一个参与者出现了问题，协调者通过执行操作的逆操作来取消之前的操作，达到最终的一致状态。

可以看出，从时序上，如果遇到极端情况下TCC会有很多问题的，例如，如果在Cancel的时候一些参与者收到指令，而一些参与者没有收到指令，整个系统仍然是不一致的，这种复杂的情况，系统首先会通过补偿的方式，尝试自动修复的，如果系统无法修复，必须由人工参与解决。

从TCC的逻辑上看，可以说TCC是简化版的三阶段提交协议，解决了两阶段提交协议的阻塞问题，但是没有解决极端情况下会出现不一致和脑裂的问题。然而，TCC通过自动化补偿手段，会把需要人工处理的不一致情况降到到最少，也是一种非常有用的解决方案，阿里在内部的一些中间件上实现了TCC模式  
  
**TCC执行步骤如下：**  
** Try：尝试执行操作**  
              · 完成所有业务检查（一致性）  
              · 预留必须业务资源（准隔离性）-----重点：**一般做冻结操作，比如库存冻结，积分增加，待发货处理等等**  
** Confirm：确认执行业务**  
              · 真正执行业务  
              · 不做任何业务检查  
              · 只使用Try阶段预留的业务资源  
** Cancel：取消执行业务**  
              · 释放Try阶段预留的业务资源    ----重点：**取消的是try业务回滚**，**并不是把Confirm中失败也到这里**  
  
重点：** Try可以失败，但Confirm和****Cancel必须成功，具体就是通过设定多次重试次数和其他定时任务等等一起使用最终达到事务一致性。**

**TCC常用事务框架有：ByteTCC、Hmily、EasyTransaction  、tcc-transaction    **    
  
**TCC的优点**  
 - 解决了跨应用业务操作的原子性问题，在诸如组合支付、账务拆分场景非常实用。  
 - TCC实际上把数据库层的二阶段提交上提到了应用层来实现，对于数据库来说是一阶段提交，规避了数据库层的2PC性能低下问题。  
  
**TCC的不足**  
 TCC的Try、Confirm和Cancel操作功能需业务提供，引入TCC 分布式事务框架，开发成本高。  
  
参考地址如下：  
[https://www.cnblogs.com/jajian/p/10014145.html][https_www.cnblogs.com_jajian_p_10014145.html]  
[http://www.tianshouzhi.com/api/tutorials/distributed\_transaction/388][http_www.tianshouzhi.com_api_tutorials_distributed_transaction_388]  
  
业务场景：咱们先来看看业务场景，假设你现在有一个电商系统，里面有一个支付订单的场景  
![format_png][]

那对一个订单支付之后，我们需要做下面的步骤：

*  更改订单的状态为“已支付”
 *  扣减商品库存
 *  给会员增加积分
 *  创建销售出库单通知仓库发货

这是一系列比较真实的步骤，无论大家有没有做过电商系统，应该都能理解。

# ***2***|***0*****进一步思考** #

好，业务场景有了，现在我们要更进一步，实现一个 TCC 分布式事务的效果。

什么意思呢？也就是说，\[1\] 订单服务-修改订单状态，\[2\] 库存服务-扣减库存，\[3\] 积分服务-增加积分，\[4\] 仓储服务-创建销售出库单。

上述这几个步骤，要么一起成功，要么一起失败，必须是一个整体性的事务。

举个例子，现在订单的状态都修改为“已支付”了，结果库存服务扣减库存失败。那个商品的库存原来是 100 件，现在卖掉了 2 件，本来应该是 98 件了。

结果呢？由于库存服务操作数据库异常，导致库存数量还是 100。这不是在坑人么，当然不能允许这种情况发生了！

但是如果你不用 TCC 分布式事务方案的话，就用个 Spring Cloud 开发这么一个微服务系统，很有可能会干出这种事儿来。

我们来看看下面的这个图，直观的表达了上述的过程：

[![format_png 1][]][format_png 1 1]

所以说，我们有必要使用 TCC 分布式事务机制来保证各个服务形成一个整体性的事务。

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

比如说库存服务要是扣减库存失败了，那么订单服务就得撤销那个修改订单状态的操作，然后得停止执行增加积分和通知出库两个操作。

说了那么多，老规矩，给大家上一张图，大伙儿顺着图来直观的感受一下：

[![format_png 2][]][format_png 2 1]

# ***3***|***0*****落地实现 TCC 分布式事务** #

那么现在到底要如何来实现一个 TCC 分布式事务，使得各个服务，要么一起成功？要么一起失败呢？

大家稍安勿躁，我们这就来一步一步的分析一下。咱们就以一个 Spring Cloud 开发系统作为背景来解释。

## ***3***|***1*****TCC 实现阶段一：Try** ##

首先，订单服务那儿，它的代码大致来说应该是这样子的：

public class OrderService {
    
        // 库存服务
        @Autowired
        private InventoryService inventoryService;
    
        // 积分服务
        @Autowired
        private CreditService creditService;
    
        // 仓储服务
        @Autowired
        private WmsService wmsService;
    
        // 对这个订单完成支付
        public void pay(){
            //对本地的的订单数据库修改订单状态为"已支付"
            orderDAO.updateStatus(OrderStatus.PAYED);
    
            //调用库存服务扣减库存
            inventoryService.reduceStock();
    
            //调用积分服务增加积分
            creditService.addCredit();
    
            //调用仓储服务通知发货
            wmsService.saleDelivery();
        }
    }

如果你之前看过 Spring Cloud 架构原理那篇文章，同时对 Spring Cloud 有一定的了解的话，应该是可以理解上面那段代码的。

其实就是订单服务完成本地数据库操作之后，通过 Spring Cloud 的 Feign 来调用其他的各个服务罢了。

但是光是凭借这段代码，是不足以实现 TCC 分布式事务的啊？！兄弟们，别着急，我们对这个订单服务修改点儿代码好不好。

首先，上面那个订单服务先把自己的状态修改为：OrderStatus.UPDATING。

这是啥意思呢？也就是说，在 pay() 那个方法里，你别直接把订单状态修改为已支付啊！你先把订单状态修改为 UPDATING，也就是修改中的意思。

这个状态是个没有任何含义的这么一个状态，代表有人正在修改这个状态罢了。

然后呢，库存服务直接提供的那个 reduceStock() 接口里，也别直接扣减库存啊，你可以是冻结掉库存。

举个例子，本来你的库存数量是 100，你别直接 100 - 2 = 98，扣减这个库存！

你可以把可销售的库存：100 - 2 = 98，设置为 98 没问题，然后在一个单独的冻结库存的字段里，设置一个 2。也就是说，有 2 个库存是给冻结了。

积分服务的 addCredit() 接口也是同理，别直接给用户增加会员积分。你可以先在积分表里的一个预增加积分字段加入积分。

比如：用户积分原本是 1190，现在要增加 10 个积分，别直接 1190 + 10 = 1200 个积分啊！

你可以保持积分为 1190 不变，在一个预增加字段里，比如说 prepare\_add\_credit 字段，设置一个 10，表示有 10 个积分准备增加。

仓储服务的 saleDelivery() 接口也是同理啊，你可以先创建一个销售出库单，但是这个销售出库单的状态是“UNKNOWN”。

也就是说，刚刚创建这个销售出库单，此时还不确定它的状态是什么呢！

上面这套改造接口的过程，其实就是所谓的 TCC 分布式事务中的第一个 T 字母代表的阶段，也就是 Try 阶段。

总结上述过程，如果你要实现一个 TCC 分布式事务，首先你的业务的主流程以及各个接口提供的业务含义，不是说直接完成那个业务操作，而是完成一个 Try 的操作。

这个操作，一般都是锁定某个资源，设置一个预备类的状态，冻结部分数据，等等，大概都是这类操作。

咱们来一起看看下面这张图，结合上面的文字，再来捋一捋整个过程：

[![format_png 3][]][format_png 3 1]

## ***3***|***2*****TCC 实现阶段二：Confirm** ##

然后就分成两种情况了，第一种情况是比较理想的，那就是各个服务执行自己的那个 Try 操作，都执行成功了，Bingo！

这个时候，就需要依靠 TCC 分布式事务框架来推动后续的执行了。这里简单提一句，如果你要玩儿 TCC 分布式事务，必须引入一款 TCC 分布式事务框架，比如国内开源的 ByteTCC、Himly、TCC-transaction。

否则的话，感知各个阶段的执行情况以及推进执行下一个阶段的这些事情，不太可能自己手写实现，太复杂了。

如果你在各个服务里引入了一个 TCC 分布式事务的框架，订单服务里内嵌的那个 TCC 分布式事务框架可以感知到，各个服务的 Try 操作都成功了。

此时，TCC 分布式事务框架会控制进入 TCC 下一个阶段，第一个 C 阶段，也就是 Confirm 阶段。

为了实现这个阶段，你需要在各个服务里再加入一些代码。比如说，订单服务里，你可以加入一个 Confirm 的逻辑，就是正式把订单的状态设置为“已支付”了，大概是类似下面这样子：

public class OrderServiceConfirm {
    
        public void pay(){
            orderDao.updateStatus(OrderStatus.PAYED);
        }
    }

库存服务也是类似的，你可以有一个 InventoryServiceConfirm 类，里面提供一个 reduceStock() 接口的 Confirm 逻辑，这里就是将之前冻结库存字段的 2 个库存扣掉变为 0。

这样的话，可销售库存之前就已经变为 98 了，现在冻结的 2 个库存也没了，那就正式完成了库存的扣减。

积分服务也是类似的，可以在积分服务里提供一个 CreditServiceConfirm 类，里面有一个 addCredit() 接口的 Confirm 逻辑，就是将预增加字段的 10 个积分扣掉，然后加入实际的会员积分字段中，从 1190 变为 1120。

仓储服务也是类似，可以在仓储服务中提供一个 WmsServiceConfirm 类，提供一个 saleDelivery() 接口的 Confirm 逻辑，将销售出库单的状态正式修改为“已创建”，可以供仓储管理人员查看和使用，而不是停留在之前的中间状态“UNKNOWN”了。

好了，上面各种服务的 Confirm 的逻辑都实现好了，一旦订单服务里面的 TCC 分布式事务框架感知到各个服务的 Try 阶段都成功了以后，就会执行各个服务的 Confirm 逻辑。

订单服务内的 TCC 事务框架会负责跟其他各个服务内的 TCC 事务框架进行通信，依次调用各个服务的 Confirm 逻辑。然后，正式完成各个服务的所有业务逻辑的执行。

同样，给大家来一张图，顺着图一起来看看整个过程：

[![format_png 4][]][format_png 4 1]

## ***3***|***3*****TCC 实现阶段三：Cancel** ##

好，这是比较正常的一种情况，那如果是异常的一种情况呢？

举个例子：在 Try 阶段，比如积分服务吧，它执行出错了，此时会怎么样？

那订单服务内的 TCC 事务框架是可以感知到的，然后它会决定对整个 TCC 分布式事务进行回滚。

也就是说，会执行各个服务的第二个 C 阶段，Cancel 阶段。同样，为了实现这个 Cancel 阶段，各个服务还得加一些代码。

首先订单服务，它得提供一个 OrderServiceCancel 的类，在里面有一个 pay() 接口的 Cancel 逻辑，就是可以将订单的状态设置为“CANCELED”，也就是这个订单的状态是已取消。

库存服务也是同理，可以提供 reduceStock() 的 Cancel 逻辑，就是将冻结库存扣减掉 2，加回到可销售库存里去，98 + 2 = 100。

积分服务也需要提供 addCredit() 接口的 Cancel 逻辑，将预增加积分字段的 10 个积分扣减掉。

仓储服务也需要提供一个 saleDelivery() 接口的 Cancel 逻辑，将销售出库单的状态修改为“CANCELED”设置为已取消。

然后这个时候，订单服务的 TCC 分布式事务框架只要感知到了任何一个服务的 Try 逻辑失败了，就会跟各个服务内的 TCC 分布式事务框架进行通信，然后调用各个服务的 Cancel 逻辑。

大家看看下面的图，直观的感受一下：

[![format_png 5][]][format_png 5 1]

## ***3***|***4*****总结与思考** ##

好了，兄弟们，聊到这儿，基本上大家应该都知道 TCC 分布式事务具体是怎么回事了！

总结一下，你要玩儿 TCC 分布式事务的话：首先需要选择某种 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 都是可以成功的！

最后，再给大家来一张图，来看看给我们的业务，加上分布式事务之后的整个执行流程：

[![format_png 6][]][format_png 6 1]

不少大公司里，其实都是自己研发 TCC 分布式事务框架的，专门在公司内部使用，比如我们就是这样。

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

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

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

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

下面，我们来讲讲可靠消息最终一致性方案实现的分布式事务，同时聊聊在实际生产中遇到的运用该方案的高可用保障架构。

# ***4***|***0*****最终一致性分布式事务如何保障实际生产** #

[https_blog.csdn.net_qq_41854137_article_details_84869850]: https://blog.csdn.net/qq_41854137/article/details/84869850
[https_blog.csdn.net_qq_39291929_article_details_80030841]: https://blog.csdn.net/qq_39291929/article/details/80030841
[https_www.cnblogs.com_jajian_p_10014145.html]: https://www.cnblogs.com/jajian/p/10014145.html
[http_www.tianshouzhi.com_api_tutorials_distributed_transaction_388]: http://www.tianshouzhi.com/api/tutorials/distributed_transaction/388
[format_png]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9pbWcyMDE4LmNuYmxvZ3MuY29tL2Jsb2cvMTE2MjU4Ny8yMDE4MTEvMTE2MjU4Ny0yMDE4MTEyNDIyMTM0NDAwMy0xMDAzNjY0ODU1LnBuZw?x-oss-process=image/format,png
[format_png 1]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9pbWcyMDE4LmNuYmxvZ3MuY29tL2Jsb2cvMTE2MjU4Ny8yMDE4MTEvMTE2MjU4Ny0yMDE4MTEyNDIyMTUxNjUzOC0yMTE3MTY4MTgzLnBuZw?x-oss-process=image/format,png
[format_png 1 1]: https://img2018.cnblogs.com/blog/1162587/201811/1162587-20181124221516538-2117168183.png
[format_png 2]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9pbWcyMDE4LmNuYmxvZ3MuY29tL2Jsb2cvMTE2MjU4Ny8yMDE4MTEvMTE2MjU4Ny0yMDE4MTEyNDIyMTYzOTc4Mi0yNzk1Njc4NjQucG5n?x-oss-process=image/format,png
[format_png 2 1]: https://img2018.cnblogs.com/blog/1162587/201811/1162587-20181124221639782-279567864.png
[format_png 3]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9pbWcyMDE4LmNuYmxvZ3MuY29tL2Jsb2cvMTE2MjU4Ny8yMDE4MTEvMTE2MjU4Ny0yMDE4MTEyNDIzMTc1ODg4My0zMTE3OTExMjEucG5n?x-oss-process=image/format,png
[format_png 3 1]: https://img2018.cnblogs.com/blog/1162587/201811/1162587-20181124231758883-311791121.png
[format_png 4]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9pbWcyMDE4LmNuYmxvZ3MuY29tL2Jsb2cvMTE2MjU4Ny8yMDE4MTEvMTE2MjU4Ny0yMDE4MTEyNDIzMjE0MjgwNi0xMzM5MDg1MTcxLnBuZw?x-oss-process=image/format,png
[format_png 4 1]: https://img2018.cnblogs.com/blog/1162587/201811/1162587-20181124232142806-1339085171.png
[format_png 5]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9pbWcyMDE4LmNuYmxvZ3MuY29tL2Jsb2cvMTE2MjU4Ny8yMDE4MTEvMTE2MjU4Ny0yMDE4MTEyNDIzMjIzNjU3MS00ODQyODgwNTIucG5n?x-oss-process=image/format,png
[format_png 5 1]: https://img2018.cnblogs.com/blog/1162587/201811/1162587-20181124232236571-484288052.png
[format_png 6]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9pbWcyMDE4LmNuYmxvZ3MuY29tL2Jsb2cvMTE2MjU4Ny8yMDE4MTEvMTE2MjU4Ny0yMDE4MTEyNDIzMjQzNDQxNC0xMTA0MzA3ODEucG5n?x-oss-process=image/format,png
[format_png 6 1]: https://img2018.cnblogs.com/blog/1162587/201811/1162587-20181124232434414-110430781.png