分布式事务及常见解决方案

本是古典何须时尚 2023-07-01 07:29 88阅读 0赞

## 分布式事务简介 ##

从广义上来看，分布式事务其实也是事务，只是由于业务上的定义以及微服务架构设计的问题，所以需要在多个服务之间保证业务的事务性，也就是 ACID 四个特性；从单机的数据库事务变成分布式事务时，原有单机中相对可靠的方法调用以及进程间通信方式已经没有办法使用，同时由于网络通信经常是不稳定的，所以服务之间信息的传递会出现障碍。

![format_png][]

模块（或服务）之间通信方式的改变是造成分布式事务复杂的最主要原因，在同一个事务之间的执行多段代码会因为网络的不稳定造成各种奇怪的问题，当我们通过网络请求其他服务的接口时，往往会得到三种结果：正确、失败和超时，无论是成功还是失败，我们都能得到唯一确定的结果，**超时代表请求的发起者不能确定接受者是否成功处理了请求**，这也是造成诸多问题的诱因。

![format_png 1][]

系统之间的通信可靠性从单一系统中的可靠变成了微服务架构之间的不可靠，**分布式事务其实就是在不可靠的通信下实现事务的特性**。无论是事务还是分布式事务实现原子性都无法避免对持久存储的依赖，事务使用磁盘上的日志记录执行的过程以及上下文，这样无论是需要 回滚还是补偿都可以通过日志追溯，而分布式事务也会依赖数据库、Zookeeper 或者 ETCD 等服务追踪事务的执行过程，总而言之，各种形式的日志是保证事务几大特性的重要手段。

## 分布式事务处理模型 ##

**DTP模型**

DTP(Distributed Transaction Processing)是x/open组织提出来的分布式事务的模型.

一个DTP模型至少包含以下三个元素:

1. AP, 应用程序,用于定义事务开始和结束的边界. 说人话就是我们开启事务的代码所以的应用.
    2. RM, 资源管理器. 理论上一切支持持久化的数据库资源都可以是一个资源管理器.
    3. TM, 事务管理器, 负责对事务进行协调,监控. 并负责事务的提交和回滚.

**XA规范**

XA是x/open提出来的分布式事务的规范, 它是跟语言无关的.

XA规范定义了RM和TM交互的接口. 例如TM可以通过以下接口对RM进行管理:

1. xa_open和xa_close, 用于跟RM建立连接
      2. xa_star和xa_end, 开始和结束一个事务
      3. xa_prepare, xa_commit和xa_rollback, 用于预提交, 提交和回滚一个事务
      3. xa_recover 用于回滚一个预提交的事务

**JTA规范**

JTA规范是可以认为是XA规范java语言实现版的规范.

JTA定义了一系列分布式事务相关的接口:

1. javax.transaction.Status: 定义了事务的状态,例如prepare, commit rollback等等等
    2. javax.transaction.Synchronization：同步
    3. javax.transaction.Transaction：事务
    4. javax.transaction.TransactionManager：事务管理器
    5. javax.transaction.UserTransaction：用于声明一个分布式事务
    6. javax.transaction.TransactionSynchronizationRegistry：事务同步注册
    7. javax.transaction.xa.XAResource：定义RM提供给TM操作的接口
    8. javax.transaction.xa.Xid：事务id

以上不同的接口由不同的角色(RM, RM等)来实现

## 常见的解决方案 ##

### 二阶段提交（2PC） ###

![format_png 2][]

两阶段提交的算法思路可以概括为：参与者将操作成功或失败的结果通知协调者，再由协调者根据所有参与者的反馈情况决定个参与者是否要提交操作还是中止操作。

1.1 第一阶段：请求阶段（投票阶段）

协调者向所有的参与者发送事务执行请求，并等待参与者反馈事务执行结果。

事务参与者收到请求之后，本地执行事务，但不提交。

参与者将自己事务执行情况反馈给协调者，同时等待协调者的下一步通知。

