分布式事物解决方案

在分布式开发中，当系统被拆分成多个模块之后，一个看似简单的功能，内部可能需要调用多个服务并操作多个数据库实现，服务调用的分布式事务问题变的非常突出。本文主要介绍一下分布式开发中常用的解决方案。
常用的分布式解决方案有如下方案，基于XA协议的二阶段、三阶段提交、基于MQ消息队列的最终一致性方案，TCC、Saga，还有阿里刚开源不就的Fescar。本文主要对这些理论做介绍，后面还会对这些理论的实现方案做具体的介绍，所以Fescar也在后面介绍。

 

什么是分布式事务问题？

首先，设想一个传统的单体应用（Monolithic App），通过 3 个 Module，在同一个数据源上更新数据来完成一项业务。很自然的，整个业务过程的数据一致性由本地事务来保证。

随着业务需求和架构的变化，单体应用被拆分为微服务：原来的 3 个 Module 被拆分为 3 个独立的服务，分别使用独立的数据源（Pattern: Database per service）。

---

业务过程将由 3 个服务的调用来完成。此时，每一个服务内部的数据一致性仍有本地事务来保证。而整个业务层面的全局数据一致性要如何保障呢？这就是微服务架构下面临的，典型的分布式事务需求。

基于XA协议的解决方案

XA协议和X/Open DTP模型

要了解XA协议，必须先了解X/Open DTP模型，稍微总结一下：

X/Open DTP(Distributed Transaction Process)是一个分布式事务模型。这个模型主要使用了两段提交(2PC - Two-Phase-Commit)来保证分布式事务的完整性。在这个模型里面，有三个角色：

• AP: Application，应用程序。也就是业务层。哪些操作属于一个事务，就是AP定义的。
• TM: Transaction Manager，事务管理器。接收AP的事务请求，对全局事务进行管理，管理事务分支状态，协调RM的处理，通知RM哪些操作属于哪些全局事务以及事务分支等等。这个也是整个事务调度模型的核心部分。
• RM：Resource Manager，资源管理器。一般是数据库，也可以是其他的资源管理器，如消息队列(如JMS数据源)，文件系统等。

三者之间的关系如图：

而XA协议(XA Specification)，指的是TM和RM之间的接口。

二阶段提交

二阶段提交从字面意思来说就是将事物的提交划分为俩个阶段

事务的发起者称协调者，事务的执行者称参与者。

处理流程：

　　1、准备阶段

　　　　事务协调者，向所有事务参与者发送事务内容，询问是否可以提交事务，并等待参与者回复。

　　　　事务参与者收到事务内容，开始执行事务操作，讲 undo 和 redo  信息记入事务日志中（但此时并不提交事务）。

　　　　如果参与者执行成功，给协调者回复yes,表示可以进行事务提交。如果执行失败，给协调者回复no,表示不可提交。

　　2、提交阶段

　　　　如果协调者收到了参与者的失败信息或超时信息，直接给所有参与者发送回滚（rollback）信息进行事务回滚，否则，发送提交（commit）信息。

　　　　参与者根据协调者的指令执行提交或者回滚操作，释放所有事务处理过程中使用的锁资源。(注意：必须在最后阶段释放锁资源) 接下来分两种情况分别讨论提交阶段的过程。

二阶段提交看起来确实能够提供原子性的操作，但是不幸的事，二阶段提交还是有几个缺点的：

1、同步阻塞问题。执行过程中，所有参与节点都是事务阻塞型的。当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态。

2、单点故障。由于协调者的重要性，一旦协调者发生故障。参与者会一直阻塞下去。尤其在第二阶段，协调者发生故障，那么所有的参与者还都处于锁定事务资源的状态中，而无法继续完成事务操作。（如果是协调者挂掉，可以重新选举一个协调者，但是无法解决因为协调者宕机导致的参与者处于阻塞状态的问题）

