1. Saga模式概述
1.1 Saga模式的定义
Saga是一种用于管理长活事务的分布式事务模式，由1987年Hector Garcia-Molina和Kenneth Salem在论文中首次提出。它将一个全局事务拆分为一组本地事务（Local Transaction），每个本地事务对应一个微服务内的ACID操作，并为每个本地事务配备一个补偿事务（Compensating Transaction）。当某个本地事务失败时，Saga引擎会按逆序依次执行已成功事务的补偿操作，从而回滚整个业务流程。
核心特征：Saga不依赖数据库层面的全局锁或两阶段提交，而是通过业务逻辑层面的补偿机制实现最终一致性。
1.2 Saga与TCC/2PC的核心区别
下表从一致性模型、资源锁定、隔离性、适用场景四个维度对比三种主流分布式事务方案：
| 对比维度 | 2PC（两阶段提交） | TCC（Try-Confirm-Cancel） | Saga |
|---|---|---|---|
| 一致性模型 | 强一致性（ACID） | 最终一致性 | 最终一致性 |
| 资源锁定 | 全局锁，阻塞资源 | Try阶段预留资源 | 无全局锁，不阻塞 |
| 隔离性 | 可串行化 | 业务层控制隔离 | 弱隔离（需语义补偿） |
| 适用场景 | 短事务、低并发、同构数据库 | 高并发、资源预留型业务 | 长事务、跨微服务、高可用 |
| 典型代表 | XA协议、Seata AT | Seata TCC、Hmily | Axon、Eventuate、Seata Saga |
选型建议：如果业务对强一致性有硬性要求且并发量低，优先考虑2PC；如果业务需要高吞吐且资源可预留，TCC更合适；如果业务流程跨越多个微服务且执行时间长（如订单、物流、支付组合），Saga是最佳选择。
1.3 Saga在微服务中的价值
微服务架构下，每个服务拥有独立的数据库，传统数据库事务无法跨服务生效。Saga模式为微服务提供了以下关键价值：
- 解耦事务逻辑：每个微服务只需实现自己的本地事务和补偿逻辑，不依赖全局协调器锁定资源。
- 高可用与弹性：Saga引擎支持异步编排，单个服务故障不会阻塞整个链路，补偿机制可自动回滚。
- 适配事件驱动：Saga天然与消息队列、事件总线结合，适合异步、非阻塞的微服务通信模型。
- 状态可追溯：每个Saga实例的状态（开始、执行中、成功、补偿中、失败）可持久化到数据库，便于审计和故障恢复。
1.4 Saga执行流程示意图
下图展示了一个典型的订单创建Saga流程，包含正向事务和补偿回滚两条路径：
1.5 Saga的两种编排模式
Saga的实现分为编排（Choreography）和协调（Orchestration）两种模式，其架构差异如下：
| 对比维度 | 编排模式（Choreography） | 协调模式（Orchestration） |
|---|---|---|
| 控制中心 | 无中心，服务间通过事件通信 | 有中心协调器（Saga Orchestrator） |
| 通信方式 | 消息队列 / 事件总线 | 协调器调用各服务API |
| 复杂度 | 服务间耦合低，但调试困难 | 协调器集中管理，易于监控 |
| 状态管理 | 分散在各服务的事件日志中 | 集中存储在协调器状态机中 |
| 典型框架 | Eventuate Tram、Axon | Seata Saga、Camel Saga |
注意：编排模式适合服务数量少、事件流简单的场景；协调模式更适合复杂业务流程（如本课程后续的鉴权拦截+状态持久化场景），因为协调器可以集中管理Saga状态、补偿策略和重试逻辑。
1.6 协调模式架构示意图
下图展示了协调模式（Orchestration）下Saga引擎与各微服务的交互关系：