1.2 第二阶段：提交阶段（执行阶段）

在第一阶段协调者的询盘之后，各个参与者会回复自己事务的执行情况，这时候存在三种可能：  
1、所有的参与者回复能够正常执行事务  
 ①协调者向各个参与者发送commit通知，请求提交事务  
 ②参与者收到事务提交通知之后，执行commit操作  
 ③参与者向协调者返回事务commit结果信息。  
2、一个或多个参与者回复事务执行失败  
3、协调者等待超时  
 ①协调者向各个参与者发送事务rollback通知，请求回滚事务  
 ②参与者收到事务回滚通知之后，执行rollback操作  
 ③参与者向协调者返回事务rollback结果信息

1.3 两阶段提交的缺点

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

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

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

1.4 两阶段提交无法解决的问题

当协调者和参与者同时出现故障时，两阶段提交无法保证事务的完整性。如果调用者在发出commit消息之后宕机，而唯一接收到commit消息的参与者同时也宕机了。那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，因为没人知道事务是否已经被提交。

### 二阶段补偿型事务（TCC） ###

TCC是二阶段协议的一种，优化，只锁定了一部分的资源，其他的事务仍可以使用。TCC是一种比较成熟的分布式事务解决方案，可用于**解决跨库操作的数据一致性问题**，适用于公司内部对一致性、实时性要求较高的业务场景。其中Try、Confirm、Cancel 3个方法均由业务编码实现。其中Try操作为第一阶段，负责资源的检查和预留；Confirm操作为第二阶段，执行真正的业务操作；Cancel时执行取消（回滚）操作。

业务实现TCC服务之后，该TCC服务将作为分布式事务的其中一个资源，参与到整个分布式事务中；事务管理器分两阶段协调的TCC服务，**第一阶段调用所有TCC服务的Try方法（和二阶段提交中的预提交不同，这里每一个RM来说，事务此时已经提交了），在第二阶段执行所有TCC服务的Confirm或者Cancel方法**。

![format_png 3][]

3.1 实现TCC服务时注意事项

**1. 业务操作分两阶段完成**

接入TCC前，业务操作只需要一步就能完成，但是在接入TCC之后，需要考虑如何将其分成2阶段完成，把资源的检查和预留放在一阶段的Try操作中进行，把真正的业务操作的执行放在二阶段的Confirm操作中进行。TCC服务要保证第一阶段Try操作成功之后，二阶段Confirm操作一定能成功。

![format_png 4][]

**2. 允许空回滚**

事务协调器在调用TCC服务的一阶段Try操作时，可能会出现因为丢包而导致的网络超时，此时事务协调器会触发二阶段回滚，调用TCC服务的Cancel操作；TCC服务在未收到Try请求的情况下收到Cancel请求，这种场景被称为空回滚；TCC服务在实现时应当允许空回滚的执行。

![format_png 5][]

**3. 防悬挂控制**

事务协调器在调用TCC服务的一阶段Try操作时，可能会出现因网络拥堵而导致的超时，此时事务协调器会触发二阶段回滚，调用TCC服务的Cancel操作；在此之后，拥堵在网络上的一阶段Try数据包被TCC服务收到，出现了二阶段Cancel请求比一阶段Try请求先执行的情况；用户在实现TCC服务时，应当允许空回滚，但是要拒绝执行空回滚之后到来的一阶段Try请求。

![format_png 6][]

**4. 幂等控制**

无论是网络数据包重传，还是异常事务的补偿执行，都会导致TCC服务的Try、Confirm或者Cancel操作被重复执行；用户在实现TCC服务时，需要考虑幂等控制，即Try、Confirm、Cancel 执行一次和执行多次的业务结果是一样的。

![format_png 7][]

举例，假入 Bob 要向 Smith 转账，思路大概是：

1. 首先在 Try 阶段，要先调用远程接口把 Smith 和 Bob 的钱给冻结起来。