3、数据不一致。在二阶段提交的阶段二中，当协调者向参与者发送commit请求之后，发生了局部网络异常或者在发送commit请求过程中协调者发生了故障，这回导致只有一部分参与者接受到了commit请求。而在这部分参与者接到commit请求之后就会执行commit操作。但是其他部分未接到commit请求的机器则无法执行事务提交。于是整个分布式系统便出现了数据部一致性的现象。

4、二阶段无法解决的问题：协调者再发出commit消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了。那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交。

三阶段提交

3PC,就是三阶段提交协议，顾名思义，就是把事务的提交过程分为三个阶段，实际上它就是在原来二阶段提交上做了一部分改进。

与两阶段提交不同的是，三阶段提交有两个改动点：
        引入超时机制(同时在协调者和参与者中都引入超时机制);

        在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的;

也就是说，除了引入超时机制之外，3PC把2PC的准备阶段再次一分为二，这样三阶段提交就有CanCommit、PreCommit、DoCommit三个阶段。


CanCommit阶段
        事务询问：协调者向参与者发送CanCommit请求。询问是否可以执行事务提交操作。然后开始等待参与者的响应；

        响应反馈：参与者接到CanCommit请求之后，正常情况下，如果其自身认为可以顺利执行事务，则返回Yes响应，并进入预备状态。否则反馈No；

 PreCommit阶段
        协调者根据参与者的反应情况来决定是否可以进行事务的PreCommit操作。根据响应情况，有以下两种可能：

        假如协调者从所有的参与者获得的反馈都是Yes响应，那么就会执行事务的预执行。

        发送预提交请求：协调者向参与者发送PreCommit请求，并进入Prepared阶段；

        事务预提交：参与者接收到PreCommit请求后，会执行事务操作，并将undo和redo信息记录到事务日志中；

        响应反馈：如果参与者成功的执行了事务操作，则返回ACK响应，同时开始等待最终指令；

假如有任何一个参与者向协调者发送了No响应，或者等待超时之后，协调者都没有接到参与者的响应，那么就执行事务的中断。

        发送中断请求：协调者向所有参与者发送abort请求；

        中断事务：参与者收到来自协调者的abort请求之后（或超时之后，仍未收到协调者的请求），执行事务的中断；

 doCommit阶段
该阶段进行真正的事务提交，也可以分为以下两种情况：

执行提交
        发送提交请求：协调接收到参与者发送的ACK响应，那么他将从预提交状态进入到提交状态。并向所有参与者发送doCommit请求;
        事务提交:参与者接收到doCommit请求之后，执行正式的事务提交。并在完成事务提交之后释放所有事务资源;
        响应反馈:事务提交完之后，向协调者发送Ack响应;
        完成事务:协调者接收到所有参与者的ack响应之后完成事务;

中断事务(协调者没有接收到参与者发送的ACK响应)
        发送中断请求:协调者向所有参与者发送abort请求;
        事务回滚:参与者接收到abort请求之后，利用其在阶段二记录的undo信息来执行事务的回滚操作，并在完成回滚之后释放所有的事务资源;
        反馈结果:参与者完成事务回滚之后，向协调者发送ACK消息;
        中断事务:协调者接收到参与者反馈的ACK消息之后，执行事务的中断;

2PC与3PC的区别

相对于2PC，3PC主要解决的单点故障问题，并减少阻塞，因为一旦参与者无法及时收到来自协调者的信息之后，他会默认执行commit。而不会一直持有事务资源并处于阻塞状态。但是这种机制也会导致数据一致性问题，因为，由于网络原因，协调者发送的abort响应没有及时被参与者接收到，那么参与者在等待超时之后执行了commit操作。这样就和其他接到abort命令并执行回滚的参与者之间存在数据不一致的情况。

TCC 事务：最终一致性

方案简介

TCC（Try-Confirm-Cancel）的概念，最早是由 Pat Helland 于 2007 年发表的一篇名为《Life beyond Distributed Transactions:an Apostate’s Opinion》的论文提出。

