分布式事务

分布式事务简介

在了解分布式事务之前，我们先了解一下什么是事务

什么是事务

数据库事务(简称：事务，Transaction)是指数据库执行过程中的⼀个逻辑单位，⼀个事务会有多个业务操作构成。

jdbc 开启事务伪代码

connection.setAutoCommit(false); //开启事务
业务操作A：扣减库存
业务操作B：创建订单
业务操作C：扣款
业务操作D：增加用户积分
connection.commit(); //提交事务
connection.rollback(); //有异常回滚事务

事务的四个特性

事务拥有以下四个特性，习惯上被称为 ACID 特性：
原子性(Atomicity)：事务作为⼀个整体被执行，包含在其中的对数据库的操作要么全部被执行，要么都不执行。
⼀致性(Consistency)：事务应确保数据库的状态从⼀个⼀致状态转变为另⼀个⼀致状态。⼀致状态是指数据库中的数据应满足完整性约束。除此之外，⼀致性还有另外⼀层语义，就是事务的中间状态不能被观察到(这层语义也有说应该属于原子性)。
隔离性(Isolation)：多个事务并发执行时，⼀个事务的执行不应影响其他事务的执行，如同只有这⼀个操作在被数据库所执行⼀样。
持久性(Durability)：已被提交的事务对数据库的修改应该永久保存在数据库中。在事务结束时，此操作将不可逆转。

本地事务

倘若将⼀个单⼀的服务操作作为⼀个事务，那么整个服务操作只能涉及⼀个单⼀的数据库资源，这类基于单个服务单⼀数据库资源访问的事务，被称为本地事务(Local Transaction)。

什么是分布式事务

分布式事务指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系 统的不同节点之上，且属于不同的应用，分布式事务需要保证这些操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据⼀致性。

分布式事务应用架构

本地事务主要限制在单个会话内，不涉及多个数据库资源。但是在基于 SOA（Service-Oriented Architecture，面向服务架构）的分布式应用环境下，越来越多的应用要求对多个数据库资源，多个服务的访问都能纳入到同⼀个事务当中，分布式事务应运而生。

单⼀服务分布式事务

即服务与服务不相互访问，仅仅是单个服务内操作涉及到对多个数据库资源的访问。

1.4.2 多服务分布式事务

如果系统中只有一个数据源，而系统中⼀个服务操作需要调用另外⼀个服务，这时的事务就需要跨越多个服务了。在这种情况下，起始于某个服务的事务在调用另外⼀个服务的时候，需要以某种机制流转到另外⼀个服务，从而使被调用的服务访问的资源也自动加入到该事务当中来。下图反映了这样⼀个跨越多个服务的分布式事务：

多服务多数据源分布式事务

如果将上面这两种场景(⼀个服务可以调用多个数据库资源，也可以调用其他服务)结合在⼀起，对此进行延伸，整个分布式事务的参与者将会组成如下图所示的树形拓扑结构。在⼀个跨服务的分布式事务中， 事务的发起者和提交均是同⼀个，它可以是整个调用的客户端，也可以是客户端最先调用的那个服务。

在了解分布式事务的解决方案，我们先来了解一个概念

CAP定理

定义

在理论计算机科学中，CAP定理（CAP theorem），又被称作布鲁尔定理（Brewer’s theorem），它指出对于⼀个分布式计算系统来说，不可能同时满足以下三点

选项	具体意义
⼀致性（Consistency）	所有节点访问同⼀份最新的数据副本
可用性（Availability）	每次请求都能获取到非错的响应，但是不保证获取的数据为最新数据
分区容错性（Partition tolerance）	分布式系统在遇到任何网络分区故障的时候，仍然能够对外提供满足⼀致性和可用性的服务，除非整个网络环境都发生了故障

CAP三者不可能同时满足

假设确实存在三者能同时满足的系统

• 那么我们要做的第⼀件事就是分区我们的系统，由于满足分区容错性，也就是说可能因为通信不佳等情况，G1和G2之间是没有同步