2. 在 Confirm 阶段，执行远程调用的转账的操作，转账成功进行解冻（在TCC事务机制中认为，如果在Try阶段能正常的预留资源，那Confirm一定能完整正确的提交。Confirm阶段也可以看成是对Try阶段的一个补充，Try+Confirm一起组成了一个完整的业务逻辑）。

3. 如果第2步执行成功，那么转账成功，如果第二步执行失败，则调用远程冻结接口对应的解冻方法 (Cancel)。

**TCC模型对业务的侵入强，改造的难度大，一些业务流程用TCC可能不太好定义，阿里巴巴内部采用的是这种方式。**

### 三阶段提交（3PC） ###

为了解决两阶段提交存在的一些问题，三阶段提交引入了**超时机制和准备阶段**，如果协调者或者参与者在规定的时间内没有接收到来自其他节点的响应，就会根据当前的状态选择提交或者终止整个事务，准备阶段的引入其实让事务的参与者有了除回滚之外的其他选择。

![format_png 8][]

2.1 第一阶段：CanCommit

协调者向参与者发送事务执行请求CanCommit，参与者如果可以提交就返回YES响应，否则就返回NO响应。

2.2 第二阶段：PreCommit

协调者根据参与者反馈的结果来决定是否继续执行事务的PreCommit操作，根据协调者反馈的结果，有以下两种可能：

假如协调者收到参与者的反馈结果都是YES，那么就会执行PreCommit操作。

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

事务预提交：参与者接收到PreCommit请求后，执行事务操作。

响应反馈：事务操作执行成功，则返回ACK响应，然后等待协调者的下一步通知。

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

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

中断事务：参与者收到中断请求之后（或超时之后，仍未收到协调者的请求），执行事务中断操作。

2.3 第三阶段：DoCommit

执行提交

发送提交请求：协调者收到ACK之后，向所有的参与者发送DoCommit请求。

事务提交：参与者收到DoCommit请求之后，提交事务。

响应反馈：事务提交之后，向协调者发送ACK响应。

完成事务：协调者收到ACK响应之后，完成事务。

中断事务

在第二阶段，协调者没有收到参与者发送的ACK响应，那么就会执行中断事务。

**2pc和3pc的区别**

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

在2PC中一个参与者的状态只有它自己和协调者知晓，假如协调者提议后自身宕机，在协调者备份启用前一个参与者又宕机，其他参与者就会进入既不能回滚、又不能强制commit的阻塞状态，直到参与者宕机恢复。

参与者如果在不同阶段宕机，我们来看看3PC如何应对：

**阶段1**: 协调者或协调者备份未收到宕机参与者的vote，直接中止事务；宕机的参与者恢复后，读取logging发现未发出赞成vote，自行中止该次事务

**阶段2**: 协调者未收到宕机参与者的precommit ACK，但因为之前已经收到了宕机参与者的赞成反馈(不然也不会进入到阶段2)，协调者进行commit；协调者备份可以通过问询其他参与者获得这些信息，过程同理；宕机的参与者恢复后发现收到precommit或已经发出赞成vote，则自行commit该次事务

**阶段3**: 即便协调者或协调者备份未收到宕机参与者t的commit ACK，也结束该次事务；宕机的参与者恢复后发现收到commit或者precommit，也将自行commit该次事务

### 本地消息表（最终一致性） ###

本地消息表的方案最初是由ebay提出，核心思路是将分布式事务拆分成本地事务进行处理。

方案通过在事务主动发起方额外新建事务消息表，事务发起方处理业务和记录事务消息在本地事务中完成，轮询事务消息表的数据发送事务消息，事务被动方基于消息中间件消费事务消息表中的事务。

这样设计可以避免”**业务处理成功 + 事务消息发送失败**"，或"**业务处理失败 + 事务消息发送成功**"的棘手情况出现，保证2个系统事务的数据一致性。

**处理流程**

