We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
很多朋友看了还是不知道分布式事务到底怎么回事，在项目里到底如何使用。 之前在某公司弄微服务时候 用的TCC
tcc: 分布式事务处理器 还有2pc 3pc dtm
看业务场景，假设你现在有一个电商系统，里面有一个支付订单的场景。
TCC是分布式事务中非常经典的模式，但即使借助框架实现，代码实现也比较复杂。 实际使用时需要考虑服务集群、空提交、幂等、空回滚、悬挂等问题。
TCC 分别对应 Try、Confirm 和 Cancel 三种操作，这三种操作的业务含义如下： Try：预留业务资源 Confirm：确认执行业务操作 Cancel：取消执行业务操作 稍稍对照下关系型数据库事务的三种操作：DML、Commit 和 Rollback，会发现和 TCC 有异曲同工之妙。 在一个跨应用的业务操作中，Try 操作是先把多个应用中的业务资源预留和锁定住，为后续的确认打下基础， 类似的，DML 操作要锁定数据库记录行，持有数据库资源；Confirm 操作是在 Try 操作中涉及的所有应用均成功之后进行确认， 使用预留的业务资源，和 Commit 类似；而 Cancel 则是当 Try 操作中涉及的所有应用没有全部成功， 需要将已成功的应用进行取消 (即 Rollback 回滚)。其中 Confirm 和 Cancel 操作是一对反向业务操作。
那对一个订单支付之后，我们需要做下面的步骤：
更改订单的状态为“已支付” 扣减商品库存 给会员增加积分 创建销售出库单通知仓库发货 这是一系列比较真实的步骤，无论大家有没有做过电商系统，应该都能理解。
什么意思呢？也就是说，[1] 订单服务-修改订单状态，[2] 库存服务-扣减库存，[3] 积分服务-增加积分，[4] 仓储服务-创建销售出库单。
上述这几个步骤，要么一起成功，要么一起失败，必须是一个整体性的事务。
举个例子，现在订单的状态都修改为“已支付”了，结果库存服务扣减库存失败。那个商品的库存原来是 100 件，现在卖掉了 2 件，本来应该是 98 件了。
结果呢？由于库存服务操作数据库异常，导致库存数量还是 100。这不是在坑人么，当然不能允许这种情况发生了！
使用 TCC 分布式事务机制来保证各个服务形成一个整体性的事务。
上面那几个步骤，要么全部成功，如果任何一个服务的操作失败了，就全部一起回滚，撤销已经完成的操作。
比如说库存服务要是扣减库存失败了，那么订单服务就得撤销那个修改订单状态的操作，然后得停止执行增加积分和通知出库两个操作。
说了那么多，老规矩，给大家上一张图，大伙儿顺着图来直观的感受一下：
然后就分成两种情况了，第一种情况是比较理想的，那就是各个服务执行自己的那个 Try 操作，都执行成功了，Bingo！
这个时候，就需要依靠 TCC 分布式事务框架来推动后续的执行了。这里简单提一句，如果你要玩儿 TCC 分布式事务，必须引入一款 TCC 分布式事务框架，比如国内开源的 ByteTCC、Himly、TCC-transaction。
否则的话，感知各个阶段的执行情况以及推进执行下一个阶段的这些事情，不太可能自己手写实现，太复杂了。
如果你在各个服务里引入了一个 TCC 分布式事务的框架，订单服务里内嵌的那个 TCC 分布式事务框架可以感知到，各个服务的 Try 操作都成功了。
此时，TCC 分布式事务框架会控制进入 TCC 下一个阶段，第一个 C 阶段，也就是 Confirm 阶段。
为了实现这个阶段，你需要在各个服务里再加入一些代码。比如说，订单服务里，你可以加入一个 Confirm 的逻辑，就是正式把订单的状态设置为“已支付”了，
库存服务也是类似的，你可以有一个 InventoryServiceConfirm 类，里面提供一个 reduceStock() 接口的 Confirm 逻辑，这里就是将之前冻结库存字段的 2 个库存扣掉变为 0。
这样的话，可销售库存之前就已经变为 98 了，现在冻结的 2 个库存也没了，那就正式完成了库存的扣减。
积分服务也是类似的，可以在积分服务里提供一个 CreditServiceConfirm 类，里面有一个 addCredit() 接口的 Confirm 逻辑，就是将预增加字段的 10 个积分扣掉，然后加入实际的会员积分字段中，从 1190 变为 1120。
仓储服务也是类似，可以在仓储服务中提供一个 WmsServiceConfirm 类，提供一个 saleDelivery() 接口的 Confirm 逻辑，将销售出库单的状态正式修改为“已创建”，可以供仓储管理人员查看和使用，而不是停留在之前的中间状态“UNKNOWN”了。
好了，上面各种服务的 Confirm 的逻辑都实现好了，一旦订单服务里面的 TCC 分布式事务框架感知到各个服务的 Try 阶段都成功了以后，就会执行各个服务的 Confirm 逻辑。
订单服务内的 TCC 事务框架会负责跟其他各个服务内的 TCC 事务框架进行通信，依次调用各个服务的 Confirm 逻辑。然后，正式完成各个服务的所有业务逻辑的执行。
举个例子：在 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 逻辑。
聊到这儿，基本上大家应该都知道 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 都是可以成功的！
对于常见的微服务系统，大部分接口调用是同步的，也就是一个服务直接调用另外一个服务的接口。
这个时候，用 TCC 分布式事务方案来保证各个接口的调用，要么一起成功，要么一起回滚，是比较合适的。
但是在实际系统的开发过程中，可能服务间的调用是异步的。也就是说，一个服务发送一个消息给 MQ，即消息中间件，比如 RocketMQ、RabbitMQ、Kafka、ActiveMQ 等等。
然后，另外一个服务从 MQ 消费到一条消息后进行处理。这就成了基于 MQ 的异步调用了。
那么针对这种基于 MQ 的异步调用，如何保证各个服务间的分布式事务呢？也就是说，我希望的是基于 MQ 实现异步调用的多个服务的业务逻辑，要么一起成功，要么一起失败。
这个时候，就要用上可靠消息最终一致性方案，来实现分布式事务。
看上图，如果不考虑各种高并发、高可用等技术挑战的话，单从“可靠消息”以及“最终一致性”两个角度来考虑，这种分布式事务方案还是比较简单的。
可靠消息最终一致性方案的核心流程[#] ①上游服务投递消息[#] 如果要实现可靠消息最终一致性方案，一般你可以自己写一个可靠消息服务，实现一些业务逻辑。
首先，上游服务需要发送一条消息给可靠消息服务。这条消息说白了，你可以认为是对下游服务一个接口的调用，里面包含了对应的一些请求参数。
然后，可靠消息服务就得把这条消息存储到自己的数据库里去，状态为“待确认”。
接着，上游服务就可以执行自己本地的数据库操作，根据自己的执行结果，再次调用可靠消息服务的接口。
如果本地数据库操作执行成功了，那么就找可靠消息服务确认那条消息。如果本地数据库操作失败了，那么就找可靠消息服务删除那条消息。
此时如果是确认消息，那么可靠消息服务就把数据库里的消息状态更新为“已发送”，同时将消息发送给 MQ。
这里有一个很关键的点，就是更新数据库里的消息状态和投递消息到 MQ。这俩操作，你得放在一个方法里，而且得开启本地事务。
啥意思呢？如果数据库里更新消息的状态失败了，那么就抛异常退出了，就别投递到 MQ；如果投递 MQ 失败报错了，那么就要抛异常让本地数据库事务回滚。这俩操作必须得一起成功，或者一起失败。
如果上游服务是通知删除消息，那么可靠消息服务就得删除这条消息。
②下游服务接收消息[#] 下游服务就一直等着从 MQ 消费消息好了，如果消费到了消息，那么就操作自己本地数据库。
如果操作成功了，就反过来通知可靠消息服务，说自己处理成功了，然后可靠消息服务就会把消息的状态设置为“已完成”。
③如何保证上游服务对消息的 100% 可靠投递？[#] 上面的核心流程大家都看完：一个很大的问题就是，如果在上述投递消息的过程中各个环节出现了问题该怎么办？
我们如何保证消息 100% 的可靠投递，一定会从上游服务投递到下游服务？别着急，下面我们来逐一分析。
如果上游服务给可靠消息服务发送待确认消息的过程出错了，那没关系，上游服务可以感知到调用异常的，就不用执行下面的流程了，这是没问题的。
如果上游服务操作完本地数据库之后，通知可靠消息服务确认消息或者删除消息的时候，出现了问题。
比如：没通知成功，或者没执行成功，或者是可靠消息服务没成功的投递消息到 MQ。这一系列步骤出了问题怎么办？
其实也没关系，因为在这些情况下，那条消息在可靠消息服务的数据库里的状态会一直是“待确认”。
此时，我们在可靠消息服务里开发一个后台定时运行的线程，不停的检查各个消息的状态。
如果一直是“待确认”状态，就认为这个消息出了点什么问题。此时的话，就可以回调上游服务提供的一个接口，问问说，兄弟，这个消息对应的数据库操作，你执行成功了没啊？
如果上游服务答复说，我执行成功了，那么可靠消息服务将消息状态修改为“已发送”，同时投递消息到 MQ。
如果上游服务答复说，没执行成功，那么可靠消息服务将数据库中的消息删除即可。
通过这套机制，就可以保证，可靠消息服务一定会尝试完成消息到 MQ 的投递。
④如何保证下游服务对消息的 100% 可靠接收？[#] 那如果下游服务消费消息出了问题，没消费到？或者是下游服务对消息的处理失败了，怎么办？
其实也没关系，在可靠消息服务里开发一个后台线程，不断的检查消息状态。
如果消息状态一直是“已发送”，始终没有变成“已完成”，那么就说明下游服务始终没有处理成功。
此时可靠消息服务就可以再次尝试重新投递消息到 MQ，让下游服务来再次处理。
只要下游服务的接口逻辑实现幂等性，保证多次处理一个消息，不会插入重复数据即可。
⑤如何基于 RocketMQ 来实现可靠消息最终一致性方案？[#] 在上面的通用方案设计里，完全依赖可靠消息服务的各种自检机制来确保：
如果上游服务的数据库操作没成功，下游服务是不会收到任何通知。 如果上游服务的数据库操作成功了，可靠消息服务死活都会确保将一个调用消息投递给下游服务，而且一定会确保下游服务务必成功处理这条消息。 通过这套机制，保证了基于 MQ 的异步调用/通知的服务间的分布式事务保障。其实阿里开源的 RocketMQ，就实现了可靠消息服务的所有功能，核心思想跟上面类似。
只不过 RocketMQ 为了保证高并发、高可用、高性能，做了较为复杂的架构实现，非常的优秀。有兴趣的同学，自己可以去查阅 RocketMQ 对分布式事务的支持。
可靠消息最终一致性方案的高可用保障生产实践[#] 背景引入[#] 上面那套方案和思想，很多同学应该都知道是怎么回事儿，我们也主要就是铺垫一下这套理论思想。
在实际落地生产的时候，如果没有高并发场景的，完全可以参照上面的思路自己基于某个 MQ 中间件开发一个可靠消息服务。
如果有高并发场景的，可以用 RocketMQ 的分布式事务支持上面的那套流程都可以实现。
今天给大家分享的一个核心主题，就是这套方案如何保证 99.99% 的高可用。
大家应该发现了这套方案里保障高可用性最大的一个依赖点，就是 MQ 的高可用性。
任何一种 MQ 中间件都有一整套的高可用保障机制，无论是 RabbitMQ、RocketMQ 还是 Kafka。
所以在大公司里使用可靠消息最终一致性方案的时候，我们通常对可用性的保障都是依赖于公司基础架构团队对 MQ 的高可用保障。
也就是说，大家应该相信兄弟团队，99.99% 可以保障 MQ 的高可用，绝对不会因为 MQ 集群整体宕机，而导致公司业务系统的分布式事务全部无法运行。
但是现实是很残酷的，很多中小型的公司，甚至是一些中大型公司，或多或少都遇到过 MQ 集群整体故障的场景。
MQ 一旦完全不可用，就会导致业务系统的各个服务之间无法通过 MQ 来投递消息，导致业务流程中断。
比如最近就有一个朋友的公司，也是做电商业务的，就遇到了 MQ 中间件在自己公司机器上部署的集群整体故障不可用，导致依赖 MQ 的分布式事务全部无法跑通，业务流程大量中断的情况。
这种情况，就需要针对这套分布式事务方案实现一套高可用保障机制。
从事务中心拿xid 调用try 传惨xid以及业务参数 $xid = $this->tccService->getRegisterXid();
$this->tccService->confirm($xid); $this->tccService->cancel($xid);
try 根据xid 并传回调confirm_url和 cancel_url 从基础中心 返回新xid2 confirm cancel
https://dtm.pub/
https://mp.weixin.qq.com/s?__biz=MzU2NTEyNjIzMw==&mid=2247485816&idx=1&sn=b804bf9d7f2bfa3826405cb955cc0db7&chksm=fc413c4ecb36b558f774b48da1a45a4c2d0e2848bf73250a2ba69b6969e55be7c5e152e7bced&mpshare=1&scene=1&srcid=0608fe1xfHDE3RjXoMzmsLr3&sharer_sharetime=1623140147592&sharer_shareid=29b55bed57b47675ad205bcd9509c2f3#rd
https://dtm.pub/ https://github.com/dtm-php/dtm-client/ dtm https://www.cnblogs.com/jajian/p/10014145.html https://developer.51cto.com/article/648202.html tcc事务原理 https://www.jianshu.com/p/a7d1c4f2542c 二阶消息的理解
https://dtm.pub/practice/tcc.html#%E5%A4%B1%E8%B4%A5%E5%9B%9E%E6%BB%9A
The text was updated successfully, but these errors were encountered:
No branches or pull requests
很多朋友看了还是不知道分布式事务到底怎么回事，在项目里到底如何使用。
之前在某公司弄微服务时候 用的TCC
tcc: 分布式事务处理器 还有2pc 3pc
dtm
什么是 TCC 分布式事务
看业务场景，假设你现在有一个电商系统，里面有一个支付订单的场景。
TCC是分布式事务中非常经典的模式，但即使借助框架实现，代码实现也比较复杂。
实际使用时需要考虑服务集群、空提交、幂等、空回滚、悬挂等问题。
TCC 分别对应 Try、Confirm 和 Cancel 三种操作，这三种操作的业务含义如下：
Try：预留业务资源
Confirm：确认执行业务操作
Cancel：取消执行业务操作
稍稍对照下关系型数据库事务的三种操作：DML、Commit 和 Rollback，会发现和 TCC 有异曲同工之妙。
在一个跨应用的业务操作中，Try 操作是先把多个应用中的业务资源预留和锁定住，为后续的确认打下基础，
类似的，DML 操作要锁定数据库记录行，持有数据库资源；Confirm 操作是在 Try 操作中涉及的所有应用均成功之后进行确认，
使用预留的业务资源，和 Commit 类似；而 Cancel 则是当 Try 操作中涉及的所有应用没有全部成功，
需要将已成功的应用进行取消 (即 Rollback 回滚)。其中 Confirm 和 Cancel 操作是一对反向业务操作。
那对一个订单支付之后，我们需要做下面的步骤：
更改订单的状态为“已支付”
扣减商品库存
给会员增加积分
创建销售出库单通知仓库发货
这是一系列比较真实的步骤，无论大家有没有做过电商系统，应该都能理解。
实现一个 TCC 分布式事务的效果。
什么意思呢？也就是说，[1] 订单服务-修改订单状态，[2] 库存服务-扣减库存，[3] 积分服务-增加积分，[4] 仓储服务-创建销售出库单。
上述这几个步骤，要么一起成功，要么一起失败，必须是一个整体性的事务。
举个例子，现在订单的状态都修改为“已支付”了，结果库存服务扣减库存失败。那个商品的库存原来是 100 件，现在卖掉了 2 件，本来应该是 98 件了。
结果呢？由于库存服务操作数据库异常，导致库存数量还是 100。这不是在坑人么，当然不能允许这种情况发生了！
使用 TCC 分布式事务机制来保证各个服务形成一个整体性的事务。
上面那几个步骤，要么全部成功，如果任何一个服务的操作失败了，就全部一起回滚，撤销已经完成的操作。
比如说库存服务要是扣减库存失败了，那么订单服务就得撤销那个修改订单状态的操作，然后得停止执行增加积分和通知出库两个操作。
说了那么多，老规矩，给大家上一张图，大伙儿顺着图来直观的感受一下：
TCC 实现阶段一：Try
TCC 实现阶段二：Confirm
然后就分成两种情况了，第一种情况是比较理想的，那就是各个服务执行自己的那个 Try 操作，都执行成功了，Bingo！
这个时候，就需要依靠 TCC 分布式事务框架来推动后续的执行了。这里简单提一句，如果你要玩儿 TCC 分布式事务，必须引入一款 TCC 分布式事务框架，比如国内开源的 ByteTCC、Himly、TCC-transaction。
否则的话，感知各个阶段的执行情况以及推进执行下一个阶段的这些事情，不太可能自己手写实现，太复杂了。
如果你在各个服务里引入了一个 TCC 分布式事务的框架，订单服务里内嵌的那个 TCC 分布式事务框架可以感知到，各个服务的 Try 操作都成功了。
此时，TCC 分布式事务框架会控制进入 TCC 下一个阶段，第一个 C 阶段，也就是 Confirm 阶段。
为了实现这个阶段，你需要在各个服务里再加入一些代码。比如说，订单服务里，你可以加入一个 Confirm 的逻辑，就是正式把订单的状态设置为“已支付”了，
库存服务也是类似的，你可以有一个 InventoryServiceConfirm 类，里面提供一个 reduceStock() 接口的 Confirm 逻辑，这里就是将之前冻结库存字段的 2 个库存扣掉变为 0。
这样的话，可销售库存之前就已经变为 98 了，现在冻结的 2 个库存也没了，那就正式完成了库存的扣减。
积分服务也是类似的，可以在积分服务里提供一个 CreditServiceConfirm 类，里面有一个 addCredit() 接口的 Confirm 逻辑，就是将预增加字段的 10 个积分扣掉，然后加入实际的会员积分字段中，从 1190 变为 1120。
仓储服务也是类似，可以在仓储服务中提供一个 WmsServiceConfirm 类，提供一个 saleDelivery() 接口的 Confirm 逻辑，将销售出库单的状态正式修改为“已创建”，可以供仓储管理人员查看和使用，而不是停留在之前的中间状态“UNKNOWN”了。
好了，上面各种服务的 Confirm 的逻辑都实现好了，一旦订单服务里面的 TCC 分布式事务框架感知到各个服务的 Try 阶段都成功了以后，就会执行各个服务的 Confirm 逻辑。
订单服务内的 TCC 事务框架会负责跟其他各个服务内的 TCC 事务框架进行通信，依次调用各个服务的 Confirm 逻辑。然后，正式完成各个服务的所有业务逻辑的执行。
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 逻辑。
总结
聊到这儿，基本上大家应该都知道 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 都是可以成功的！
高可用
对于常见的微服务系统，大部分接口调用是同步的，也就是一个服务直接调用另外一个服务的接口。
这个时候，用 TCC 分布式事务方案来保证各个接口的调用，要么一起成功，要么一起回滚，是比较合适的。
但是在实际系统的开发过程中，可能服务间的调用是异步的。也就是说，一个服务发送一个消息给 MQ，即消息中间件，比如 RocketMQ、RabbitMQ、Kafka、ActiveMQ 等等。
然后，另外一个服务从 MQ 消费到一条消息后进行处理。这就成了基于 MQ 的异步调用了。
那么针对这种基于 MQ 的异步调用，如何保证各个服务间的分布式事务呢？也就是说，我希望的是基于 MQ 实现异步调用的多个服务的业务逻辑，要么一起成功，要么一起失败。
这个时候，就要用上可靠消息最终一致性方案，来实现分布式事务。
看上图，如果不考虑各种高并发、高可用等技术挑战的话，单从“可靠消息”以及“最终一致性”两个角度来考虑，这种分布式事务方案还是比较简单的。
可靠消息最终一致性方案的核心流程[#]
①上游服务投递消息[#]
如果要实现可靠消息最终一致性方案，一般你可以自己写一个可靠消息服务，实现一些业务逻辑。
首先，上游服务需要发送一条消息给可靠消息服务。这条消息说白了，你可以认为是对下游服务一个接口的调用，里面包含了对应的一些请求参数。
然后，可靠消息服务就得把这条消息存储到自己的数据库里去，状态为“待确认”。
接着，上游服务就可以执行自己本地的数据库操作，根据自己的执行结果，再次调用可靠消息服务的接口。
如果本地数据库操作执行成功了，那么就找可靠消息服务确认那条消息。如果本地数据库操作失败了，那么就找可靠消息服务删除那条消息。
此时如果是确认消息，那么可靠消息服务就把数据库里的消息状态更新为“已发送”，同时将消息发送给 MQ。
这里有一个很关键的点，就是更新数据库里的消息状态和投递消息到 MQ。这俩操作，你得放在一个方法里，而且得开启本地事务。
啥意思呢？如果数据库里更新消息的状态失败了，那么就抛异常退出了，就别投递到 MQ；如果投递 MQ 失败报错了，那么就要抛异常让本地数据库事务回滚。这俩操作必须得一起成功，或者一起失败。
如果上游服务是通知删除消息，那么可靠消息服务就得删除这条消息。
②下游服务接收消息[#]
下游服务就一直等着从 MQ 消费消息好了，如果消费到了消息，那么就操作自己本地数据库。
如果操作成功了，就反过来通知可靠消息服务，说自己处理成功了，然后可靠消息服务就会把消息的状态设置为“已完成”。
③如何保证上游服务对消息的 100% 可靠投递？[#]
上面的核心流程大家都看完：一个很大的问题就是，如果在上述投递消息的过程中各个环节出现了问题该怎么办？
我们如何保证消息 100% 的可靠投递，一定会从上游服务投递到下游服务？别着急，下面我们来逐一分析。
如果上游服务给可靠消息服务发送待确认消息的过程出错了，那没关系，上游服务可以感知到调用异常的，就不用执行下面的流程了，这是没问题的。
如果上游服务操作完本地数据库之后，通知可靠消息服务确认消息或者删除消息的时候，出现了问题。
比如：没通知成功，或者没执行成功，或者是可靠消息服务没成功的投递消息到 MQ。这一系列步骤出了问题怎么办？
其实也没关系，因为在这些情况下，那条消息在可靠消息服务的数据库里的状态会一直是“待确认”。
此时，我们在可靠消息服务里开发一个后台定时运行的线程，不停的检查各个消息的状态。
如果一直是“待确认”状态，就认为这个消息出了点什么问题。此时的话，就可以回调上游服务提供的一个接口，问问说，兄弟，这个消息对应的数据库操作，你执行成功了没啊？
如果上游服务答复说，我执行成功了，那么可靠消息服务将消息状态修改为“已发送”，同时投递消息到 MQ。
如果上游服务答复说，没执行成功，那么可靠消息服务将数据库中的消息删除即可。
通过这套机制，就可以保证，可靠消息服务一定会尝试完成消息到 MQ 的投递。
④如何保证下游服务对消息的 100% 可靠接收？[#]
那如果下游服务消费消息出了问题，没消费到？或者是下游服务对消息的处理失败了，怎么办？
其实也没关系，在可靠消息服务里开发一个后台线程，不断的检查消息状态。
如果消息状态一直是“已发送”，始终没有变成“已完成”，那么就说明下游服务始终没有处理成功。
此时可靠消息服务就可以再次尝试重新投递消息到 MQ，让下游服务来再次处理。
只要下游服务的接口逻辑实现幂等性，保证多次处理一个消息，不会插入重复数据即可。
⑤如何基于 RocketMQ 来实现可靠消息最终一致性方案？[#]
在上面的通用方案设计里，完全依赖可靠消息服务的各种自检机制来确保：
如果上游服务的数据库操作没成功，下游服务是不会收到任何通知。
如果上游服务的数据库操作成功了，可靠消息服务死活都会确保将一个调用消息投递给下游服务，而且一定会确保下游服务务必成功处理这条消息。
通过这套机制，保证了基于 MQ 的异步调用/通知的服务间的分布式事务保障。其实阿里开源的 RocketMQ，就实现了可靠消息服务的所有功能，核心思想跟上面类似。
只不过 RocketMQ 为了保证高并发、高可用、高性能，做了较为复杂的架构实现，非常的优秀。有兴趣的同学，自己可以去查阅 RocketMQ 对分布式事务的支持。
可靠消息最终一致性方案的高可用保障生产实践[#]
背景引入[#]
上面那套方案和思想，很多同学应该都知道是怎么回事儿，我们也主要就是铺垫一下这套理论思想。
在实际落地生产的时候，如果没有高并发场景的，完全可以参照上面的思路自己基于某个 MQ 中间件开发一个可靠消息服务。
如果有高并发场景的，可以用 RocketMQ 的分布式事务支持上面的那套流程都可以实现。
今天给大家分享的一个核心主题，就是这套方案如何保证 99.99% 的高可用。
大家应该发现了这套方案里保障高可用性最大的一个依赖点，就是 MQ 的高可用性。
任何一种 MQ 中间件都有一整套的高可用保障机制，无论是 RabbitMQ、RocketMQ 还是 Kafka。
所以在大公司里使用可靠消息最终一致性方案的时候，我们通常对可用性的保障都是依赖于公司基础架构团队对 MQ 的高可用保障。
也就是说，大家应该相信兄弟团队，99.99% 可以保障 MQ 的高可用，绝对不会因为 MQ 集群整体宕机，而导致公司业务系统的分布式事务全部无法运行。
但是现实是很残酷的，很多中小型的公司，甚至是一些中大型公司，或多或少都遇到过 MQ 集群整体故障的场景。
MQ 一旦完全不可用，就会导致业务系统的各个服务之间无法通过 MQ 来投递消息，导致业务流程中断。
比如最近就有一个朋友的公司，也是做电商业务的，就遇到了 MQ 中间件在自己公司机器上部署的集群整体故障不可用，导致依赖 MQ 的分布式事务全部无法跑通，业务流程大量中断的情况。
这种情况，就需要针对这套分布式事务方案实现一套高可用保障机制。
php
从事务中心拿xid
调用try 传惨xid以及业务参数
$xid = $this->tccService->getRegisterXid();
$this->tccService->confirm($xid);
$this->tccService->cancel($xid);
try 根据xid 并传回调confirm_url和 cancel_url 从基础中心 返回新xid2
confirm
cancel
https://dtm.pub/
链接
https://mp.weixin.qq.com/s?__biz=MzU2NTEyNjIzMw==&mid=2247485816&idx=1&sn=b804bf9d7f2bfa3826405cb955cc0db7&chksm=fc413c4ecb36b558f774b48da1a45a4c2d0e2848bf73250a2ba69b6969e55be7c5e152e7bced&mpshare=1&scene=1&srcid=0608fe1xfHDE3RjXoMzmsLr3&sharer_sharetime=1623140147592&sharer_shareid=29b55bed57b47675ad205bcd9509c2f3#rd
https://dtm.pub/
https://github.com/dtm-php/dtm-client/ dtm
https://www.cnblogs.com/jajian/p/10014145.html
https://developer.51cto.com/article/648202.html tcc事务原理
https://www.jianshu.com/p/a7d1c4f2542c 二阶消息的理解
https://dtm.pub/practice/tcc.html#%E5%A4%B1%E8%B4%A5%E5%9B%9E%E6%BB%9A
The text was updated successfully, but these errors were encountered: