上一篇内容《从 2PC 和容错共识算法讨论 zookeeper 中的 Create 请求》介绍了保证分布式事务提交的两阶段提交协议，而 XA 是针对两阶段提交提出的接口实现标准，本文则对 XA 进行介绍。

1. XA

XA （eXtended Architecture 扩展架构）是 X/Open 组织提出的跨异构技术实现两阶段提交的接口标准。

分布式事务包含两种类型：

数据库内部的分布式事务

异构分布式事务

它于 1991 年推出并得到了广泛的实现：许多传统关系数据库包括 PostgreSQL、MySQL、DB2、SQL Server 和 Oracle；消息代理包括 ActiveMQ、HornetQ、MSMQ 和 IBM MQ 都支持 XA。它不是一个网络协议而是定义了 事务管理器（Transaction Manager）、应用程序（Application Program）和资源管理器（Resource Manager）之间交互的 CAPI(Common Application Programming Interface) 接口标准，如下图所示，但是标准中并没有指明该如何实现，例如在 Java EE 中，XA 使用的是 Java 事务 API（JTA， Java Transaction API）实现的。

CAPI: 国际标准的通用应用交互接口。

其中三个组件的职责如下：

应用程序（Application Program）：负责定义事务的开启、提交或中止，并能够访问事务内的资源（数据库等）

资源管理器（Resource Manager）：负责对资源进行管理，相当于两阶段提交中的参与者，能够与事务管理器通过接口交互来传递必要的事务信息

事务管理器（Transaction Manager）：负责管理全局事务，分配事务 ID，监控事务的执行进度，并负责事务的开启、提交和回滚等，相当于两阶段提交中的协调者

XA 同样也分为准备阶段和提交阶段，它对分布式事务管理的流程如下

• 准备阶段：AP 与 TM 交互，开启一个全局分布式事务，并发送请求到每个 RM，执行数据变更逻辑，此时每个 RM 会向 TM 发送请求注册分支事务，在执行完业务逻辑后报告准备提交的状态（事务执行完未提交），之后 AP 会根据 RM 的响应在提交阶段做出反馈
• 提交阶段：如果所有的 RM 都回复 “是”，表示它们已经准备好提交，那么 AP 会在该阶段向 TM 发出提交请求，分布式事务提交；否则，AP 会向 TM 发出中止请求，分布式事务回滚

2. Seata 的 XA 的模式

Seata 中有三个角色事务管理器（Transaction Manager）、资源管理器（Resource Manager）和事务协调者（Transaction Coordinator）。在 XA 模式下，利用事务资源（数据库、消息服务等）对 XA 协议的支持，来对分布式事务进行管理。

但是，在 Seata 中三个角色的定义与 XA 协议标准中角色的定义有所区别：事务管理器（Transaction Manager）应该对应 XA 协议中的应用程序（Application Program）；事务协调者（Transaction Coordinator）对应 XA 协议中的事务管理器（Transaction Manager）。我认为它们只是在命名上的区别，为了上下文各名词的统一，避免发生因名词不一致而理解混淆的问题，决定以 XA 标准协议中的定义进行讲解，特此强调。

下图是 Seata 管理分布式事务的流程图，与第一小节中所述事务流程相同，不再赘述。

2.1 XA 模式实战分析