本文已参与「新人创作礼」活动，一起开启掘金创作之路。
0. 引言
前几章咱们聊了四种分布式事务中的前三种，今天就最后一种XA模式，来做详细讲解。如果对于前三种模式感兴趣的同学，可以看看专栏之前的博文。
1. XA模式
我们先看看百度百科中XA的定义：
XA协议由Tuxedo首先提出的，并交给X/Open组织，作为资源管理器（数据库）与事务管理器的接口标准。Oracle、Informix、DB2和Sybase等各大数据库厂家都提供对XA的支持。XA协议采用两阶段提交方式来管理分布式事务。XA接口提供资源管理器与事务管理器之间进行通信的标准接口。XA协议包括两套函数，以xa_开头的及以ax_开头的
XA协议主要定义了事务管理些（TM）和资源管理器（RM）之间的接口，mysql从5.0版本开始，innodb存储引擎就支持XA协议了。
如果看过前面的AT模式的，那么再理解XA模式就容易很多，XA模式流程也是分为两阶段提交：
第一阶段：事务发起者TM向TC申请开启全局事务，被调用的各个服务即RM向TC注册各自的本地事务。RM执行完本地事务但还不真正提交，会向TC报告执行状态。
第二阶段：如果各个本地事务都执行成功，则TC向各个RM发送提交的指令，各个本地事务真正提交。如果有本地事务执行不成功，则TC会向各个已经执行的RM发送回退的指令。 看到这里大家能体会到XA模式与AT模式的区别吗？
我们再回顾下AT模式：
第一阶段：事务发起者TM向TC申请开启全局事务，被调用的各个服务即RM向TC注册各自的本地事务。RM生成undo log并保存到undo log表，执行完就会提交事务，会向TC报告执行状态。
第二阶段：如果各个本地事务都执行成功，则TC向各个RM发送删除undo log、全局行锁、before image,after image等资源。如果执行失败，通过undo log回滚事务。
两个模式的核心区别在哪儿？
那就是AT模式的RM在本地事务执行完成后就会提交事务，不会占用本地资源。而XA模式则是在所有的本地事务执行完成后，TC才发送指令让所有的RM提交事务、释放本地锁。
这样的机制使得XA占用的资源多，时间长，并发下性能低。但好处是什么呢？就是强一致性，因为都是它一个人占着，不全部用玩就不放手，其一致性可想而知。因此XA模式是不会出现脏读的。
需要注意的是，XA模式是需要数据库本身支持XA协议的，和AT模式一样，受制于存储数据库的自身的特性。
2. seata实现XA模式
seata中实现XA模式非常简单，同AT模式一样也是无代码入侵的，甚至用法都是一样：在调用方法上加入@GlobalTransactional注解即可
唯一要调整的是将数据源代理修改为XA模式：
@Bean("dataSource")
public DataSource dataSource(DruidDataSource druidDataSource) {
// DataSourceProxy for AT mode
// return new DataSourceProxy(druidDataSource);
// DataSourceProxyXA for XA mode
return new DataSourceProxyXA(druidDataSource);
}
复制代码应用场景
XA模式是分布式强一致性的解决方案，但性能低而使用较少，所以对它的介绍也相对简单。
适用于对性能要求低，但要求强一致性的业务场景。