• 接下来，我们的客户端将v1写入G1，但G1和G2之间是不同步的，所以如下G1是v1数据，G2是v0 数据。

• 由于要满足可用性，即⼀定要返回数据，所以G1必须在数据没有同步给G2的前提下返回数据给
  client，如下

• 接下去，client请求的是G2服务器，由于G2服务器的数据是v0，所以client得到的数据是v0

很明显，G1返回的是v1数据，G2返回的是v0数据，两者不⼀致。其余情况也有类似推导，也就是说CAP三者不能同时出现。

CAP三者如何权衡

三选二利弊如何

1. CA (Consistency + Availability)：关注⼀致性和可用性，它需要非常严格的全体⼀致的协议，比如
   “两阶段提交”（2PC）。CA 系统不能容忍网络错误或节点错误，⼀旦出现这样的问题，整个系统就
   会拒绝写请求，因为它并不知道对面的那个结点是否挂掉了，还是只是网络问题。唯⼀安全的做法
   就是把自己变成只读的。
2. CP (consistency + partition tolerance)：关注⼀致性和分区容忍性。它关注的是系统里大多数⼈的
   ⼀致性协议，比如：Paxos 算法 (Quorum 类的算法)。这样的系统只需要保证大多数结点数据⼀
   致，而少数的结点会在没有同步到最新版本的数据时变成不可用的状态。这样能够提供⼀部分的可
   用性。

例如 ZK 就是遵循 CP，为了⼀致性和分区容忍性，ZK 牺牲了可用性，即当 ZK 的 Leader 宕机后，其他节点需要进去到新的 Leader 选举中，但是选举时长在30s - 120s之间，而当新的 Leader 选举出来后，各个 Follower 需要将新的 Leader 的数据同步到自己的缓存中，即完成初始化同步，在选举和初始化同步的过程中，ZK 是不提供服务的。而在某 Follower 节点同步 Leader 的数据时，即更新同步的过程中，该节点同样是不可用的。

3. AP (availability + partition tolerance)：这样的系统关心可用性和分区容忍性。因此，这样的系统
   不能达成⼀致性，需要给出数据冲突，给出数据冲突就需要维护数据版本。

例如 Eureka 保证 AP，在设计时就优先保证可用性。Eureka 各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而 Eureka 的客户端在向某个Eureka 注册或时如果发现连接失败，则会自动切换其它节点，只要有⼀台Eureka还在，就能保证注册
服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强⼀致性)。除此之外，Eureka 还有⼀种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么 Eureka 就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：

1. Eureka 不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
2. Eureka 仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上(即保证当前节点依然可用)
3. 当网络稳定时，当前实例新的注册信息会被同步到其它节点中 因此， Eureka 可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像 zookeeper 那样使整个注册服务瘫痪。

总结

权衡三者的关键点取决于业务

放弃了⼀致性，满足分区容错，那么节点之间就有可能失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会容易导致全局数据不⼀致性。对于互联网应用来说（如新浪，网易），机器数量庞大，节点分散，网络故障再正常不过了，那么此时就是保障AP，放弃C的场景，而从实际中理解，像门户网站这种偶尔没有⼀致性是能接受的，但不能访问问题就非常大了。
对于银行来说，就是必须保证强⼀致性，也就是说C必须存在，那么就只用CA和CP两种情况，当保障强⼀致性和可用性（CA），那么⼀旦出现通信故障，系统将完全不可用。另⼀方面，如果保障了强⼀致性和分区容错（CP），那么就具备了部分可用性。实际究竟应该选择什么，是需要通过业务场景进行权衡的（并不是所有情况都是CP好于CA，只能查看信息但不能更新信息有时候还不如直接拒绝服务）

分布式事务解决方案

两阶段提交(2PC)

