https://seata.io/zh-cn/docs/user/mode/xa
https://seata.io/zh-cn/docs/dev/mode/xa-mode
XA 规范 是 X/Open 组织定义的分布式事务处理（DTP，Distributed Transaction Processing）标准，XA 规范 描述了全局的TM与局部的RM之间的接口，几乎所有主流的数据库都对 XA 规范 提供了支持。
XA 模式是从 1.2 版本支持的事务模式。XA 规范 是 X/Open 组织定义的分布式事务处理（DTP，Distributed Transaction Processing）标准。Seata XA 模式是利用事务资源（数据库、消息服务等）对 XA 协议的支持，以 XA 协议的机制来管理分支事务的一种事务模式。
前提
- 基于支持本地 ACID 事务的关系型数据库。
- Java 应用，通过 JDBC 访问数据库。
两阶段提交
XA是规范，目前主流数据库都实现了这种规范，实现的原理都是基于两阶段提交。
正常情况：
异常情况：
一阶段：
- 事务协调者通知每个事物参与者执行本地事务
- 本地事务执行完成后报告事务执行状态给事务协调者，此时事务不提交，继续持有数据库锁
二阶段：
- 事务协调者基于一阶段的报告来判断下一步操作
- 如果一阶段都成功，则通知所有事务参与者，提交事务
- 如果一阶段任意一个参与者失败，则通知所有事务参与者回滚事务
4.1.2.Seata的XA模型
Seata对原始的XA模式做了简单的封装和改造，以适应自己的事务模型，基本架构如图：
RM一阶段的工作：
① 注册分支事务到TC
② 执行分支业务sql但不提交
③ 报告执行状态到TC
TC二阶段的工作：
-
TC检测各分支事务执行状态
a.如果都成功，通知所有RM提交事务
b.如果有失败，通知所有RM回滚事务
RM二阶段的工作：
- 接收TC指令，提交或回滚事务
优缺点
XA模式的优点是什么？
- 事务的强一致性，满足ACID原则。
- 常用数据库都支持，实现简单，并且没有代码侵入
XA模式的缺点是什么？
- 因为一阶段需要锁定数据库资源，等待二阶段结束才释放，性能较差
- 依赖关系型数据库实现事务
实现XA模式
Seata的starter已经完成了XA模式的自动装配，实现非常简单，步骤如下：
1）修改application.yml文件（每个参与事务的微服务），开启XA模式：
seata:
enabled: true
tx-service-group: default_tx_group # 事务组名称
service:
vgroup-mapping:
default_tx_group: default
grouplist:
default: 127.0.0.1:8091
data-source-proxy-mode: XA
2）给发起全局事务的入口方法添加@GlobalTransactional注解:
本例中是OrderServiceImpl中的create方法.
四种模式对比
我们从以下几个方面来对比四种实现：
- 一致性：能否保证事务的一致性？强一致还是最终一致？
- 隔离性：事务之间的隔离性如何？
- 代码侵入：是否需要对业务代码改造？
- 性能：有无性能损耗？
- 场景：常见的业务场景
如图：
