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

分布式事务，我们已经给小伙伴介绍了整体内容：

• 一文搞明白分布式事务解决方案！真的 so easy！

AT 模式的实现：

• 手把手带领小伙伴们写一个分布式事务案例！

AT 模式在多数据源中的应用：

• Spring Boot 多数据源如何处理事务？教你一招！

今天我们就一起来看下另一种模式，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），事务协调者收到消息后，如果三个服务的一阶段都执行成功了，此时就通知三个事务分别提交，如果三个服务中有服务执行失败了，此时就通知三个事务分别回滚。