⼆阶段事务提交方案：强⼀致性
事务的发起者称协调者，事务的执行者称参与者。处理流程：
1、准备阶段
事务协调者，向所有事务参与者发送事务内容，询问是否可以提交事务，并等待参与者回复。事务参与者收到事务内容，开始执行事务操作，将 undo （回滚）和 redo （提交）信息记入事务日志中（但此时并不提交事务）。
如果参与者执行成功，给协调者回复 yes，表示可以进行事务提交。如果执行失败，给协调者回复 no,表示不可提交。
2、提交阶段
如果协调者收到了参与者的失败信息或超时信息，直接给所有参与者发送回滚（rollback）信息进行事务回滚，否则，发送提交（commit）信息。
参与者根据协调者的指令执行提交或者回滚操作，释放所有事务处理过程中使用的锁资源(注意：必须在最后阶段释放锁资源) 。
简单⼀点理解，可以把协调者节点比喻为带头大哥，参与者理解比喻为跟班小弟，带头大哥统⼀协调跟班小弟的任务执行。
接下来分两种情况分别讨论提交阶段的过程。

情况 1，当所有参与者均反馈 yes，提交事务，如上图：

• 协调者向所有参与者发出正式提交事务的请求（即 commit 请求）。
• 参与者执行 commit 请求，并释放整个事务期间占用的资源。
• 各参与者向协调者反馈 ack(应答)完成的消息。
• 协调者收到所有参与者反馈的 ack 消息后，即完成事务提交。
  
  情况 2，当阶段 1 中任何⼀个参与者反馈 no，中断事务，如上图：
  协调者向所有参与者发出回滚请求（即 rollback 请求）。
  参与者使用阶段 1 中的 undo 信息执行回滚操作，并释放整个事务期间占用的资源。各参与者向协调者反馈 ack 完成的消息。
  协调者收到所有参与者反馈的 ack 消息后，即完成事务中断。

方案总结

2PC 方案实现起来简单，但存在以下问题：

• 性能问题：所有参与者在事务提交阶段处于同步阻塞状态，占用系统资源，容易导致性能瓶颈。
• 可靠性问题：如果协调者存在单点故障问题，如果协调者出现故障，参与者将⼀直处于锁定状态。
• 数据⼀致性问题：在阶段 2 中，如果发生局部网络问题，⼀部分事务参与者收到了提交消息，另⼀部分事务参与者没收到提交消息，那么就导致了节点之间数据的不⼀致。

补偿事务（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 事务机制相比于上面介绍的 2PC 事务机制，有以下优点：

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

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

本地消息表

方案简介

本地消息表的方案最初是由 eBay 提出，核心思路是将分布式事务拆分成本地事务进行处理。
方案通过在事务主动发起方额外新建事务消息表，事务发起方处理业务和记录事务消息在本地事务中完 成，轮询事务消息表的数据发送事务消息，事务被动方基于消息中间件消费事务消息表中的事务。
这样设计可以避免”业务处理成功 + 事务消息发送失败"，或"业务处理失败 + 事务消息发送成功"的棘⼿情况出现，保证 2 个系统事务的数据⼀致性。

处理流程

下面把分布式事务最先开始处理的事务方称为事务主动方，在事务主动方之后处理的业务内的其他事务 称为事务被动方。
为了方便理解，下面继续以电商下单为例进行方案解析，这里把整个过程简单分为扣减库存，订单创建 2 个步骤。
库存服务和订单服务分别在不同的服务器节点上，其中库存服务是事务主动方，订单服务是事务被动
方。
事务的主动方需要额外新建事务消息表，用于记录分布式事务的消息的发生、处理状态。 整个业务处理流程如下：

