Saga事务在分布式事务鉴权拦截中的异步补偿机制 - 第2节

2.1 Saga模式的定义

Saga是一种用于管理分布式系统中长事务的异步补偿模式。它将一个全局事务拆分为多个本地事务（子事务），每个本地事务都有对应的补偿事务。当某个本地事务失败时，Saga会按照逆序依次执行之前已成功子事务的补偿操作，从而回滚整个业务流程，保证最终一致性。

Saga事务的每个子事务Ti都对应一个补偿事务Ci。正常流程下，所有Ti依次执行成功；异常流程下，从失败点开始反向执行Ci，直到所有已提交的子事务都被补偿。

2.2 Saga的两种协调方式

Saga事务根据协调方式的不同，分为编排模式（Choreography）和协调模式（Orchestration）两种。两者在架构、耦合度、控制权方面有显著差异。

2.2.1 编排模式（Choreography）

编排模式下，每个服务在完成本地事务后，通过事件总线发布消息，触发下一个服务的执行。没有中央协调器，服务之间通过事件驱动形成链式调用。

• 通信方式：异步事件（如Kafka、RabbitMQ）
• 控制权：分散在各服务中
• 耦合度：低，服务仅依赖事件契约
• 补偿触发：每个服务监听失败事件并执行自己的补偿逻辑

2.2.2 协调模式（Orchestration）

协调模式下，引入一个Saga协调器（Orchestrator）作为中央控制器，负责编排所有子事务的执行顺序，并在失败时触发补偿。协调器通常以状态机方式管理事务生命周期。

• 通信方式：同步RPC或异步消息
• 控制权：集中在协调器
• 耦合度：服务与协调器耦合，服务间解耦
• 补偿触发：协调器统一决策并调用补偿接口

2.3 两种协调方式的对比

2.4 Saga的适用场景

Saga事务并非万能，它适用于特定类型的分布式事务场景。以下场景适合采用Saga模式：

• 跨服务业务流程：订单、支付、库存、物流等跨多个微服务的业务链路。
• 长事务场景：事务执行时间较长（秒级到分钟级），不适合数据库锁。
• 最终一致性可接受：业务允许短暂的数据不一致，但最终必须一致。
• 高并发、低延迟要求：相比2PC，Saga避免全局锁，性能更高。
• 异构数据源：涉及MySQL、MongoDB、Redis等多种存储，无法使用统一XA协议。

2.4.1 典型应用案例

以电商下单流程为例，Saga事务的典型应用如下：

1. 订单服务：创建订单（状态：待支付）
2. 库存服务：扣减库存（补偿：加回库存）
3. 支付服务：扣款（补偿：退款）
4. 物流服务：创建配送单（补偿：取消配送）

若第3步支付失败，则依次执行：退款（C3）→ 加库存（C2）→ 取消订单（C1），最终回到初始状态。