下面把分布式事务最先开始处理的事务方成为事务主动方，在事务主动方之后处理的业务内的其他事务成为事务被动方。

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

事务的主动方需要额外新建事务消息表，用于记录分布式事务的消息的发生、处理状态。

整个业务处理流程如下：

![本地消息表方案][cc971858e42203bded0fc8940f311993.png]

*  **步骤1 事务主动方处理本地事务。** 事务主动发在本地事务中处理业务更新操作和写消息表操作。 上面例子中库存服务阶段再本地事务中完成扣减库存和写消息表(图中1、2)。
 *  **步骤2 事务主动方通过消息中间件，通知事务被动方处理事务通知事务待消息**。 消息中间件可以基于Kafka、RocketMQ消息队列，事务主动方法主动写消息到消息队列，事务消费方消费并处理消息队列中的消息。 上面例子中，库存服务把事务待处理消息写到消息中间件，订单服务消费消息中间件的消息，完成新增订单（图中3 - 5）。
 *  **步骤3 事务被动方通过消息中间件，通知事务主动方事务已处理的消息。** 上面例子中，订单服务把事务已处理消息写到消息中间件，库存服务消费中间件的消息，并将事务消息的状态更新为已完成(图中6 - 8)

为了数据的一致性，当处理错误需要重试，事务发送方和事务接收方相关业务处理需要支持幂等。具体保存一致性的容错处理如下：

*  1、当步骤1处理出错，事务回滚，相当于什么都没发生。
 *  2、当步骤2、步骤3处理出错，由于未处理的事务消息还是保存在事务发送方，事务发送方可以定时轮询为超时消息数据，再次发送的消息中间件进行处理。事务被动方消费事务消息重试处理。
 *  3、如果是业务上的失败，事务被动方可以发消息给事务主动方进行回滚。
 *  4、如果多个事务被动方已经消费消息，事务主动方需要回滚事务时需要通知事务被动方回滚。

**方案总结**

方案的优点如下：

*  从应用设计开发的角度实现了消息数据的可靠性，消息数据的可靠性不依赖于消息中间件，弱化了对MQ中间件特性的依赖。
 *  方案轻量，容易实现。

缺点如下：

*  与具体的业务场景绑定，耦合性强，不可公用。
 *  消息数据与业务数据同库，占用业务系统资源。
 *  业务系统在使用关系型数据库的情况下，消息服务性能会受到关系型数据库并发性能的局限。

### MQ事务消息（最终一致性） ###

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

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

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

![正常情况——事务主动方发消息][a67568759c172d846d132ad28373a8c9.png]

*  图中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，此时处理逻辑如下：

![异常情况——事务主动方消息恢复][fc13aebb314ef32dfbb3fb6b3dd09a4f.png]

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

有一些第三方的MQ是支持事务消息的，比如RocketMQ，但是市面上一些主流的MQ都是不支持事务消息的，比如 RabbitMQ 和 Kafka 都不支持。

### Saga（最终一致性） ###

Saga事务源于1987年普林斯顿大学的Hecto和Kenneth发表的如何处理long lived transaction（长活事务）论文，**Saga事务核心思想是将长事务拆分为多个本地短事务**，由Saga事务协调器协调，如果正常结束那就正常完成，如果某个步骤失败，则根据相反顺序一次调用补偿操作。

**处理流程**

Saga事务基本协议如下：

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

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

下面以下单流程为例，整个操作包括：创建订单、扣减库存、支付、增加积分 Saga的执行顺序有两种：

![Saga事务执行顺序][Saga]

*  事务正常执行完成 T1, T2, T3, ..., Tn，例如：扣减库存(T1)，创建订单(T2)，支付(T3)，依次有序完成整个事务。
 *  事务回滚 T1, T2, ..., Tj, Cj,..., C2, C1，其中0 < j < n，例如：扣减库存(T1)，创建订单(T2)，支付(T3，支付失败)，支付回滚(C3)，订单回滚(C2)，恢复库存(C1)。

