分布式事务，原理简单，写起来全是坑！

今天我们就一起来看下另一种模式，XA 模式！

其实我觉得 seata 中的四种不同的分布式事务模式，学完 AT、TCC 以及 XA 就够了，Saga 不好玩，而且长事务本身就有很多问题，也不推荐使用。

Seata 中的 XA 模式实际上是基于 MySQL 的 XA 两阶段提交发展出来的，所以学习 XA 模式，需要小伙伴们先理解 MySQL 中的 XA 是怎么一回事，把 MySQL 中的 XA 搞清楚了，再来学习 Seata 中的 XA 模式就容易的多了。

1. 什么是 XA 规范

1.1 什么是两阶段提交

我们先来稍微回顾一下两阶段提交。

先来看下面一张图：

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

AP：这个不用多说，AP 就是应用程序本身。RM：RM 是资源管理器，也就是事务的参与者，大部分情况下就是指数据库，一个分布式事务往往涉及到多个 RM。TM：TM 就是事务管理器，创建分布式事务并协调分布式事务中的各个子事务的执行和状态，子事务就是指在 RM 上执行的具体操作。

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

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

比如下面一张图：

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

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

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

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

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

1.2 什么是 XA 规范

XA 规范 是 X/Open 组织定义的分布式事务处理（DTP，Distributed Transaction Processing）标准。

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