先来看下面一张图：

这张图里涉及到三个概念：

那么什么是两阶段(Two-Phase Commit, 简称 2PC)提交？

两阶段提交说白了道理很简单，松哥举个简单例子来和大家说明两阶段提交：

比如下面一张图：

我们在 Business 中分别调用 Storage 与 Order、Account，这三个中的操作要同时成功或者同时失败，但是由于这三个分处于不同服务，因此我们只能先让这三个服务中的操作各自执行，三个服务中的事务各自执行就是两阶段中的第一阶段。

第一阶段执行完毕后，先不要急着提交，因为三个服务中有的可能执行失败了，此时需要三个服务各自把自己一阶段的执行结果报告给一个事务协调者（也就是前面文章中的 Seata Server），事务协调者收到消息后，如果三个服务的一阶段都执行成功了，此时就通知三个事务分别提交，如果三个服务中有服务执行失败了，此时就通知三个事务分别回滚。

这就是所谓的两阶段提交。

总结一下：两阶段提交中，事务分为参与者（例如上图的各个具体服务）与协调者（上文案例中的 Seata Server），参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是要提交操作还是中止操作，这里的参与者可以理解为 RM，协调者可以理解为 TM。

不过 Seata 中的各个分布式事务模式，基本都是在二阶段提交的基础上演化出来的，因此并不完全一样，这点需要小伙伴们注意。

XA 规范描述了全局的事务管理器与局部的资源管理器之间的接口。 XA规范的目的是允许多个资源（如数据库，应用服务器，消息队列等）在同一事务中访问，这样可以使 ACID 属性跨越应用程序而保持有效。

XA 规范使用两阶段提交来保证所有资源同时提交或回滚任何特定的事务。

XA 规范在上世纪 90 年代初就被提出。目前，几乎所有主流的数据库都对 XA 规范提供了支持。

XA 事务的基础是两阶段提交协议。需要有一个事务协调者来保证所有的事务参与者都完成了准备工作(第一阶段)。如果协调者收到所有参与者都准备好的消息，就会通知所有的事务都可以提交了（第二阶段）。MySQL 在这个 XA 事务中扮演的是参与者的角色，而不是协调者(事务管理器)。

MySQL 的 XA 事务分为内部 XA 和外部 XA。外部 XA 可以参与到外部的分布式事务中，需要应用层介入作为协调者；内部 XA 事务用于同一实例下跨多引擎事务，由 Binlog 作为协调者，比如在一个存储引擎提交时，需要将提交信息写入二进制日志，这就是一个分布式内部 XA 事务，只不过二进制日志的参与者是 MySQL 本身。 MySQL 在 XA 事务中扮演的是一个参与者的角色，而不是协调者。

上面这段事务提交是一个两阶段事务提交的案例。

具体执行步骤如下：

最后一步，可以通过 XA COMMIT 来提交，也可以通过 XA ROLLBACK 来回滚，回滚后事务的状态就是 ROLLBACK。

另外第四步可以省略，即一个 IDLE 状态的 XA 事务可以直接提交或者回滚。

我们来看下面一张流程图：

从这张图里我们可以看出，事务可以一步提交，也可以两阶段提交，都是支持的。如果是两阶段提交，prepare 之后，其实是在等其他的资源管理器（RM）反馈结果。

这个就比较简单，没啥好说的。

这块再跟大家介绍另外一个 XA 事务相关的命令 XA RECOVER ，如下图：

XA RECOVER 可以列出所有处于 PREPARE 状态的 XA 事务，其他状态的事务则都不会列出来，如上图。

小伙伴们看到， xa recover 可以查看处于 prepare 状态的事务，事务回滚有三个参数：第一个参数，是以 gtrid_length 为依据，从 data 字符串上截取下来的值；第二个参数，是第一个从 data 上截取下来值之后，data 剩余的值，在本案例中，第一次被截取之后，就不剩了，所以第二个参数是一个空字符串；第三个参数是 formatID 的值。

回滚之后，再执行 xa recover 就看不到东西了。

相反的，如果已经使用 START TRANSACTION 启动一个本地事务，则 XA 语句不能被使用，直到该事务被提交或者回滚为止，而且 XA 事务仅仅被 InnoDB 存储引擎支持。

通过上面的介绍，大家已经知道了 MySQL 中的 XA 事务是怎么回事了，Seata 中的 XA 模式其实就是在 MySQL 中 XA 模式的基础上实现的。Seata 中的 XA 模式就是在 Seata 定义的分布式事务框架内，利用事务资源（数据库、消息服务等）对 XA 协议的支持，以 XA 协议的机制来管理分支事务的一种事务模式。

我们来看下面一张图：

我来大概说一下这个执行步骤：

这就是 Seata 中的 XA 模式！只要小伙伴们理解了 2.2 小节中 MySQL 的 XA 模式，那么 Seata 中的 XA 模式就很好理解了。

好啦，比较完啦，那就上代码吧！

接下来我就来说几个要点。

这是一个坑。松哥经过反复测试，seata 中的 XA 模式和最新版的 MySQL 驱动不兼容，运行时候会有错误，经过测试，MySQL 8.0.11 这个版本的驱动是没问题的，所以在 account、storage 以及 order 三个需要数据库调用的服务上，记得修改一下数据库驱动依赖的版本号：

1
2
3
4
5
6

<dependency>
    <groupId>mysql</groupId>
    <artifactId>mysql-connector-java</artifactId>
    <scope>runtime</scope>
    <version>8.0.11</version>
</dependency>

有的小伙伴们看到这里用到了阿里的 Druid 数据库连接池，就赶紧加入这个依赖！殊不知，这又掉入版本兼容的坑了， spring-cloud-starter-alibaba-seata 依赖中实际上包含了 druid 依赖，而且版本号是没有问题的！所以小伙伴们千万别自己手动加 druid 依赖，可能会因为版本号问题掉坑。

接下来就是关闭掉 seata 数据源代理了，account、storage 以及 order 里边都改一下，加入如下配置：

1

seata.enable-auto-data-source-proxy=false

接下来就是配置自定义数据源了，account、order 以及 storage 都要配置，如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

@Configuration
public class DataSourceConfiguration {

    @Bean
    @ConfigurationProperties(prefix = "spring.datasource")
    public DruidDataSource druidDataSource() {
        return new DruidDataSource();
    }

    @Bean("dataSourceProxy")
    @Primary
    public DataSource dataSource(DruidDataSource druidDataSource) {
        return new DataSourceProxyXA(druidDataSource);
    }


    @Bean
    public SqlSessionFactory sqlSessionFactory(DataSource dataSourceProxy)throws Exception{
        SqlSessionFactoryBean sqlSessionFactoryBean = new SqlSessionFactoryBean();
        sqlSessionFactoryBean.setDataSource(dataSourceProxy);
        sqlSessionFactoryBean.setTransactionFactory(new SpringManagedTransactionFactory());
        return sqlSessionFactoryBean.getObject();
    }

}

先配置 DruidDataSource，但这不是我们最终目的，最终目的是配置 DataSourceProxyXA，看名字就知道，这就会把事务切换为 XA 模式，最后，还需要基于 DataSourceProxyXA 来配置一下 MyBatis，都是常规操作，不多说。

好啦，就这样，我们的 seata XA 模式就配置好啦～其他的代码都和 AT 模式一样，不再赘述。