『』分布式事务如何实现？深入解读 Seata 的 XA 模式( 二 )

本文插图

执行阶段：

调用业务定义的 Try 方法（完全由业务层面保证可回滚和持久化）

完成阶段：

分支提交：调用各事务分支定义的 Confirm 方法
分支回滚：调用各事务分支定义的 Cancel 方法

1.3 什么是 Seata 的 XA 模式？
XA 模式：
在 Seata 定义的分布式事务框架内，利用事务资源（数据库、消息服务等）对 XA 协议的支持，以 XA 协议的机制来管理分支事务的一种事务模式。

本文插图

执行阶段：

可回滚：业务 SQL 操作放在 XA 分支中进行，由资源对 XA 协议的支持来保证可回滚
持久化：XA 分支完成后，执行 XA prepare ，同样，由资源对 XA 协议的支持来保证持久化（即，之后任何意外都不会造成无法回滚的情况）

完成阶段：

分支提交：执行 XA 分支的 commit
分支回滚：执行 XA 分支的 rollback

2. 为什么支持 XA？
为什么要在 Seata 中增加 XA 模式呢？支持 XA 的意义在哪里呢？
2.1 补偿型事务模式的问题
本质上， Seata 已经支持的 3 大事务模式：AT、TCC、Saga 都是补偿型的。
补偿型事务处理机制构建在事务资源之上（要么在中间件层面，要么在应用层面），事务资源本身对分布式事务是无感知的。

本文插图
事务资源对分布式事务的无感知存在一个根本性的问题：无法做到真正的全局一致性。
比如，一条库存记录，处在补偿型事务处理过程中，由 100 扣减为 50 。此时，仓库管理员连接数据库，查询统计库存，就看到当前的 50 。之后，事务因为异外回滚，库存会被补偿回滚为 100 。显然，仓库管理员查询统计到的 50 就是脏数据。
可以看到，补偿型分布式事务机制因为不要求事务资源本身（如数据库）的机制参与，所以无法保证从事务框架之外的全局视角的数据一致性。
2.2 XA 的价值
与补偿型不同， XA 协议要求事务资源本身提供对规范和协议的支持。

本文插图
因为事务资源感知并参与分布式事务处理过程，所以事务资源（如数据库）可以保障从任意视角对数据的访问有效隔离，满足全局数据一致性。
比如，上一节提到的库存更新场景， XA 事务处理过程中，中间态数据库存 50 由数据库本身保证，是不会仓库管理员的查询统计看到的。（当然隔离级别需要读已提交以上）
除了全局一致性这个根本性的价值外，支持 XA 还有如下几个方面的好处：

业务无侵入：和 AT 一样， XA 模式将是业务无侵入的，不给应用设计和开发带来额外负担。
数据库的支持广泛：XA 协议被主流关系型数据库广泛支持，不需要额外的适配即可使用。
多语言支持容易：因为不涉及 SQL 解析， XA 模式对 Seata 的 RM 的要求比较少，为不同语言开发 SDK 较之 AT 模式将更薄，更容易。
传统基于 XA 应用的迁移：传统的，基于 XA 协议的应用，迁移到 Seata 平台，使用 XA 模式将更平滑。

2.3 XA 广泛被质疑的问题