TCC 是服务化的二阶段编程模型，其 Try、Confirm、Cancel 3 个方法均由业务编码实现：

• Try 操作作为一阶段，负责资源的检查和预留。
• Confirm 操作作为二阶段提交操作，执行真正的业务。
• Cancel 是预留资源的取消。

TCC 事务的 Try、Confirm、Cancel 可以理解为 SQL 事务中的 Lock、Commit、Rollback。

处理流程

为了方便理解，下面以电商下单为例进行方案解析，这里把整个过程简单分为扣减库存，订单创建 2 个步骤，库存服务和订单服务分别在不同的服务器节点上。

Try 阶段

从执行阶段来看，与传统事务机制中业务逻辑相同。但从业务角度来看，却不一样。

TCC 机制中的 Try 仅是一个初步操作，它和后续的确认一起才能真正构成一个完整的业务逻辑，这个阶段主要完成：

• 完成所有业务检查( 一致性 ) 。
• 预留必须业务资源( 准隔离性 ) 。
• Try 尝试执行业务。

TCC 事务机制以初步操作（Try）为中心的，确认操作（Confirm）和取消操作（Cancel）都是围绕初步操作（Try）而展开。

因此，Try 阶段中的操作，其保障性是最好的，即使失败，仍然有取消操作（Cancel）可以将其执行结果撤销。

假设商品库存为 100，购买数量为 2，这里检查和更新库存的同时，冻结用户购买数量的库存，同时创建订单，订单状态为待确认。

Confirm / Cancel 阶段

根据 Try 阶段服务是否全部正常执行，继续执行确认操作（Confirm）或取消操作（Cancel）。

Confirm 和 Cancel 操作满足幂等性，如果 Confirm 或 Cancel 操作执行失败，将会不断重试直到执行完成。

Confirm：当 Try 阶段服务全部正常执行， 执行确认业务逻辑操作

这里使用的资源一定是 Try 阶段预留的业务资源。在 TCC 事务机制中认为，如果在 Try 阶段能正常的预留资源，那 Confirm 一定能完整正确的提交。

Confirm 阶段也可以看成是对 Try 阶段的一个补充，Try+Confirm 一起组成了一个完整的业务逻辑。

Cancel：当 Try 阶段存在服务执行失败， 进入 Cancel 阶段

Cancel 取消执行，释放 Try 阶段预留的业务资源，上面的例子中，Cancel 操作会把冻结的库存释放，并更新订单状态为取消。

方案总结

TCC 事务机制相对于传统事务机制（X/Open XA），TCC 事务机制相比于上面介绍的 XA 事务机制，有以下优点：

• 性能提升：具体业务来实现控制资源锁的粒度变小，不会锁定整个资源。
• 数据最终一致性：基于 Confirm 和 Cancel 的幂等性，保证事务最终完成确认或者取消，保证数据的一致性。
• 可靠性：解决了 XA 协议的协调者单点故障问题，由主业务方发起并控制整个业务活动，业务活动管理器也变成多点，引入集群。

缺点： TCC 的 Try、Confirm 和 Cancel 操作功能要按具体业务来实现，业务耦合度较高，提高了开发成本。

MQ 事务：最终一致性

方案简介

基于 MQ 的分布式事务方案其实是对本地消息表的封装，将本地消息表基于 MQ 内部，其他方面的协议基本与本地消息表一致。

处理流程

下面主要基于 RocketMQ 4.3 之后的版本介绍 MQ 的分布式事务方案。

在本地消息表方案中，保证事务主动方发写业务表数据和写消息表数据的一致性是基于数据库事务，RocketMQ 的事务消息相对于普通 MQ，相对于提供了 2PC 的提交接口，方案如下：

正常情况：事务主动方发消息

这种情况下，事务主动方服务正常，没有发生故障，发消息流程如下：

