好的，我来帮你系统讲解 Saga 模式，让你理解它在分布式事务中的作用、工作原理和优缺点。

理解 Saga 模式：分布式事务的优雅解决方案

1️⃣ 背景：为什么需要 Saga

在 分布式系统中，一个业务操作往往涉及多个微服务：

  • 用户下单 → 扣库存 → 扣余额 → 发货
  • 每个操作都在不同的服务和数据库中执行

问题：

  • 传统的 两阶段提交（2PC） 在分布式环境下性能低，容易阻塞资源
  • 网络抖动、服务故障容易导致事务不一致

目标：在 保证最终一致性 的前提下，提高性能和可用性

2️⃣ Saga 模式简介

Saga 是一种 分布式事务处理模式，将一个大事务拆分为多个 局部事务，每个局部事务执行成功后触发下一个事务。

  • 核心思想：用 补偿操作 撤销失败的事务
  • 每个子事务都提交自己的数据，但可以定义失败后的 回滚补偿

Saga 两种实现方式：

类型说明
编排型（Orchestration）一个中心协调者（Saga Coordinator）控制事务顺序，调用每个服务，并在失败时触发补偿
事件型（Choreography）各服务通过事件驱动（消息队列）自发执行下一个事务，失败时发补偿事件

3️⃣ Saga 流程示意

以 电商下单为例：

  1. 用户下单（Order Service 创建订单）
  2. 库存服务扣减库存（Inventory Service）
  3. 支付服务扣减余额（Payment Service）
  4. 发货服务发货（Shipping Service）

补偿逻辑：

  • 库存不足 → 取消订单
  • 支付失败 → 退款
  • 发货失败 → 回退库存、退款

流程图（逻辑描述）：

Order Created
     |
  Deduct Inventory
     |
  Deduct Payment
     |
   Ship Item

如果 Deduct Payment 失败，则触发：

Deduct Inventory → Compensate Inventory (加回库存)
Order Created → Compensate Order (取消订单)

4️⃣ Saga 的优缺点

✅ 优点

  1. 避免全局锁和 2PC 阻塞，提高系统吞吐量
  2. 保证 最终一致性，适合分布式微服务
  3. 可与事件驱动结合，天然支持异步处理

❌ 缺点

  1. 实现复杂，需要设计补偿逻辑
  2. 事务顺序依赖严格，失败补偿链条长
  3. 不保证 强一致性，只保证 最终一致性

5️⃣ 技术实现

  • 编排型 Saga：Netflix Conductor、Camunda、Temporal
  • 事件型 Saga：Kafka、RabbitMQ、RocketMQ 结合微服务事件驱动
  • 框架：Spring Cloud 的 @TransactionalEventListener + Outbox 模式

6️⃣ 实战小结

  1. 适合 跨微服务、多数据库操作
  2. 每个操作要有补偿操作
  3. 可通过 编排型或事件型 实现
  4. 最终目标是 高可用 + 最终一致性

💡 一句话理解：

Saga = 分布式事务的“拆弹专家”，每一步操作可单独执行并补偿，确保最终数据一致，而不是全局锁住所有服务。