共计 4605 个字符，预计需要花费 12 分钟才能阅读完成。
简介：XA 协定是由 X/Open 组织提出的分布式事务处理标准，次要定义了事务管理器 TM 和部分资源管理器 RM 之间的接口。目前支流的数据库，比方 oracle、DB2 都是反对 XA 协定的。
作者 | 朱晋君
起源 | 阿里巴巴云原生公众号
XA 协定是由 X/Open 组织提出的分布式事务处理标准，次要定义了事务管理器 TM 和部分资源管理器 RM 之间的接口。目前支流的数据库，比方 oracle、DB2 都是反对 XA 协定的。
mysql 从 5.0 版本开始，innoDB 存储引擎曾经反对 XA 协定，明天的源码介绍试验环境应用的是 mysql 数据库。
两阶段提交
分布式事务的两阶段提交是把整个事务提交分为 prepare 和 commit 两个阶段。以电商零碎为例，分布式系统中有订单、账户和库存三个服务，如下图：
第一阶段，事务协调者向事务参与者发送 prepare 申请，事务参与者收到申请后，如果能够提交事务，回复 yes，否则回复 no。
第二阶段，如果所有事务参与者都回复了 yes，事务协调者向所有事务参与者发送 commit 申请，否则发送 rollback 申请。
两阶段提交存在三个问题：
同步阻塞，本地事务在 prepare 阶段锁定资源，如果有其余事务也要批改 xiaoming 这个账户，就必须期待后面的事务实现。这样就造成了零碎性能降落。
协调节点单点故障，如果第一个阶段 prepare 胜利了，然而第二个阶段协调节点收回 commit 指令之前宕机了，所有服务的数据资源处于锁定状态，事务将无限期地期待。
数据不统一，如果第一阶段 prepare 胜利了，然而第二阶段协调节点向某个节点发送 commit 命令时失败，就会导致数据不统一。
三阶段提交
为了解决两阶段提交的问题，三阶段提交做了改良：
在协调节点和事务参与者都引入了超时机制。
第一阶段的 prepare 阶段分成了两步，canCommi 和 preCommit。
如下图：
引入 preCommit 阶段后，协调节点会在 commit 之前再次查看各个事务参与者的状态，保障它们的状态是统一的。然而也存在问题，那就是如果第三阶段收回 rollback 申请，有的节点没有收到，那没有收到的节点会在超时之后进行提交，造成数据不统一。
XA 事务语法介绍
xa 事务的语法如下：
三阶段的第一阶段：开启 xa 事务，这里 xid 为全局事务 id：
XA {START|BEGIN} xid [JOIN|RESUME]
完结 xa 事务：
XA END xid [SUSPEND [FOR MIGRATE]]
三阶段的第二阶段，即 prepare：
XA PREPARE xid
三阶段的第三阶段，即 commit/rollback：
XA COMMIT xid [ONE PHASE]
XA ROLLBACK xid
查看处于 PREPARE 阶段的所有事务：
XA RECOVER XA RECOVER [CONVERT XID]
seata XA 简介
seata 是阿里推出的一款开源分布式事务解决方案，目前有 AT、TCC、SAGA、XA 四种模式。
seata 的 XA 模式是利用分支事务中数据库对 XA 协定的反对来实现的。咱们看一下 seata 官网的介绍：[1]
从下面的图能够看到，seata XA 模式的流程跟其余模式一样：
TM 开启全局事务
RM 向 TC 注册分支事务
RM 向 TC 报告分支事务状态
TC 向 RM 发送 commit/rollback 申请
TM 完结全局事务
这里介绍一下 RM 客户端初始化关联的 UML 类图：[2]
这个图中有一个类是 AbstractNettyRemotingClient，这个类的外部类 ClientHandler 来解决 TC 发来的申请并委托给父类 AbstractNettyRemoting 的 processMessage 办法来解决。processMessage 办法调用 RmBranchCommitProcessor 类的 process 办法。
须要留神的是，「seata 的 xa 模式对传统的三阶段提交做了优化，改成了两阶段提交」:
第一阶段首执行 XA 开启、执行 sql、XA 完结三个步骤，之后间接执行 XA prepare。
第二阶段执行 XA commit/rollback。
mysql 目前是反对 seata xa 模式的两阶段优化的。
「然而这个优化对 oracle 不反对，因为 oracle 实现的是规范的 xa 协定，即 xa end 后，协调节点向事务参与者对立发送 prepare，最初再发送 commit/rollback。这也导致了 seata 的 xa 模式对 oracle 反对不太好。」
seata XA 源码
seata 中的 XA 模式是应用数据源代理来实现的，须要手动配置数据源代理，代码如下：
@Bean
@ConfigurationProperties(prefix = “spring.datasource”)
public DruidDataSource druidDataSource() {
return new DruidDataSource();}
@Bean(“dataSourceProxy”)
public DataSource dataSource(DruidDataSource druidDataSource) {
return new DataSourceProxyXA(druidDataSource);}
也能够依据一般 DataSource 来创立 XAConnection，然而这种形式有兼容性问题（比方 oracle），所以 seata 应用了开发者本人配置 XADataSource。
seata 提供的 XA 数据源代理，要求代码框架中必须应用 druid 连接池。
- XA 第一阶段
当 RM 收到 DML 申请后，seata 会应用 ExecuteTemplateXA 来执行，执行办法 execute 中有一个中央很要害，就是把 autocommit 属性改为了 false，而 mysql 默认 autocommit 是 true。事务提交之后，还要把 autocommit 改回默认。
上面咱们看一下 XA 第一阶段提交的次要代码。
1）开启 XA
下面代码标注 [1] 处，调用了 ConnectionProxyXA 类的 setAutoCommit 办法，这个办法的源代码中，XA start 次要做了三件事：
向 TC 注册分支事务
调用数据源的 XA Start
xaResource.start(this.xaBranchXid, XAResource.TMNOFLAGS);
把 xaActive 设置为 true
RM 并没有间接应用 TC 返回的 branchId 作为 xa 数据源的 branchId，而是应用全局事务 id(xid) 和 branchId 从新构建了一个。
2）执行 sql
调用 PreparedStatementProxyXA 的 execute 执行 sql。
3）XA end/prepare
public void commit() throws SQLException {
// 省略局部源代码
try {
// XA End: Success
xaResource.end(xaBranchXid, XAResource.TMSUCCESS);
// XA Prepare
xaResource.prepare(xaBranchXid);
// Keep the Connection if necessary
keepIfNecessary();} catch (XAException xe) {
try {
// Branch Report to TC: Failed
DefaultResourceManager.get().branchReport(BranchType.XA, xid, xaBranchXid.getBranchId(),
BranchStatus.PhaseOne_Failed, null);
} catch (TransactionException te) {// 这儿只打印了一个 warn 级别的日志}
throw new SQLException("Failed to end(TMSUCCESS)/prepare xa branch on" + xid + "-" + xaBranchXid.getBranchId() + "since" + xe
.getMessage(), xe);
} finally {cleanXABranchContext();
}}
从这个源码咱们看到，commit 次要做了三件事：
调用数据源的 XA end
调用数据源的 XA prepare
向 TC 报告分支事务状态
到这里咱们就能够看到，seata 把 xa 协定的前两个阶段合成了一个阶段。
2. XA commit
这里的调用关系用一个时序图来示意：
看一下 RmBranchCommitProcessor 类的 process 办法，代码如下：
@Override
public void process(ChannelHandlerContext ctx, RpcMessage rpcMessage) throws Exception {
String remoteAddress = NetUtil.toStringAddress(ctx.channel().remoteAddress());
Object msg = rpcMessage.getBody();
if (LOGGER.isInfoEnabled()) {LOGGER.info("rm client handle branch commit process:" + msg);
}
handleBranchCommit(rpcMessage, remoteAddress, (BranchCommitRequest) msg);}
从调用关系时序图能够看出，下面的 handleBranchCommit 办法最终调用了 AbstractRMHandler 的 handle 办法，最初通过 branchCommit 办法调用了 ResourceManagerXA 类的 finishBranch 办法。
ResourceManagerXA 类是 XA 模式的资源管理器，看上面这个类图，也就是 seata 中资源管理器（RM）的 UML 类图：
下面的 finishBranch 办法调用了 connectionProxyXA.xaCommit 办法，咱们最初看一下 xaCommit 办法：
public void xaCommit(String xid, long branchId, String applicationData) throws XAException {
XAXid xaXid = XAXidBuilder.build(xid, branchId);// 因为应用 mysql，这里 xaResource 是 MysqlXAConnection
xaResource.commit(xaXid, false);
releaseIfNecessary();}
下面调用了数据源的 commit 办法，提交了 RM 分支事务。
到这里，整个 RM 分支事务就完结了。Rollback 的代码逻辑跟 commit 相似。
最初要阐明的是，下面的 xaResource，是 mysql-connector-java.jar 包中的 MysqlXAConnection 类实例，它封装了 mysql 提供的 XA 协定接口。
总结
seata 中 XA 模式的实现是应用数据源代理实现的，底层应用了数据库对 XA 协定的原生反对。
mysql 的 java 驱动库中，MysqlXAConnection 类封装类 XA 协定的底层接口供内部调用。
跟 TCC 和 SAGA 模式须要在业务代码中实现 prepare/commit/rollback 逻辑相比，XA 模式对业务代码无侵入。
原文链接
本文为阿里云原创内容，未经容许不得转载。
