Saga 事务基础：定义与两种实现模式对比
2.1 Saga 事务的定义
Saga 是一种用于管理分布式系统中长事务的架构模式。它将一个全局事务拆分为一系列本地事务（称为“步骤”），每个步骤都有对应的补偿操作。当某个步骤失败时，Saga 会依次执行之前已成功步骤的补偿操作，以撤销已产生的副作用，从而保证最终一致性。
核心思想： 放弃传统 ACID 的强隔离性，采用“补偿”机制实现最终一致性。每个本地事务提交后立即释放资源，避免长时间持有数据库锁。
Saga 事务的关键特征：
- 本地事务序列： 每个参与者独立提交自己的本地事务。
- 补偿操作： 每个正向步骤都预先定义好一个反向操作，用于撤销该步骤的影响。
- 最终一致性： 不保证全局强一致性，但保证在无故障或补偿完成后系统达到一致状态。
- 无锁设计： 不持有跨服务的分布式锁，适合高并发场景。
2.2 两种实现模式对比
Saga 有两种主流实现模式：Choreography（编排） 和 Orchestration（编舞）。它们在协调方式、耦合度、可追踪性等方面存在显著差异。
| 对比维度 | Choreography（编排） | Orchestration（编舞） |
|---|---|---|
| 协调方式 | 服务间通过事件异步通信，无中心协调器 | 由中心协调器（Orchestrator）统一调度 |
| 耦合度 | 服务之间通过事件耦合，新增服务需修改事件订阅 | 服务只与协调器交互，服务间解耦 |
| 可追踪性 | 分散在多个服务的事件日志中，追踪困难 | 协调器集中记录状态，易于追踪和调试 |
| 复杂度 | 简单场景下实现轻量，复杂场景下事件流难以管理 | 协调器逻辑集中，适合复杂业务流程 |
| 补偿触发 | 服务监听失败事件，自行触发补偿 | 协调器检测失败，统一调用补偿步骤 |
| 典型应用 | 微服务数量少、流程简单的场景 | 流程复杂、需要严格状态管理的场景 |
2.3 Choreography 模式详解
在 Choreography 模式中，每个服务在执行完本地事务后，向消息队列或事件总线发布事件。其他服务监听这些事件，并根据事件内容决定下一步操作。没有中心化的协调者。
适用场景： 服务数量少（通常 2-4 个）、业务流程简单、团队希望减少中心依赖的微服务架构。
典型流程示例（订单创建 Saga）：
- 订单服务创建订单（状态：待支付），发布“订单已创建”事件。
- 支付服务监听该事件，执行扣款，发布“支付成功”事件。
- 库存服务监听“支付成功”事件，扣减库存，发布“库存已扣减”事件。
- 若支付失败，支付服务发布“支付失败”事件，订单服务监听后取消订单（补偿）。
2.4 Orchestration 模式详解
Orchestration 模式引入一个中心化的协调器（Orchestrator），负责管理 Saga 的执行流程。协调器向各个服务发送命令，服务执行后返回结果，协调器根据结果决定下一步是继续正向流程还是触发补偿。
注意： 协调器本身可能成为单点故障和性能瓶颈。生产环境中通常需要对协调器做高可用部署，并确保其状态持久化。
典型流程示例（订单创建 Saga）：
- 协调器向订单服务发送“创建订单”命令。
- 订单服务执行成功，返回订单 ID。
- 协调器向支付服务发送“扣款”命令（携带订单 ID）。
- 支付服务执行成功，返回支付凭证。
- 协调器向库存服务发送“扣减库存”命令。
- 若任意步骤失败，协调器按逆序调用补偿操作（取消订单、退款、恢复库存）。
2.5 模式选择建议
选型决策：
- 若业务流程简单（2-3 个服务）、团队希望快速迭代，优先考虑 Choreography。
- 若业务流程复杂（超过 4 个服务）、需要严格的状态管理和审计追踪，选择 Orchestration。
- 若对延迟敏感，Choreography 的事件异步通信通常比 Orchestration 的同步调用延迟更低。
- 若需要与现有系统集成，Orchestration 的协调器可以更容易地适配异构服务。
两种模式并非互斥，在大型系统中可以混合使用：核心流程使用 Orchestration 保证可靠性，边缘流程使用 Choreography 降低耦合。