• 图中 1：发送方向 MQ 服务端(MQ Server)发送 half 消息。
• 图中 2：MQ Server 将消息持久化成功之后，向发送方 ack 确认消息已经发送成功。
• 图中 3：发送方开始执行本地事务逻辑。
• 图中 4：发送方根据本地事务执行结果向 MQ Server 提交二次确认（commit 或是 rollback）。
• 图中 5：MQ Server 收到 commit 状态则将半消息标记为可投递，订阅方最终将收到该消息；MQ Server 收到 rollback 状态则删除半消息，订阅方将不会接受该消息。

异常情况：事务主动方消息恢复

在断网或者应用重启等异常情况下，图中 4 提交的二次确认超时未到达 MQ Server，此时处理逻辑如下：

• 图中 5：MQ Server 对该消息发起消息回查。
• 图中 6：发送方收到消息回查后，需要检查对应消息的本地事务执行的最终结果。
• 图中 7：发送方根据检查得到的本地事务的最终状态再次提交二次确认。
• 图中 8：MQ Server基于 commit/rollback 对消息进行投递或者删除。

介绍完 RocketMQ 的事务消息方案后，由于前面已经介绍过本地消息表方案，这里就简单介绍 RocketMQ 分布式事务：

事务主动方基于 MQ 通信通知事务被动方处理事务，事务被动方基于 MQ 返回处理结果。

如果事务被动方消费消息异常，需要不断重试，业务处理逻辑需要保证幂等。

如果是事务被动方业务上的处理失败，可以通过 MQ 通知事务主动方进行补偿或者事务回滚。

方案总结

相比本地消息表方案，MQ 事务方案优点是：

• 消息数据独立存储 ，降低业务系统与消息系统之间的耦合。
• 吞吐量由于使用本地消息表方案。

缺点是：

 

 

• 一次消息发送需要两次网络请求(half 消息 + commit/rollback 消息) 。
• 业务处理服务需要实现消息状态回查接口。

Saga 事务：最终一致性

方案简介

Saga 事务源于 1987 年普林斯顿大学的 Hecto 和 Kenneth 发表的如何处理 long lived transaction（长活事务）论文。

Saga 事务核心思想是将长事务拆分为多个本地短事务，由 Saga 事务协调器协调，如果正常结束那就正常完成，如果某个步骤失败，则根据相反顺序一次调用补偿操作。

处理流程

Saga 事务基本协议如下：

每个 Saga 事务由一系列幂等的有序子事务(sub-transaction) Ti 组成。 每个 Ti 都有对应的幂等补偿动作 Ci，补偿动作用于撤销 Ti 造成的结果。

值得补充的是，由于 Saga 模型中没有 Prepare 阶段，因此事务间不能保证隔离性。

当多个 Saga 事务操作同一资源时，就会产生更新丢失、脏数据读取等问题，这时需要在业务层控制并发，例如：在应用层面加锁，或者应用层面预先冻结资源。

事件/编排设计缺点如下：

事件/编排设计优点如下：

命令协调设计缺点如下：

命令协调设计的优点如下：

事件/编排是实现 Saga 模式的自然方式，它很简单，容易理解，不需要太多的代码来构建。如果事务涉及 2 至 4 个步骤，则可能是非常合适的。

方案总结

中央协调器必须事先知道执行整个订单事务所需的流程(例如通过读取配置)。如果有任何失败，它还负责通过向每个参与者发送命令来撤销之前的操作来协调分布式的回滚。

基于中央协调器协调一切时，回滚要容易得多，因为协调器默认是执行正向流程，回滚时只要执行反向流程即可。

②事件编排（Event Choreography0）：没有中央协调器（没有单点风险）时，每个服务产生并观察其他服务的事件，并决定是否应采取行动。

在事件编排方法中，第一个服务执行一个事务，然后发布一个事件。该事件被一个或多个服务进行监听，这些服务再执行本地事务并发布（或不发布）新的事件。