步骤 1：事务主动方处理本地事务。
事务主动方在本地事务中处理业务更新操作和写消息表操作。上面例子中库存服务阶段在本地事务中完成扣减库存和写消息表(图中 1 - 2)。
步骤 2：事务主动方通过消息中间件，通知事务被动方处理事务通知事务待消息。
消息中间件可以基于 Kafka、RocketMQ 消息队列，事务主动方主动写消息到消息队列，事务消费方消费并处理消息队列中的消息。
上面例子中，库存服务把事务待处理消息写到消息中间件，订单服务消费消息中间件的消息，完成新增 订单（图中 3 - 5）。
步骤 3：事务被动方通过消息中间件，通知事务主动方事务已处理的消息。
上面例子中，订单服务把事务已处理消息写到消息中间件，库存服务消费中间件的消息，并将事务消息 的状态更新为已完成(图中 6 - 8)。
为了数据的⼀致性，当处理错误需要重试，事务发送方和事务接收方相关业务处理需要支持幂等。 具体保存⼀致性的容错处理如下：

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

方案总结

方案的优点如下：

• 从应用设计开发的角度实现了消息数据的可靠性，消息数据的可靠性不依赖于消息中间件，弱化了 对 MQ 中间件特性的依赖。
• 方案轻量，容易实现。
  缺点如下：
• 与具体的业务场景绑定，耦合性强，不可公用。
• 消息数据与业务数据同库，占用业务系统资源。
• 业务系统在使用关系型数据库的情况下，消息服务性能会受到关系型数据库并发性能的局限。

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 消息) 。
• 业务处理服务需要实现消息状态回查接口。

在实际的应用场景中，我们通常使用 Seata 框架来实现分布式事务，下面我们来介绍该框架

Seata 框架

2019 年 1 ⽉，阿里巴巴中间件团队发起了开源项目 Fescar（Fast & EaSy Commit And Rollback），和社区⼀起共建开源分布式事务解决方案。Fescar 的愿景是让分布式事务的使用像本地事务的使用⼀样，简单和高效，并逐步解决开发者们遇到的分布式事务方面的所有难题。
为了打造更中立、更开放、生态更加丰富的分布式事务开源社区，经过社区核心成员的投票，大家决定对 Fescar 进行品牌升级，并更名为 Seata，意为：Simple Extensible Autonomous Transaction Architecture（简单可扩展自治事务框架），Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式，是⼀套⼀站式分布式事务解决方案。
Seata 融合了阿里巴巴和蚂蚁金服在分布式事务技术上的积累，并沉淀了新零售、云计算和新金融等场景下丰富的实践经验。

Seata 四种模式

AT

Seata AT 模式是基于 2PC 事务演进而来的⼀个分布式事务中间件，AT模式分为如下3个角色

解释：
Transaction Coordinator (TC)： 事务协调器，维护全局事务的运行状态，负责协调并驱动全局事务的提交或回滚。
Transaction Manager（TM）： 控制全局事务的边界，负责开启⼀个全局事务，并最终发起全局提交或全局回滚的决议。
Resource Manager (RM)： 控制分支事务，负责分支注册、状态汇报，并接收事务协调器的指令，驱动分支（本地）事务的提交和回滚。
协调执行流程如下：

Branch就是指的分布式事务中每个独立的本地局部事务。 在 AT 模式下，用户只需关心自己的 “业务SQL”
AT 模式分为两个阶段：

• ⼀阶段：执行用户 SQL
• ⼆阶段： Seata 框架自动生成
  如图：
  

第⼀阶段
Seata 的 JDBC 数据源代理通过对业务 SQL 的解析，把业务数据在更新前后的数据镜像组织成回滚日志，利用本地事务的 ACID 特性，将业务数据的更新和回滚日志的写入在同⼀个本地事务中提交。
这样，可以保证：任何提交的业务数据的更新⼀定有相应的回滚日志存在

基于这样的机制，分支的本地事务便可以在全局事务的第⼀阶段提交，并⻢上释放本地事务锁定的资源。
这也是Seata和 2PC 事务的不同之处，2PC 两阶段提交往往对资源的锁定需要持续到第⼆阶段实际的提交或者回滚操作，而有了回滚日志之后，可以在第⼀阶段释放对资源的锁定，降低了锁范围，提高效率，即使第⼆阶段发生异常需要回滚，只需找对 undolog 中对应数据并反解析成sql来达到回滚目的。
同时 Seata 通过代理数据源将业务 sql 的执行解析成 undolog 来与业务数据的更新同时入库，达到了对业务无侵入的效果。

