微服务

Saga模式

在微服务架构中，Saga模式是实现分布式事务最终一致性的核心方案之一。它的核心思想是：将一个分布式事务拆分为多个相互关联的“本地事务”，每个本地事务由对应的微服务独立执行；同时为每个本地事务定义“补偿事务”（Compensating Transaction），当某一步本地事务执行失败时，通过执行前面已完成事务的补偿事务，将系统状态回滚到初始状态，最终保证全局事务的一致性。

Saga模式的核心构成

一个完整的Saga事务包含两部分：

  1. 本地事务（Local Transaction）：每个微服务内部的ACID事务（如“创建订单”“扣减库存”“支付金额”等），仅操作自身数据库。
  2. 补偿事务（Compensating Transaction）：针对每个本地事务的“逆操作”（如“取消订单”“恢复库存”“退款”等），用于在流程失败时回滚已完成的操作。

Saga模式的两种实现方式

根据分布式事务的协调方式，Saga模式可分为编排式（Choreography） 和编排式（Orchestration） 两种实现模式，适用于不同场景。

1. 编排式（Choreography，无中央协调者）

核心逻辑：没有专门的协调者，由各个微服务自主触发下一个本地事务，或在失败时自主触发补偿事务。每个服务仅需知道“自己执行完后该通知哪个服务”“收到失败通知时该执行什么补偿”。

实现步骤：

  • 每个微服务完成本地事务后，通过事件（如消息队列）主动通知下一个服务执行其本地事务；
  • 若某服务执行本地事务失败，通过事件通知前面已执行完的服务，触发它们的补偿事务。

示例：电商下单（简单场景）
假设一个电商下单流程需经过3个服务：

  • 订单服务（创建订单）→ 支付服务（扣减用户余额）→ 库存服务（扣减商品库存）。

正常流程：

  1. 订单服务执行本地事务“创建订单”（状态为“待支付”），完成后发送“订单创建成功”事件；
  2. 支付服务监听事件，执行本地事务“扣减用户余额”，完成后发送“支付成功”事件；
  3. 库存服务监听事件，执行本地事务“扣减库存”，完成后整个Saga事务结束（订单状态更新为“已下单”）。

失败场景（库存扣减失败）：

  1. 库存服务执行“扣减库存”失败，发送“库存扣减失败”事件；
  2. 支付服务监听事件，执行补偿事务“用户余额退款”，发送“退款成功”事件；
  3. 订单服务监听事件，执行补偿事务“取消订单”（状态改为“已取消”），整个Saga事务回滚完成。

优缺点：

  • 优点：无中央节点，服务间耦合低（仅通过事件交互），扩展性好；
  • 缺点：适合简单流程（步骤少），复杂流程中事件关系混乱（如10个服务参与时，事件依赖难以维护），且难以追踪全局事务状态。

2. 编排式（Orchestration，有中央协调者）

核心逻辑：引入一个专门的“ Saga协调者（Orchestrator）”，由协调者统一管理分布式事务的执行流程：决定下一步调用哪个服务的本地事务，以及失败时调用哪些服务的补偿事务。各微服务仅需响应协调者的指令，无需知道其他服务的存在。

实现步骤：

  • 协调者接收分布式事务请求（如“创建订单”），按预设流程依次调用各服务的本地事务接口；
  • 若某服务返回成功，协调者继续调用下一个服务；
  • 若某服务返回失败，协调者按“逆序”调用前面已成功服务的补偿事务接口，直到所有操作回滚。

示例：电商下单（复杂场景，含物流）
流程涉及4个服务：订单服务、支付服务、库存服务、物流服务，协调者统一调度。

正常流程：

  1. 协调者接收“下单”请求，调用订单服务的“创建订单”接口（本地事务），返回成功；
  2. 协调者调用支付服务的“扣减余额”接口（本地事务），返回成功；
  3. 协调者调用库存服务的“扣减库存”接口（本地事务），返回成功；
  4. 协调者调用物流服务的“创建物流单”接口（本地事务），返回成功；
  5. 协调者通知订单服务“更新状态为已下单”，事务完成。

失败场景（物流单创建失败）：

  1. 物流服务执行“创建物流单”失败，返回错误给协调者；
  2. 协调者按逆序调用补偿事务：
    • 调用库存服务的“恢复库存”接口（补偿）；
    • 调用支付服务的“退款”接口（补偿）；
    • 调用订单服务的“取消订单”接口（补偿）；
  3. 所有补偿完成，事务回滚。

优缺点：

  • 优点：适合复杂流程（步骤多），全局事务逻辑集中在协调者，易维护、易追踪；
  • 缺点：协调者可能成为性能瓶颈（需处理所有交互），且协调者与各服务存在一定耦合（需知道各服务的接口）。

Saga模式的关键注意事项

  1. 补偿事务的幂等性：补偿事务可能因网络重试被多次调用（如“退款”被调用两次），需保证重复执行结果一致（如“已退款则忽略”）。
  2. 事务顺序性：本地事务必须按预设顺序执行，补偿事务必须按逆序执行（如“创建订单→支付→扣库存”的补偿必须是“恢复库存→退款→取消订单”）。
  3. 最终一致性：Saga不保证“即时一致性”，而是通过补偿机制实现“最终一致”（可能存在短暂的中间状态，如“订单已创建但未支付”）。

总结

Saga模式通过“拆分分布式事务为本地事务+补偿事务”，解决了微服务中跨服务事务的一致性问题，尤其适合高并发、长流程场景（如电商下单、金融转账）。实际应用中，简单场景常用“编排式”，复杂场景常用“编排式”，核心是设计可靠的补偿逻辑和处理异常情况。