Saga定义了两种恢复策略：

*  向前恢复(forward recovery)

![Saga事务向前恢复][Saga 1]

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

*  向后恢复(backward recovery)

![Saga事务向后恢复][Saga 2]

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

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

*  1、**命令协调(Order Orchestrator)：中央协调器负责集中处理事件的决策和业务逻辑排序。**

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

![命令协调模式][f277f73aee1d594e53140017931f8f18.png]

以电商订单的例子为例：

> 1、事务发起方的主业务逻辑请求OSO服务开启订单事务 2、OSO向库存服务请求扣减库存，库存服务回复处理结果。 3、OSO向订单服务请求创建订单，订单服务回复创建结果。 4、OSO向支付服务请求支付，支付服务回复处理结果。 5、主业务逻辑接收并处理OSO事务处理结果回复。

中央协调器必须事先知道执行整个订单事务所需的流程(例如通过读取配置)。如果有任何失败，它还负责通过向每个参与者发送命令来撤销之前的操作来协调分布式的回滚。基于中央协调器协调一切时，回滚要容易得多，因为协调器默认是执行正向流程，回滚时只要执行反向流程即可。

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

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

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

以电商订单的例子为例：

![事件编排模式][053043cea25fe260b240474362249c4a.png]

*  1、事务发起方的主业务逻辑发布开始订单事件
 *  2、库存服务监听开始订单事件，扣减库存，并发布库存已扣减事件
 *  3、订单服务监听库存已扣减事件，创建订单，并发布订单已创建事件
 *  4、支付服务监听订单已创建事件，进行支付，并发布订单已支付事件
 *  5、主业务逻辑监听订单已支付事件并处理。

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

**方案总结**

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

*  1、服务之间关系简单，避免服务之间的循环依赖关系，因为Saga协调器会调用Saga参与者，但参与者不会调用协调器
 *  2、程序开发简单，只需要执行命令/回复(其实回复消息也是一种事件消息)，降低参与者的复杂性。
 *  3、易维护扩展，在添加新步骤时，事务复杂性保持线性，回滚更容易管理，更容易实施和测试

缺点如下：

*  1、中央协调器容易处理逻辑容易过于复杂，导致难以维护。
 *  2、存在协调器单点故障风险。

**事件/编排设计的优点和缺点** 优点如下：

*  1、避免中央协调器单点故障风险。
 *  2、当涉及的步骤较少服务开发简单，容易实现。

缺点如下：

*  1、服务之间存在循环依赖的风险。
 *  2、当涉及的步骤较多，服务间关系混乱，难以追踪调测。

值得补充的是，由于Saga模型中没有Prepare阶段，因此事务间不能保证隔离性，当多个Saga事务操作同一资源时，就会产生更新丢失、脏数据读取等问题，这时需要在业务层控制并发，例如：在应用层面加锁，或者应用层面预先冻结资源。

### 方案比较 ###

介绍完分布式事务相关理论和常见解决方案后，最终的目的在实际项目中运用，因此，总结一下各个方案的常见的使用场景。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0MzEzNjM1_size_16_color_FFFFFF_t_70][]

*  2PC/3PC 依赖于数据库，能够很好的提供强一致性和强事务性，但相对来说延迟比较高，比较适合传统的单体应用，在同一个方法中存在跨库操作的情况，不适合高并发和高性能要求的场景。
 *  TCC 适用于执行时间确定且较短，实时性要求高，对数据一致性要求高，比如互联网金融企业最核心的三个服务：交易、支付、账务。
 *  本地消息表/MQ事务 都适用于事务中参与方支持操作幂等，对一致性要求不高，业务上能容忍数据不一致到一个人工检查周期，事务涉及的参与方、参与环节较少，业务上有对账/校验系统兜底。
 *  Saga事务 由于Saga事务不能保证隔离性，需要在业务层控制并发，适合于业务场景事务并发操作同一资源较少的情况。 Saga相比缺少预提交动作，导致补偿动作的实现比较麻烦，例如业务是发送短信，补偿动作则得再发送一次短信说明撤销，用户体验比较差。Saga事务较适用于补偿动作容易处理的场景。

