深入浅出分布式事务原理

一、Seata 四大事务模式详解

模式	实现机制	事务一致性	业务侵入性	适用场景
AT	数据库本地事务 + Undo日志 + 二阶段提交	最终一致性	无侵入	电商、订单等高性能要求
TCC	Try-Confirm-Cancel	强一致性	强业务侵入	金融支付、账户、转账等
SAGA	补偿事务（前进+回滚）	最终一致性	轻微侵入	长事务，如营销活动
XA	标准XA协议	强一致性	无侵入	银行、转账等

---

二、逐个详细拆解每一种事务模式

---

1. AT 模式（Automatic Transaction，自动事务）

原理：

• 基于 两阶段提交协议（改良版 2PC）。
• 借助 本地事务 + Undo日志 + 全局事务协调 实现。
• 适合 单体数据库 场景下，分布式服务调用。

2PC：两阶段提交
阶段一（准备阶段）：
协调者让所有参与者准备事务（执行但不提交，预留资源）。
每个参与者返回准备成功或失败。

阶段二（提交阶段）：
所有参与者都准备成功：协调者通知提交。
有任一失败：协调者通知所有参与者回滚。
这是标准的数据库层面的实现（XA）

流程详解：

第一阶段（执行业务+记录日志）

• TM 开启全局事务，生成 XID。
• 各服务作为 RM，执行本地事务，操作数据库时：
  • 自动生成 Undo 日志（记录数据修改前的快照）。
• 本地事务提交。
• 注册分支事务到 TC。

第二阶段（事务提交或回滚）

• 如果全部成功，TC 通知所有分支 提交，删除 Undo 日志。
• 任一失败，TC 通知所有分支 回滚，依据 Undo 日志进行数据回滚。

⚙️ 核心机制：

问题	解决方式
脏读/幻读/不可重复读	MVCC + 行锁
数据一致性	Undo 日志 + 全局锁
高性能问题	异步提交/回滚，避免长时间阻塞资源

✅ 特点：

• 开发简单，无业务侵入。
• 高性能，适合高并发系统。
• 缺点：依赖关系型数据库，不适合跨 NoSQL。

---

2. TCC 模式（Try-Confirm-Cancel，补偿事务）

原理：

• 业务层面三段式协议，由开发者明确实现 预留资源、确认执行、回滚撤销。
• 适合复杂操作需要严格控制流程的一致性。

流程详解：

第一阶段（Try）

• 预留资源，做资源检查、冻结资源（如账户扣钱但不真正转账）。
• 如果失败，立即 Cancel。

第二阶段（Confirm）

• 确认执行：真正转账、扣钱。

第三阶段（Cancel）

• 如果某一分支失败，则回滚预留操作，释放资源（如退回冻结金额）。

⚙️ 核心机制：

问题	解决方式
数据一致性	通过 Try 阶段资源预留，Confirm 正式执行
幂等性	Try/Confirm/Cancel 方法需幂等处理

✅ 特点：

• 强一致性。
• 适合资金支付、银行、库存等场景。
• 缺点：需要自己实现 TCC 接口，开发复杂，侵入性强。

---

3. SAGA 模式（长事务/补偿事务）

原理：

• 针对长事务，按步骤执行，每一步有对应的 正向动作 + 补偿动作。
• 补偿机制恢复一致性。

流程详解：

正向操作

• 事务拆分为多个步骤顺序执行（如扣钱、发货、通知）。
• 每一步成功，执行下一步。

补偿操作

• 如果某一步失败，从当前步骤逆向调用补偿接口（如退款、取消发货）。
• 最终恢复一致性。

⚙️ 核心机制：

问题	解决方式
长事务性能问题	拆分为局部事务，避免长时间锁定
数据一致性	补偿接口执行反向操作

✅ 特点：

• 最终一致性，适合营销、订单处理等长事务。
• 非阻塞，性能高。
• 缺点：需要设计补偿接口，部分数据不可逆难处理。

---

4. XA 模式（标准分布式事务协议）

原理：

• 数据库自带 XA 协议。
• 标准 两阶段提交（2PC）。
• 数据库级别事务协调，强一致。

流程详解：

第一阶段（prepare 阶段）

• 每个分支事务执行并进入预提交，锁住资源。

第二阶段（commit/rollback 阶段）

• 全部预提交成功，通知所有分支事务提交。
• 任一失败，通知全部回滚。

⚙️ 核心机制：

问题	解决方式
一致性	预提交锁资源，最终统一提交/回滚
数据持久性	数据库自身实现持久性和日志记录

✅ 特点：

• 强一致性。
• 跨数据库一致事务（如多数据源）。
• 缺点：阻塞，性能差，不适合高并发，只有支持 XA 的数据库才可用（如 MySQL、Oracle）。

---

三、四种事务模式总结对比表

模式	一致性	性能	侵入性	适用场景	事务过程
AT	最终一致性	高	无侵入	电商、订单、库存等	自动生成 Undo 日志，二阶段提交
TCC	强一致性	较高	强侵入	金融、支付、账户	Try-Confirm-Cancel 手动实现
SAGA	最终一致性	高	轻侵入	长事务（营销、订单等）	正向步骤 + 补偿步骤
XA	强一致性	低	无侵入	银行、转账等	标准 XA 两阶段提交协议

---

XA和AT的事务流程对比：

AT 模式

基于本地事务 + Undo 日志：
每个分支事务在本地执行时，就像普通数据库操作一样，直接提交，但会自动生成 Undo 日志来记录数据修改前的状态。
最终一致性：
全局事务协调器（TC）在各个分支事务都执行完后，再统一决定全局确认成功或回滚。如果决定回滚，各个分支会利用 Undo 日志进行数据恢复。
非阻塞特性：
分支事务在执行完本地操作后即释放数据库锁，不需要在整个全局事务期间一直占用资源。
XA 模式

基于数据库原生 XA 协议：
使用数据库内置的两阶段提交（2PC）机制。分支事务在进入 prepare 阶段后，会锁住资源直到全局事务协调器做出最终决策。
强一致性：
所有参与者在 prepare 阶段锁定资源，必须等到所有分支都准备好后，才能统一提交或回滚。
阻塞特性：
由于分支事务在 prepare 阶段会一直持有锁资源，整个事务期间会对数据库性能产生较大影响，尤其在高并发场景下。

四、结论总结

• 如果你要开发高性能系统且允许最终一致，首选 AT 模式。
• 如果你要强一致如银行支付，选 TCC 或 XA。
• 如果你要处理长事务，如用户订单、营销活动等，选 SAGA。
• 多库之间事务，可选 XA（支持度有限）。

---