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

描述
在分布式系统中，一个业务操作可能涉及多个服务的数据修改，而传统的ACID事务难以跨服务保证原子性。Saga模式是一种长事务解决方案，通过将分布式事务拆分为多个本地事务，并利用补偿机制保证最终一致性。

解题过程

1. 问题背景

   • 分布式事务场景：例如电商下单需扣库存、创建订单、扣款，每个步骤属于不同服务。
   • 挑战：若使用两阶段提交（2PC），同步阻塞和容错性差；若直接串行执行本地事务，部分失败时数据不一致。

2. Saga的核心思想

   • 将长事务拆分为一系列本地事务（称为“子事务”）。
   • 每个子事务执行后发布事件触发下一个子事务。
   • 若某个子事务失败，则按相反顺序执行补偿操作（Compensating Transaction）回滚已完成的步骤。

3. Saga的实现方式

   • 协同式（Choreography）：

     • 每个服务监听前驱事件并执行本地事务，完成后发布新事件。
     • 示例流程：
       1. 订单服务创建订单（状态为“待处理”），发布“订单创建事件”。
       2. 库存服务监听事件并扣库存，发布“库存已扣事件”。
       3. 支付服务监听事件并扣款，发布“支付成功事件”。
       4. 订单服务监听支付成功事件，更新订单状态为“完成”。
     • 失败处理：若支付失败，支付服务发布“支付失败事件”，库存服务监听后执行补偿（释放库存），订单服务更新订单为“失败”。
     • 优点：去中心化，无需协调器。
     • 缺点：事件链路复杂，难调试。

   • 编排式（Orchestration）：

     • 引入Saga协调器（Orchestrator）统一管理流程。
     • 协调器按顺序调用子事务，失败时触发补偿。
     • 示例流程：
       1. 协调器调用订单服务创建订单。
       2. 成功后调用库存服务扣库存。
       3. 成功后调用支付服务扣款。
       4. 全部成功则结束。
     • 失败处理：若支付失败，协调器依次调用补偿操作（支付服务退款→库存服务释放库存→订单服务标记失败）。
     • 优点：流程集中化，易监控。
     • 缺点：协调器可能成为单点瓶颈。

4. 补偿操作的设计原则

   • 幂等性：补偿可能重试，需确保多次执行效果相同。
   • 可交换性：多个补偿操作执行顺序不应影响结果（因回滚顺序可能与正向顺序相反）。
   • 语义正确性：补偿需将数据恢复到事务开始前的状态（例如退款金额需等于原扣款金额）。

5. Saga的权衡

   • 优点：避免长期锁资源，适合长流程业务。
   • 缺点：不保证隔离性（其他事务可能看到中间状态），需业务层处理脏读（如通过版本号或状态标记）。

总结
Saga通过“正向操作+补偿回滚”实现分布式事务的最终一致性，需根据业务复杂度选择协同式或编排式，并谨慎设计补偿逻辑以应对部分失败场景。