微服务中的Saga分布式事务模式：从理论到工程落地

微服务架构中的事务困境

在单体应用中，ACID事务由数据库保证简单可靠。但在微服务架构下，一个业务操作可能跨3-5个服务的多个数据库。传统的两阶段提交（2PC）在分布式场景下因性能差、可用性低而不再适用。Garcia-Molina和Skeen于1981年提出的Saga模式——最初为了解决长事务（Long-Lived Transaction）而设计——成为微服务分布式事务的事实标准。

1. Saga的核心思想

Saga将一个分布式事务分解为一系列本地事务T1, T2, ..., Tn。每个本地事务Ti都有对应的补偿事务Ci。若某步失败，则按反向顺序执行补偿。Saga的设计哲学：不保证隔离性——中间状态对其他事务可见（缺乏Isolation），通过业务层面的补偿操作达到最终一致性。

2. 两种实现方式

2.1 编排模式（Choreography）

各服务通过事件驱动的方式自行决定下一步动作：

• 订单服务创建订单，发布OrderCreated事件
• 库存服务接收事件并预扣库存，发布InventoryReserved事件
• 支付服务接收事件并扣款，发布PaymentProcessed事件
• 物流服务接收事件并安排发货

优点：去中心化，服务自治；新业务流通过组合现有事件实现；简单场景下易于实现。

缺点：流程散布在多个服务中，难以追踪整体业务流；循环依赖风险；测试和调试复杂度指数级增长。

2.2 协调模式（Orchestration）

由一个专门的协调器（Saga Orchestrator）集中控制事务流程：

• 协调器调用订单服务创建订单
• 协调器调用库存服务预扣库存
• 协调器调用支付服务扣款
• 协调器调用物流服务安排发货
• 任何步骤失败时，协调器按反向顺序调用各服务的补偿接口

优点：流程集中管理，易追踪和监控；避免了服务间的循环依赖；协调器可作为分布式事务状态的真相源。

缺点：协调器成为单点（需要高可用设计）；协调器与业务逻辑耦合度较高。

3. 补偿事务设计原则

补偿是Saga的核心难点。设计补偿事务需遵循以下原则：

3.1 幂等性

补偿操作可能被重试（网络超时、协调器崩溃重启），必须保证幂等。正确做法是使用CAS操作（如UPDATE ... WHERE status=NEW SET status=CANCELLED）确保重复执行安全。

3.2 可交换性

Saga不保证严格的回滚序列。补偿序列最好能保证任意顺序执行都正确。应该标记为CANCELLED而非物理删除，因为删除后数据永久丢失。

3.3 超时保证

补偿事务与正向事务一样可能失败，必须处理"补偿也失败"的情况：使用重试+指数退避应对临时故障；补偿多次失败后送人工处理；监控系统实时上报。

4. 语义锁与隔离性补偿

Saga最大的工程挑战是缺乏隔离性——其他事务可能读到中间状态。解决方案是语义锁（Semantic Lock）：在执行本地事务时，将相关资源标记为"待变更"（In-Progress），阻止其他Saga对其修改，完成后清除标记。

三大模式：Counter模式（语义锁提供语义层面的隔离）、Compensatable模式（尽力回滚，适用于大多数场景）、Pivot模式（关键点之后不可回滚但可以成功，适用于支付确认等不可逆步骤）。建议将Saga设计为Compensatable到Pivot的结构。

5. 持久化与恢复

Saga必须持久化状态，以应对协调器或服务崩溃。Saga状态表记录每个步骤的执行状态（saga_id, step, status, request, response）。协调器重启时扫描状态为PROCESSING/DOING的saga，确认最后执行的步骤，继续推进或开始补偿。

6. 与TCC的对比

建议：大部分微服务场景选择Saga；只有对中间状态强敏感的核心金融操作才考虑TCC。

总结

Saga是微服务架构中最具可操作性的分布式事务模式，其核心设计原则是：分解长事务为本地事务链；每步配备幂等的补偿操作；协调器集中管理状态机；接受最终一致性，通过语义锁缓解隔离性问题。在实践中，Saga与事件驱动和持久化的组合已在电商订单（Shopify）、机票预订、金融支付等场景得到大规模验证。掌握Saga不仅是学会一种模式，更是建立"在面对分布式复杂性时如何牺牲隔离性换取可用性"的工程直觉——这种直觉才是分布式系统设计的核心能力。