## 分布式事务框架 ##

在实际的应用中, 分布式事务出现的场景可以总结为两种. 还是以一个购买服务为例, 那么这两种分布式事务的场景可能是:

第一种, 同一个服务中对多个RM进行操作（数据库层面的一个分布式，服务并没有分布式）

![image][]

第二种, 一个服务通过RPC调用多个服务, 间接操作了多个RM（服务分布式）

![image][image 1]

在微服务化大行其道的今天,按业务分库应该是大多公司搭建架构的一个基本准则了. 所以这样来看, 貌似是第二种场景更符合实际了.

当然第一种场景肯定也还是有存在的. 例如上面"本地消息表"的解决方案中, 就有需要再同一个服务中跟多个RM交互.

分布式事务开源框架其实市面上也挺多的,例如tcc-transactio等等, 这里我们来看看atomikos和seata这两个

### atomikos ###

atomikos是一个非常有名的分布式事务开源框架. 它有JTA/XA规范的实现, 也有TCC机制的实现方案, 前者是免费开源的, 后者是商业付费版的.

这里介绍一下JTA/XA规范的实现.

上面JTA规范那一小节说到JTA定义了一系列的接口,那些接口是由不同的角色去实现的. atomikos的角色是一个事务管理器, 它实现的接口主要有:

1. javax.transaction.UserTransaction
       对应的实现是com.atomikos.icatch.jta.UserTransactionImp，用户只需要直接操作这个类就是实现一个JTA分布式事务
    
     2. javax.transaction.TransactionManager
       对应的实现是com.atomikos.icatch.jta.UserTransactionManager, atomikos使用这个实现类来对事务进行管理
    
     3. javax.transaction.Transaction
        对应的实现是com.atomikos.icatch.jta.TransactionImp

atomikos适用于场景1的分布式事务. 如果有场景1的分布式事务的话, 直接使用atomikos就可以了, 简单直接高效。但是话又说回来了, 实际场景的分布式事务更多的还是属于场景2的.。很明显简单的JTA事务是处理不了场景2的分布式事务的。场景2下的分布式事务, 可以考虑使用seata

###  seata ###

seata就是Fescar(TXC/GTC/FESCAR)和tcc-transaction整合后开源的一个分布式事务落地解决方案框架,实现了AT, TCC, SAGA三种模式, 大有一统江湖的意思.

官网地址是[seata.io/zh-cn/docs/…][seata.io_zh-cn_docs], 文档方面相对来说还不够完善, 但是作为了解还是足够了. 这里也是简单地介绍一下.

### 总结 ###

分布式事务一直是业界难题，难在于CAP定理，在于分布式系统8大不可能假设，在于FLP不可能原理，在于我们习惯于单机事务ACID做对比。无论是数据库领域XA、Google percolator或Calvin模型，还是微服务下Saga、TCC、可靠消息等方案，都没有完美解决分布式事务问题，它们不过是各自在性能、一致性、可用性等方面做取舍，寻求某些场景偏好下的权衡。

**其实由于网络的不确定性，分布式下很多问题都是难题，最好的方案是避免分布式事务**

