2. Saga模式概述
Saga模式是分布式事务领域最成熟的补偿型解决方案之一。它通过将一个全局事务拆分为多个本地事务，并为每个本地事务定义对应的补偿操作，从而在保证数据最终一致性的前提下，避免传统XA协议（2PC）的同步阻塞和资源锁定问题。本章将系统阐述Saga模式的定义、核心机制、与TCC/2PC的对比分析，以及其适用场景与局限性。
2.1 Saga模式的定义与核心机制
Saga模式最早由Hector Garcia-Molina和Kenneth Salem在1987年提出，其核心思想是：将一个长事务分解为一组有序的本地子事务（Transaction），每个子事务都对应一个补偿事务（Compensation Transaction）。当所有子事务成功执行，则全局事务完成；若某个子事务失败，则按逆序依次执行已成功子事务的补偿操作，回滚到初始状态。
核心公式： Saga = (T1, C1), (T2, C2), ..., (Tn, Cn)
其中 Ti 为第 i 个本地事务，Ci 为 Ti 的补偿事务。
其中 Ti 为第 i 个本地事务，Ci 为 Ti 的补偿事务。
Saga模式有两种编排方式：
| 编排方式 | 描述 | 典型实现 |
|---|---|---|
| Choreography（ choreography） | 每个微服务在完成本地事务后，通过事件驱动的方式触发下一个子事务或补偿事务；无中心协调器。 | Eventuate Tram、Axon Framework |
| Orchestration（编排） | 由一个中心化的Saga编排器（Orchestrator）负责协调所有子事务的执行顺序和补偿逻辑。 | Camunda、Apache Camel、自定义状态机 |
2.2 Saga与TCC、2PC的对比分析
在分布式事务领域，Saga、TCC（Try-Confirm-Cancel）和2PC（两阶段提交）是三种最具代表性的方案。它们在一致性模型、资源锁定方式、隔离性支持等方面存在显著差异。
| 对比维度 | Saga | TCC | 2PC（XA） |
|---|---|---|---|
| 一致性模型 | 最终一致性 | 最终一致性 | 强一致性 |
| 资源锁定 | 不锁定资源，提交后释放 | Try阶段预留资源 | Prepare阶段锁定资源 |
| 事务隔离性 | 弱隔离（需应用层补偿） | 中等隔离（通过预留实现） | 强隔离（全局锁） |
| 回滚机制 | 补偿事务（业务级回滚） | Cancel操作（业务级回滚） | Rollback（资源级回滚） |
| 同步阻塞 | 无阻塞 | 无阻塞 | 有阻塞（Prepare阶段） |
| 适用场景 | 长事务、跨服务业务流程 | 短事务、资源预留场景 | 短事务、强一致性要求 |
| 典型实现 | Eventuate Tram、Camunda | Seata TCC、ByteTCC | Atomikos、Narayana |
选型建议： 在微服务架构中，Saga模式是最常用的分布式事务方案，因为它避免了2PC的同步阻塞问题，且比TCC更易于实现——TCC要求每个服务提供Try、Confirm、Cancel三个接口，对业务侵入性较大。Saga只需定义正向事务和补偿事务，实现成本更低。
2.3 Saga模式的适用场景
Saga模式特别适合以下场景：
- 跨微服务的业务流程：如订单创建（订单服务→库存服务→支付服务→物流服务），每个步骤都是独立的本地事务。
- 长事务场景：事务执行时间可能从几秒到几分钟，2PC的长时间锁定不可接受。
- 高并发、低延迟要求：Saga不持有数据库锁，不会导致行锁竞争和死锁。
- 业务补偿逻辑明确：每个正向操作都有对应的逆向操作（如扣减库存→增加库存、扣款→退款）。
- 最终一致性可接受：业务允许在短时间内存在中间状态，最终达到一致。
2.4 Saga模式的优缺点
| 优点 | 缺点 |
|---|---|
| 1. 无资源锁定：不持有数据库锁，高并发下性能优异 | 1. 弱隔离性：子事务提交后对其他事务可见，可能出现脏读 |
| 2. 异步非阻塞：子事务可并行或异步执行，吞吐量高 | 2. 补偿逻辑复杂：补偿事务必须幂等，且需处理部分成功场景 |
| 3. 业务侵入性低：只需定义正向+补偿，无需改造资源层 | 3. 调试困难：分布式链路追踪和状态回溯较复杂 |
| 4. 弹性好：单个服务故障不影响其他服务，补偿可异步执行 | 4. 缺乏全局一致性视图：无法像2PC那样提供ACID保证 |
| 5. 支持长事务：事务跨度可达分钟级甚至小时级 | 5. 编排器单点风险：Orchestration模式下编排器可能成为瓶颈 |
关键避坑： Saga模式不提供事务隔离性。在补偿执行期间，其他事务可能读取到已提交但后续会被补偿回滚的数据（脏读）。解决方案包括：
① 在应用层使用“状态字段”标记数据是否最终有效；
② 采用“预留+确认”模式（类似TCC的Try阶段）；
③ 使用Saga的“Countermeasure”模式，在读取时检查数据版本或状态。
① 在应用层使用“状态字段”标记数据是否最终有效；
② 采用“预留+确认”模式（类似TCC的Try阶段）；
③ 使用Saga的“Countermeasure”模式，在读取时检查数据版本或状态。
2.5 Saga模式的核心设计原则
在实际落地Saga模式时，必须遵循以下设计原则：
- 补偿幂等性：补偿事务必须支持重复执行，且结果一致。例如退款接口需支持同一笔订单多次退款不重复扣款。
- 正向与补偿可交换：正向事务和补偿事务在逻辑上互为逆操作，且补偿不能依赖正向事务的上下文（因为正向可能已失败）。
- 状态持久化：Saga的执行状态必须持久化到数据库，以便在服务重启后恢复执行或补偿。
- 超时与重试机制：每个子事务和补偿事务都应设置超时时间，超时后触发重试或人工介入。
- 最终补偿保证：即使补偿事务失败，系统也应通过重试队列或定时任务持续尝试，直到补偿成功或人工介入。
上图展示了Orchestration模式下Saga的补偿执行流程：正向事务T1、T2成功执行后，T3失败，编排器立即触发逆序补偿——先执行C2（恢复余额），再执行C1（恢复库存），最终系统回到初始状态。注意：T4（发送通知）尚未执行，因此无需补偿。
实战要点： 在实现Saga补偿时，务必为每个补偿操作设计幂等键（如事务ID+步骤序号），确保补偿操作重复执行不会产生副作用。同时，建议将Saga执行日志持久化到独立的Saga日志表，便于故障恢复和人工审计。