微服务中的分布式事务处理

题目描述：在微服务架构中，一个业务操作通常需要跨多个服务完成，这些服务拥有独立的数据库。如何保证所有服务的数据操作要么全部成功，要么全部回滚，即实现分布式事务的一致性？

知识讲解：

1. 问题根源与挑战

   • 本地事务的局限性：在单体应用中，我们使用数据库的ACID事务（原子性、一致性、隔离性、持久性）可以轻松保证数据一致性。但在微服务中，每个服务的数据是独立的，无法直接使用一个数据库的事务来涵盖多个服务的数据操作。
   • 核心挑战：分布式系统存在网络、服务、数据库等各种不可靠因素，可能造成部分服务调用成功，而部分服务调用失败，导致数据不一致。

2. 解决方案演进：从强一致性到最终一致性
   分布式事务的解决方案主要分为两大类：追求强一致性的和接受最终一致性的。

   • 方案一：两阶段提交（2PC - Two-Phase Commit）

     • 目标：实现强一致性，模仿数据库事务的提交过程。
     • 角色：
       • 协调者（Coordinator/Transaction Manager）：一个独立的组件，负责统一调度所有参与者。
       • 参与者（Participant/Resource Manager）：各个微服务，负责执行本地数据库操作。
     • 过程：
       • 第一阶段：准备阶段（Prepare Phase）
         1. 协调者向所有相关的参与者发送“准备请求”，并附上事务内容。
         2. 每个参与者执行本地事务操作（例如，更新、插入），但不进行最终提交。所有操作被锁定（Lock）。
         3. 参与者向协调者返回响应：“准备成功（Yes）”或“准备失败（No）”。
       • 第二阶段：提交/回滚阶段（Commit/Rollback Phase）
         1. 情况A：如果协调者收到的所有响应都是“Yes”：
            • 协调者向所有参与者发送“提交请求（Commit）”。
            • 参与者收到Commit后，正式提交本地事务，释放锁，并返回“提交完成”的ACK。
            • 协调者收到所有ACK后，整个事务完成。
         2. 情况B：如果协调者收到任何一个“No”响应，或等待响应超时：
            • 协调者向所有参与者发送“回滚请求（Rollback）”。
            • 参与者收到Rollback后，回滚在准备阶段所做的操作，释放锁，并返回“回滚完成”的ACK。
     • 优点：保证了强一致性，所有节点的数据状态在提交后完全一致。
     • 缺点：
       • 同步阻塞：在准备阶段，所有参与者的资源都被锁定，其他事务无法访问，直到第二阶段结束。性能差。
       • 单点问题：协调者至关重要，一旦宕机，参与者会一直锁定资源，导致系统阻塞。
       • 数据不一致风险：在第二阶段，如果只有部分参与者收到了Commit指令，就会导致数据不一致。

   • 方案二：基于最终一致性的模式（更适用于微服务）
     现代微服务架构更倾向于使用最终一致性方案，通过牺牲强一致性来换取更高的可用性和性能。最主流的模式是Saga模式。

     • Saga模式核心思想：将一个分布式事务拆分为一系列本地事务，每个本地事务都有一个对应的补偿事务（Compensating Transaction）。补偿事务用于撤销该本地事务造成的影响。
     • 执行方式：
       • 协同式Saga（Orchestration）：
         1. 引入一个Saga协调器（Orchestrator），它负责按顺序调用各个Saga参与者的本地事务。
         2. 如果某个本地事务成功，协调器则调用下一个。
         3. 关键：如果某个本地事务失败，协调器会反向依次调用之前所有已成功事务的补偿操作。
         4. 举例（创建订单Saga）：
            • 事务T1：订单服务 -> 创建“待确认”状态订单。
            • 事务T2：库存服务 -> 扣减库存。
            • 事务T3：支付服务 -> 进行扣款。
            • 补偿操作：
              • C1：订单服务 -> 将订单状态更新为“已取消”。
              • C2：库存服务 -> 恢复已扣减的库存。
              • C3：支付服务 -> 执行退款。
            • 流程：执行 T1 -> 成功 -> 执行 T2 -> 成功 -> 执行 T3 -> 失败 -> 执行 C2（补偿T2）-> 执行 C1（补偿T1）。最终所有服务数据回到事务开始前的状态。
       • 事件驱动式Saga（Choreography）：
         1. 没有中央协调器，每个服务独立监听并生产领域事件（Domain Event）。
         2. 服务执行完本地事务后，发布一个事件。
         3. 下一个服务监听该事件，并执行自己的本地事务，然后发布新的事件。
         4. 如果某个服务执行失败，它会发布一个失败事件，监听该事件的服务会触发自己的补偿操作。
         • 举例：订单服务创建订单后发布 OrderCreated 事件 -> 库存服务监听该事件并扣减库存，发布 InventoryUpdated 事件 -> 支付服务监听并扣款，若失败则发布 PaymentFailed 事件 -> 库存服务监听失败事件，执行库存恢复。
     • 优点：
       • 高可用性：没有全局锁，服务间解耦。
       • 高性能：避免了长时间的资源锁定。
     • 缺点：
       • 最终一致性：数据在某一时刻可能是不一致的（例如，订单是“待确认”状态，但库存已扣）。
       • 设计复杂：需要为每个正向操作设计对应的、可逆的补偿操作，且补偿操作必须保证能成功（等幂性）。

3. 总结与选择

   • 2PC：适用于对强一致性要求极高、且参与服务数量不多、性能要求不高的场景（如金融核心交易）。
   • Saga：是微服务架构中处理分布式事务的首选方案，它通过最终一致性在业务可接受的范围内，实现了系统的高可用和伸缩性。协同式Saga控制流更清晰，事件驱动式Saga服务间更解耦。

通过理解从2PC到Saga的演进，你可以看到分布式系统设计在一致性与可用性之间的权衡（CAP定理），这也是微服务设计的核心思想之一。