[format_png]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly91c2VyLWdvbGQtY2RuLnhpdHUuaW8vMjAxOS8xLzI1LzE2ODgyZTUwY2Y0Yjc4NzY?x-oss-process=image/format,png
[format_png 1]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly91c2VyLWdvbGQtY2RuLnhpdHUuaW8vMjAxOS8xLzI1LzE2ODgyZTUwZDQ3MDZkOWQ?x-oss-process=image/format,png
[format_png 2]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy8yMjY5MjMyLWViNDU5NDBkZTUzYWIxNjA_aW1hZ2VNb2dyMi9hdXRvLW9yaWVudC9zdHJpcHxpbWFnZVZpZXcyLzIvdy84Nzc?x-oss-process=image/format,png
[format_png 3]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy8yMjY5MjMyLTdjZDQ4NDAyZjNiN2ZmMzY_aW1hZ2VNb2dyMi9hdXRvLW9yaWVudC9zdHJpcHxpbWFnZVZpZXcyLzIvdy8xMjAw?x-oss-process=image/format,png
[format_png 4]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy8yMjY5MjMyLTBmOWJhZjljNzU4NDEyM2I_aW1hZ2VNb2dyMi9hdXRvLW9yaWVudC9zdHJpcHxpbWFnZVZpZXcyLzIvdy8xMDcy?x-oss-process=image/format,png
[format_png 5]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy8yMjY5MjMyLTIyM2ZjYzBiMjM1MDljNzY_aW1hZ2VNb2dyMi9hdXRvLW9yaWVudC9zdHJpcHxpbWFnZVZpZXcyLzIvdy8xMjAw?x-oss-process=image/format,png
[format_png 6]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy8yMjY5MjMyLWJjNDRjMDIwOTc1OTM5NmY_aW1hZ2VNb2dyMi9hdXRvLW9yaWVudC9zdHJpcHxpbWFnZVZpZXcyLzIvdy8xMjAw?x-oss-process=image/format,png
[format_png 7]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy8yMjY5MjMyLTkxMzMyNWFlZDg2Mzg4Y2E_aW1hZ2VNb2dyMi9hdXRvLW9yaWVudC9zdHJpcHxpbWFnZVZpZXcyLzIvdy8zODQ?x-oss-process=image/format,png
[format_png 8]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy8yMjY5MjMyLTE0NzQ0MWYzYTU4YThlM2Q_aW1hZ2VNb2dyMi9hdXRvLW9yaWVudC9zdHJpcHxpbWFnZVZpZXcyLzIvdy85NTI?x-oss-process=image/format,png
[cc971858e42203bded0fc8940f311993.png]: https://img-blog.csdnimg.cn/img_convert/cc971858e42203bded0fc8940f311993.png
[a67568759c172d846d132ad28373a8c9.png]: https://img-blog.csdnimg.cn/img_convert/a67568759c172d846d132ad28373a8c9.png
[fc13aebb314ef32dfbb3fb6b3dd09a4f.png]: https://img-blog.csdnimg.cn/img_convert/fc13aebb314ef32dfbb3fb6b3dd09a4f.png
[Saga]: https://img-blog.csdnimg.cn/img_convert/b2cccaae955d41b0e43bffc9c6b4d1f0.png
[Saga 1]: https://img-blog.csdnimg.cn/img_convert/afd9f992cb2d1cd06021b699da280e0d.png
[Saga 2]: https://img-blog.csdnimg.cn/img_convert/5d03adb4426a896ba6087aa105b56d60.png
[f277f73aee1d594e53140017931f8f18.png]: https://img-blog.csdnimg.cn/img_convert/f277f73aee1d594e53140017931f8f18.png
[053043cea25fe260b240474362249c4a.png]: https://img-blog.csdnimg.cn/img_convert/053043cea25fe260b240474362249c4a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0MzEzNjM1_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20210217210556685.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0MzEzNjM1,size_16,color_FFFFFF,t_70
[image]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly91c2VyLWdvbGQtY2RuLnhpdHUuaW8vMjAxOS8xMS8yMy8xNmU5NmQxM2JiMWMxMDhl?x-oss-process=image/format,png
[image 1]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly91c2VyLWdvbGQtY2RuLnhpdHUuaW8vMjAxOS8xMS8yMy8xNmU5NmQxM2Q2NDI2NmY2?x-oss-process=image/format,png
[seata.io_zh-cn_docs]: http://seata.io/zh-cn/docs/overview/what-is-seata.html