Seata 是如何解决分布式事务的呢？

Seata 是如何解决分布式事务的呢？

在微服务架构中，一个业务往往需要调用多个服务，分别操作多个数据库，进而引发分布式事务问题。如果某个环节失败而无法回滚整个链路，便会造成数据不一致。Seata 是阿里开源的分布式事务解决方案，它通过多种事务模式，帮助我们解决这一难题。

Seata支持四种不同的分布式事务解决方案：

• XA
• TCC
• AT
• SAGA

一、XA 模式

• XA 规范 是 X/Open 组织定义的分布式事务处理（DTP，Distributed Transaction Processing）标准
• XA 规范 描述了全局的TM与局部的RM之间的接口，几乎所有主流的数据库都对 XA 规范 提供了支持

1️⃣两阶段提交原理

A是规范，目前主流数据库都实现了这种规范，实现的原理都是基于两阶段提交。

• 正常情况：
  

• 异常情况：
  

• 第一阶段（准备阶段）：

  • 全局事务协调者（TM）通知各参与者（RM）预提交事务。
  • 各参与者执行本地事务操作但不提交，并将状态标记为“准备好”。

• 第二阶段（提交/回滚阶段）：

  • 如果所有参与者都“准备好”，协调者通知各参与者提交事务。
  • 如果有任一参与者失败，则协调者通知所有参与者回滚事务。

2️⃣Seata 的 XA 模型

Seata对原始的XA模式做了简单的封装和改造，以适应自己的事务模型

• Seata 的 Transaction Coordinator（TC）扮演全局协调者角色。
• 各微服务的数据源通过 DataSourceProxy 接入 Seata，作为事务参与者。
• Seata 负责全局事务的开始、提交和回滚，结合数据库的 XA 协议。

基本架构如图：

RM一阶段的工作：

1. 注册分支事务到TC
2. 执行分支业务sql但不提交
3. 报告执行状态到TC

TC二阶段的工作：

1. TC检测各分支事务执行状态
   a. 如果都成功，通知所有RM提交事务
   b. 如果有失败，通知所有RM回滚事务

RM二阶段的工作：

• 接收TC指令，提交或回滚事务

3️⃣XA 模式的优缺点

✅ 优点：

• 严格的两阶段提交协议，数据强一致性。
• 借助数据库原生 XA 能力，无需业务侵入。
• 支持多语言、多协议。

❌ 缺点：

• 数据库的 XA 协议实现不一，兼容性有限。
• 性能开销大，特别是需要频繁加锁和日志记录。
• 耦合度高，受制于数据库对 XA 的支持程度。

4️⃣实现步骤

• 在配置文件中指定要采用的分布式事务模式

seata:
  data-source-proxy-mode: XA

• 利用@GlobalTransactional标记分布式事务的入口方法

二、AT 模式

AT模式同样是分阶段提交的事务模型，不过缺弥补了XA模型中资源锁定周期过长的缺陷。

1️⃣Seata 的 AT 模型

相比 XA，AT 模式是 Seata 的默认事务模式，属于无侵入式分布式事务解决方案
基于数据库的本地事务能力（通过 JDBC）来完成分布式控制，且性能优于 XA

AT 模式的核心思想是：

• 业务执行时：拦截 SQL 语句，记录“前镜像”和“后镜像”数据。
• 提交事务时：同时记录全局提交点。
• 回滚时：通过“前镜像”恢复数据。

基本流程图：

阶段一RM的工作：

• 注册分支事务
• 记录undo-log（数据快照）
• 执行业务sql并提交
• 报告事务状态

阶段二提交时RM的工作：

• 删除undo-log即可

阶段二回滚时RM的工作：

• 根据undo-log恢复数据到更新前

三、AT 与 XA 模式的区别