本文目录导读：
SAGA（Saga）模式是微服务架构中用于管理分布式事务的一种重要模式，它的核心思想是：将一个全局事务拆分为多个本地子事务，每个子事务都有对应的补偿操作（用于回滚）。
SAGA 模式适用于长事务和高并发场景,通过最终一致性来替代强一致性。
以下通过 3 个经典案例来详细说明 SAGA 模式的应用：
在线旅游预订系统（跨服务聚合）
这是最经典的 SAGA 应用场景,涉及多个不同领域的微服务。
业务背景
用户在一个旅游平台（如携程、飞猪）同时预订 机票 + 酒店 + 租车 服务，这三项服务由不同的微服务团队负责，并且是跨数据库的（因为负载极高，不可能共用一个数据库）。
涉及服务
- 机票服务：扣减机票库存,生成订单。
- 酒店服务：扣减房间库存,生成订单。
- 租车服务：扣减车辆库存,生成订单。
- 支付服务：进行资金扣款。
业务流程与 Saga 编排
采用 基于编排（Choreography） 的方式，订单服务作为总协调者（Orchestrator）。
- 正向操作：订单服务发起命令，依次调用 [机票服务] -> [酒店服务] -> [租车服务] -> [支付服务]。
- 异常触发：假设酒店服务预订成功，但租车服务因车辆库存不足而失败。
补偿执行过程（回滚）
Saga 引擎介入,执行前两步的补偿操作：
- 补偿支付：如果已扣款，调用支付服务的“退款”接口（此时还未付款，则可跳过）。
- 补偿酒店：调用酒店服务的“取消房间订单并释放库存”接口。
- 补偿机票：调用机票服务的“取消机票订单并释放座位”接口。
结果
用户收到“预订失败”的提示，系统中的机票和酒店订单被自动取消，库存恢复，但平均响应时间比传统的分布式锁（XA协议）要快很多,用户体验更好。
电商“下单支付”流程（用户余额与库存分布式）
业务背景
一个电商平台，用户账户余额（资金服务）与商品库存（库存服务）存储在不同的数据库，用户点击“下单支付”后,事务需要同时扣减余额和库存。
涉及服务
- 订单服务：创建待支付订单。
- 库存服务：扣减商品库存。
- 资金服务：扣减用户账户余额。
业务流程（基于事件驱动）
- 正向链路：
- 步骤1：订单服务 -> 创建订单（状态：待支付）。
- 步骤2：资金服务 -> 扣款成功。
- 步骤3：库存服务 -> 扣减库存成功。
- 异常触发：
假设步骤3（扣库存）失败，或者步骤2（扣款）成功但步骤3（扣库存）超时失败。
补偿执行过程
系统发现下游调用失败,需要进行反向操作：
- 补偿库存：如果库存部分扣减了，调用库存服务恢复库存（如果没扣减，则跳过）。
- 补偿资金：调用资金服务执行 “资金加回” 操作,将用户的余额退回。
关键点
- 幂等性：如果步骤2（扣款）返回超时，但实际已经扣款成功，补偿操作必须保证不重复退款,或者正向操作重试时不重复扣款。
- 状态流转：订单状态最终变为“已取消”,用户资金余额回滚。
银行间转账 - A银行账户向B银行账户汇款
业务背景
两家银行（银行A 和 银行B）的系统架构不同（甚至可能是Oracle与MySQL），且不共享数据库，跨行转账必须保证“要么都成功，要么都失败”。
传统痛点
如果使用两阶段提交（2PC），在转账期间，两个数据库的锁会被长时间持有，导致系统性能下降,SAGA则允许中途释放锁。
涉及服务（横向跨系统）
- 银行A 账户服务（负责扣款）。
- 银行B 账户服务（负责收款）。
业务流程（基于事件链）
- 正向操作：
- 步骤1：银行A 服务扣减 $100（本地事务提交，锁释放）。
- 步骤2：发送“转账成功”事件到MQ（消息队列）。
- 步骤3：银行B 服务消费事件，增加 $100（本地事务提交）。
- 异常触发：
如果银行B 服务发生故障，无法增加资金（例如账号错误、系统宕机）。
补偿执行过程
由于银行A已经扣款,现在需要触发补偿：
- 补偿目标：银行A 服务执行“逆操作 - 增加 $100”。
- 特殊处理：
- 银行B 服务需要标记该笔交易为“挂账”或“失败”，并向银行A发送否定确认（NACK）。
- 银行A 收到后，执行加款,并记录日志供人工对账。
案例启示
在跨企业（跨业务边界）的场景下，SAGA模式的补偿机制往往不是简单的“调用反接口”，而是通过异步对账和人工介入来最终达成一致性。
SAGA 案例中的三个核心准则
- 反向操作必须存在：任何业务操作（扣钱”、“减库存”、“订票”）都必须有对应的反向操作（“加钱”、“加库存”、“退票”）。
- 幂等控制：由于网络可能重发请求，无论是正向操作还是补偿操作，必须设计幂等键,防止重复扣款或重复退款。
- 状态机管理：整个事务通常通过一个状态机来管理（如：待处理 -> 已处理 -> 已补偿），确保在任意时刻崩溃,重启后都能根据当前状态继续补偿。
SAGA 的优缺点总结：
- 优点：事务阶段提交，不需要长期持有数据库资源锁，吞吐量高,适合长事务。
- 缺点：隔离性弱（无法避免脏读，需业务容忍中间状态），并且编码复杂度高,需要针对每个操作写补偿逻辑。