第⼆阶段
如果决议是全局提交，此时分支事务此时已经完成提交，不需要同步协调处理（只需要异步清理回滚日志），阶段 2 可以非常快速地完成.

如果决议是全局回滚，RM 收到协调器发来的回滚请求，通过 XID 和 Branch ID 找到相应的回滚日志记录，通过回滚记录生成反向的更新 SQL 并执行，以完成分支的回滚

AT模式优点
AT 模式的⼀阶段、⼆阶段提交和回滚均由 Seata 框架自动生成，用户只需编写“业务 SQL”，便能轻松接入分布式事务，AT 模式是⼀种对业务无任何侵入的分布式事务解决方案。

TCC

TCC分为三个阶段：

• Try：做业务检查和资源预留
• Confirm：确认提交
• Cancel：业务执行错误需要回滚的状态下执行分支事务的业务取消，预留资源释放
  

1）过程

1. Try
2. Confirm
3. Cancel

2）三种异常处理

1. 空回滚：Try未执行，Cancel 执行了
2. 幂等：多次调用方法（Confirm）

   出现原因：

   • 网络异常
   • TC Server 异常

3. 悬挂：Cancel 接口 比 Try 接口先执行

   出现原因：超时

3）优点
相对于 AT 模式，TCC 模式对业务代码有⼀定的侵入性，但是 TCC 模式无 AT 模式的全局行锁，TCC 性能会比AT 模式高很多。

Sage

Sage 是长事务解决方案，事务驱动。
1）过程
如图：

2）适用场景

• 业务流程长/多
• 参与者包含其他公司或遗留系统服务，无法提供 TCC 模式要求的三个接口
• 典型业务系统：如金融网络（与外部金融机构对接）、互联网微贷、渠道整合、分布式架构服务集成等业务系统
• 银行业金融机构使用广泛
  3）三种异常

1. 空补偿：原服务未执行，补偿服务执行了

   • 原服务超时（丢包）
   • Saga 事务触发回滚
   • 未收到原服务请求，先收到补偿请求

2. 悬挂：补偿服务⽐原服务先执行

   • 原服务超时（拥堵）
   • Saga 事务回滚，触发回滚
   • 拥堵的原服务到达

3. 幂等：原服务与补偿服务都需要保证幂等性

4）优点

1. ⼀阶段提交本地数据库事务，无锁，性能高
2. 补偿服务即正向服务的 “反向”，高吞吐
3. 参与者可异步执行，高吞吐

XA

XA 模式是 Seata 将会开源的另⼀种无侵入的分布式事务解决方案。在 Seata 定义的分布式事务框架内，利用事务资源（数据库、消息服务等）对 XA 协议的支持，以 XA 协议的机制来管理分支事务的一种事务模式。

优点

1. 无侵入
2. 将快照数据和行锁等通过 XA 指令委托给了数据库来完成

以上4种模式可参考Seata官网进行学习和使用

总结

四种分布式事务模式，分别在不同的时间被提出，每种模式都有它的适用场景

• AT 模式是无侵⼊的分布式事务解决方案，适用于不希望对业务进行改造的场景，⼏乎0学习成本。
• TCC 模式是高性能分布式事务解决方案，适用于核心系统等对性能有很高要求的场景。
• Saga 模式是长事务解决方案，适用于业务流程长且需要保证事务最终⼀致性的业务系统，Saga 模式⼀阶段就会提交本地事务，无锁，长流程情况下可以保证性能，多用于渠道层、集成层业务系统。事务参与者可能是其它公司的服务或者是遗留系统的服务，无法进行改造和提供 TCC 要求的接⼝，也可以使用 Saga 模式。
• XA模式是分布式强⼀致性的解决方案，但性能低而使用较少。