分布式系统中的 Saga 事务模式

题目描述
Saga 事务模式是一种用于管理分布式系统中长周期事务的架构方案。在微服务架构下，一个业务操作可能涉及多个服务，每个服务都有其独立的数据存储。传统的ACID事务难以跨服务维护强一致性，Saga 通过将全局事务拆分为一系列本地事务，并通过补偿机制保证最终一致性，来解决分布式事务问题。面试中常考察Saga的设计思想、实现方式及异常处理逻辑。

知识讲解

1. 问题背景

   • 分布式事务挑战：在微服务中，例如"下单"操作需调用订单、库存、支付等服务，若用单一数据库事务（如2PC）会引入性能瓶颈和可用性问题。
   • Saga 目标：避免长时锁资源，通过异步、补偿策略实现最终一致性。

2. Saga 核心思想

   • 事务拆分：将全局事务 T 拆分为 n 个本地事务 T₁, T₂, ..., Tₙ，每个 Tᵢ 独立提交。
   • 补偿机制：为每个 Tᵢ 设计对应的补偿事务 Cᵢ，用于撤销 Tᵢ 的效果（如库存服务扣减后，补偿动作为加回库存）。
   • 执行方式：
     • 正向流程：按顺序执行 T₁ → T₂ → ... → Tₙ。
     • 逆向流程：若 Tᵢ 执行失败，则按逆序执行 Cᵢ₋₁ → ... → C₁。

3. Saga 的实现模式

   • 协同式（Choreography）：

     • 设计：每个服务监听上游事件并执行本地事务，发布后续事件或补偿事件。无中心节点，服务间通过消息队列通信。
     • 示例：订单服务创建订单后发布"ORDER_CREATED"事件，库存服务监听事件并扣库存，若成功则发布"INVENTORY_DECREASED"事件；若扣库存失败，发布"INVENTORY_FAILED"事件触发补偿。
     • 优点：去中心化，服务耦合低。
     • 缺点：流程复杂时事件链难追踪，易形成"蜘蛛网"依赖。

   • 编排式（Orchestration）：

     • 设计：引入一个Saga编排器（Orchestrator），集中管理事务流程。编排器向服务发送命令，接收结果并决定下一步操作。
     • 示例：编排器依次调用订单服务（创建订单）→ 库存服务（扣库存）→ 支付服务（扣款）。若支付失败，编排器主动调用补偿命令逆序回滚。
     • 优点：流程可视化，易维护和测试。
     • 缺点：编排器可能成为单点瓶颈。

4. 补偿事务的设计要点

   • 幂等性：补偿操作可能因重试而多次执行，需确保多次执行效果与一次执行相同（例如通过事务ID去重）。
   • 可交换性：补偿顺序不需严格逆序时，可并行执行以提高回滚效率（如订单取消与库存加回可同时进行）。
   • 语义正确性：补偿需考虑业务约束（如已发货的订单不能直接取消，需转为退款流程）。

5. 异常处理与容错

   • 超时与重试：服务调用需设置超时，失败后按策略重试（如指数退避）。
   • 悬挂事务：正向事务超时后可能实际成功，但编排器误判失败而触发补偿，需通过对账机制修复数据。
   • 隔离性问题：其他用户可能读到Saga执行中的中间状态（如看到订单但库存未扣），可通过"版本号"或"预留资源"降低影响。

总结
Saga 通过"分段提交+补偿"平衡了可用性与一致性，适用于跨服务的长流程业务（如电商交易、旅行订票）。设计时需根据业务复杂度选择协同式或编排式，并重点保障补偿逻辑的可靠性。