介绍分布式事务之Seata
简介
Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式事务解决方案。
🚀 一、Seata 的四种主要模式
Seata 提供的分布式事务解决方案有：
- AT 模式（Automatic Transaction，默认模式）
- TCC 模式（Try-Confirm-Cancel）
- SAGA 模式（长事务补偿型）
- 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 模式：像“银行转账”，两个银行同时锁定账户，确认后一起提交。