2. Saga 事务模式基础
Saga 是分布式事务领域中最适合长事务与业务流程编排的模式。它通过将一个大事务拆分为多个本地事务，并为每个本地事务定义对应的补偿操作（Compensating Action），在部分步骤失败时依次回滚已提交的步骤，从而在最终一致性模型下保证业务正确性。
2.1 Saga 模式的定义
Saga 的核心思想是：一个全局事务由一组有序的本地子事务组成，每个子事务 Ti 对应一个补偿事务 Ci。当所有 Ti 成功执行，全局事务完成；若某个 Ti 失败，则按逆序依次执行 Ci 进行回滚。
关键特征：
- 无全局锁：每个子事务提交后立即释放资源，不持有跨步骤的锁。
- 最终一致性：允许中间状态对外可见，但最终通过补偿达到一致。
- 补偿驱动：补偿逻辑必须由业务代码显式实现，不能依赖数据库回滚。
2.2 Saga 与 TCC、2PC 的对比
三种模式在一致性强度、资源锁定、适用场景上存在本质差异。下表从多个维度进行对比：
| 对比维度 | Saga | TCC | 2PC |
|---|---|---|---|
| 一致性模型 | 最终一致性 | 最终一致性 | 强一致性（ACID） |
| 资源锁定 | 无锁，提交即释放 | Try 阶段预留资源 | 全局锁至 Commit/Abort |
| 事务粒度 | 本地事务 + 补偿 | Try/Confirm/Cancel 三段 | Prepare/Commit/Rollback |
| 隔离性 | 弱（需业务补偿） | 中（预留可防脏读） | 强（可序列化） |
| 吞吐量 | 高 | 中 | 低（锁竞争） |
| 实现复杂度 | 中（补偿逻辑） | 高（三段接口） | 中（协调器） |
| 典型场景 | 长流程、跨服务编排 | 短事务、资源敏感 | 短事务、强一致要求 |
选型建议：如果业务允许中间状态且需要高吞吐，优先选择 Saga；如果资源必须预留（如库存扣减），TCC 更合适；如果必须强一致且事务时间极短（< 100ms），2PC 仍可考虑。
2.3 Saga 的适用场景
Saga 并非万能，它在以下场景中表现最佳：
- 跨微服务的业务流程编排：如电商下单（库存→订单→支付→物流），每个步骤由不同微服务处理。
- 长事务（秒级到分钟级）：2PC 无法长时间持有锁，Saga 通过补偿避免锁竞争。
- 允许最终一致性的业务：如社交平台发布内容、用户积分累计、异步通知等。
- 需要高可用与高吞吐：Saga 无全局锁，协调器可水平扩展。
不适用场景：
- 要求强隔离性（如资金转账必须避免脏读）——应使用 TCC 或 2PC。
- 补偿逻辑无法实现或成本过高（如发送短信无法撤回）——应避免使用 Saga。
- 子事务之间存在写依赖（后一步依赖前一步的未提交数据）——需重新设计流程。
2.4 Saga 的两种编排模式
Saga 的实现分为编排（Choreography）和协调（Orchestration）两种模式：
| 特性 | 编排模式 | 协调模式 |
|---|---|---|
| 控制方式 | 事件驱动，无中心协调器 | 中心协调器（Orchestrator） |
| 耦合度 | 服务间通过事件耦合 | 服务只与协调器交互 |
| 补偿管理 | 每个服务监听失败事件自行补偿 | 协调器统一调用补偿 |
| 复杂度 | 低（适合简单链路） | 高（适合复杂分支） |
| 可观测性 | 弱（事件流分散） | 强（协调器集中记录） |
实践建议：在鉴权拦截场景中，推荐使用协调模式。因为鉴权逻辑通常需要集中判断事务边界、记录审计日志，协调器可以统一管理鉴权状态与补偿触发，避免鉴权事件在服务间扩散导致安全漏洞。