当最后一个服务执行本地事务并且不发布任何事件时，意味着分布式事务结束，或者它发布的事件没有被任何 Saga 参与者听到都意味着事务结束。

以电商订单的例子为例：

Saga 定义了两种恢复策略：

向前恢复（forward recovery）：对应于上面第一种执行顺序，适用于必须要成功的场景，发生失败进行重试，执行顺序是类似于这样的：T1, T2, ..., Tj(失败), Tj(重试),..., Tn，其中j是发生错误的子事务(sub-transaction)。该情况下不需要Ci。

向后恢复（backward recovery）：对应于上面提到的第二种执行顺序，其中 j 是发生错误的子事务(sub-transaction)，这种做法的效果是撤销掉之前所有成功的子事务，使得整个 Saga 的执行结果撤销。

Saga 事务常见的有两种不同的实现方式：

①命令协调（Order Orchestrator）：中央协调器负责集中处理事件的决策和业务逻辑排序。

中央协调器（Orchestrator，简称 OSO）以命令/回复的方式与每项服务进行通信，全权负责告诉每个参与者该做什么以及什么时候该做什么。

以电商订单的例子为例：

可以看到，和 TCC 相比，Saga 没有“预留”动作，它的 Ti 就是直接提交到库。

下面以下单流程为例，整个操作包括：创建订单、扣减库存、支付、增加积分。

Saga 的执行顺序有两种，如上图：

 

• 服务之间存在循环依赖的风险。
• 当涉及的步骤较多，服务间关系混乱，难以追踪调测。
• 避免中央协调器单点故障风险。
• 当涉及的步骤较少服务开发简单，容易实现。
• 中央协调器容易处理逻辑容易过于复杂，导致难以维护。
• 存在协调器单点故障风险。
• 服务之间关系简单，避免服务之间的循环依赖关系，因为 Saga 协调器会调用 Saga 参与者，但参与者不会调用协调器。
• 程序开发简单，只需要执行命令/回复(其实回复消息也是一种事件消息)，降低参与者的复杂性。
• 易维护扩展，在添加新步骤时，事务复杂性保持线性，回滚更容易管理，更容易实施和测试。
• 事务发起方的主业务逻辑发布开始订单事件。
• 库存服务监听开始订单事件，扣减库存，并发布库存已扣减事件。
• 订单服务监听库存已扣减事件，创建订单，并发布订单已创建事件。
• 支付服务监听订单已创建事件，进行支付，并发布订单已支付事件。
• 主业务逻辑监听订单已支付事件并处理。
• 事务发起方的主业务逻辑请求 OSO 服务开启订单事务
• OSO 向库存服务请求扣减库存，库存服务回复处理结果。
• OSO 向订单服务请求创建订单，订单服务回复创建结果。
• OSO 向支付服务请求支付，支付服务回复处理结果。
• 主业务逻辑接收并处理 OSO 事务处理结果回复。
• 事务正常执行完成：T1, T2, T3, ..., Tn，例如：扣减库存(T1)，创建订单(T2)，支付(T3)，依次有序完成整个事务。
• 事务回滚：T1, T2, ..., Tj, Cj,..., C2, C1，其中 0 < j < n，例如：扣减库存(T1)，创建订单(T2)，支付(T3，支付失败)，支付回滚(C3)，订单回滚(C2)，恢复库存(C1)。

我的星球

微信识别二维码，加入我的星球和我一起讨论开发中的问题，星球内提供各种实用的实战指南。

 

参考资料

https://www.cnblogs.com/gnodev/p/3817323.html
https://www.cnblogs.com/monkeyblog/p/10449363.html
https://www.hollischuang.com/archives/681
https://mp.weixin.qq.com/s/TFGRcHV6EgeLB45OEJPRXw
http://www.tianshouzhi.com/api/tutorials/distributed_transaction/383