简介

Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式事务解决方案。

🚀 一、Seata 的四种主要模式

Seata 提供的分布式事务解决方案有：

1. AT 模式（Automatic Transaction，默认模式）
2. TCC 模式（Try-Confirm-Cancel）
3. SAGA 模式（长事务补偿型）
4. XA 模式（基于数据库 XA 协议）

下面我逐一拆解：

---

1️⃣ AT 模式（自动事务模式）

🔹 原理

• 基于 本地事务 + Undo Log 实现，两阶段提交。
• 阶段一：执行业务 SQL，生成 前后镜像，并写入 undo log。
• 阶段二：根据全局事务结果来 提交（删除 undo log） 或 回滚（利用 undo log 恢复数据）。

🔹 举例

下单 → 扣库存 → 扣余额。

• 阶段一：库存 stock=100 → 99，undo log 记录 before=100, after=99。
• 阶段二：若失败，回滚时用 undo log 恢复 stock=100。

🔹 特点

✅ 优点：透明、接入简单、开发成本低（像本地事务一样写 SQL）。
❌ 缺点：只支持 关系型数据库，性能依赖 undo log。

👉 应用场景：
适合 大多数互联网电商/订单类系统，数据一致性要求较高，且数据库是关系型的。

---

2️⃣ TCC 模式（Try-Confirm-Cancel）

🔹 原理

• 应用层显式定义两阶段逻辑。
• Try：资源预留。
• Confirm：业务确认。
• Cancel：业务回滚。

🔹 举例

转账：从 A → B 转 100。

• Try 阶段：冻结 A 的 100 元。
• Confirm 阶段：扣除冻结金额，B 账户加 100。
• Cancel 阶段：解冻 A 的 100 元（回滚）。

🔹 特点

✅ 优点：性能高，灵活，能处理 非数据库资源（比如调用第三方服务）。
❌ 缺点：开发成本高，需要写三套逻辑（Try、Confirm、Cancel）。

👉 应用场景：
适合 金融交易、积分兑换、优惠券发放 等对资源预留要求高的场景。

---

3️⃣ SAGA 模式（长事务补偿型）

🔹 原理

• 长事务分解为一系列本地事务。
• 每个本地事务都必须提供 正向操作（Action） 和 补偿操作（Compensation）。
• 如果中途失败，通过补偿操作逆向回滚。

🔹 举例

机票 + 酒店 + 租车 预订：

• Action：订机票成功 → 订酒店成功 → 订租车成功。
• 如果订租车失败 → 执行补偿：取消酒店 → 取消机票。

🔹 特点

✅ 优点：适合 长事务，执行时间长、跨多个系统。
❌ 缺点：补偿操作可能很复杂，而且补偿不一定能保证完全幂等。

👉 应用场景：
适合 旅游预订、电商大促销活动、大批量异步任务 等。

---

4️⃣ XA 模式（基于数据库 XA 协议）

🔹 原理

• 基于数据库 XA 协议 实现两阶段提交。
• 阶段一：RM 向数据库发送 prepare，数据库执行事务但不提交。
• 阶段二：根据全局事务结果，发送 commit 或 rollback。

🔹 举例

A 数据库转账 → B 数据库：

• 阶段一：A/B 数据库都 prepare。
• 阶段二：都 commit，或者都 rollback。

🔹 特点

✅ 优点：强一致性，数据库级别保证。
❌ 缺点：性能低，依赖数据库的 XA 支持，锁的粒度较大。

👉 应用场景：
适合 对强一致性要求极高的金融场景，但性能瓶颈较明显。

---

🚀 二、四种模式对比

模式	一致性	性能	适用场景	开发成本
AT	强一致	高	电商、订单、支付	低（透明接入）
TCC	强一致	最高	金融交易、库存冻结	高（需写3套逻辑）
SAGA	最终一致	中	旅游预订、大促销、长事务	中（需写补偿）
XA	强一致	低	银行、证券	低（依赖数据库）

---

🚀 三、总结（通俗理解）

• AT 模式：像“写日记”，每次改动前后都记下来，出错就翻回去。
• TCC 模式：像“预定房间”，先 Try 预留，确认后付款，不要就取消。
• SAGA 模式：像“旅游订票”，一步步订票，如果最后失败，就退票。
• XA 模式：像“银行转账”，两个银行同时锁定账户，确认后一起提交。

---

1️⃣ AT 模式 (自动补偿)

---

2️⃣ TCC 模式 (Try-Confirm-Cancel)

---

3️⃣ SAGA 模式 (长事务补偿)

---

4️⃣ XA 模式 (两阶段提交)