订单系统分布式事务：TCC与Saga模式如何确保库存与订单一致性

在微服务架构盛行的今天，业务逻辑被拆分到多个独立的服务中，这极大地提升了系统的可伸缩性和灵活性。然而，随之而来的挑战便是如何确保跨服务操作的数据一致性，特别是对于像订单创建和库存扣减这样需要“全有或全无”原子性的核心业务场景。

想象一下，当用户在电商平台成功下单后，系统需要同时完成两件事：

1. 扣减商品库存： 从库存服务中将对应商品的数量减少。
2. 生成订单记录： 在订单服务中创建新的订单信息。

如果这两步操作不能同时成功或同时失败，就会导致严重的数据不一致问题：

• 库存已扣减但订单未创建： 用户未下单成功，但商品却被错误地减少了库存，造成实际库存与显示不符，影响后续销售。
• 订单已创建但库存未扣减： 用户下单成功，但实际库存未减少，可能导致超卖，严重影响商家信誉和经营。

传统的数据库事务（ACID特性）在单个服务内部可以很好地解决这个问题，但当操作涉及多个服务时，传统事务便无能为力。此时，我们需要引入分布式事务解决方案，其中TCC（Try-Confirm-Cancel）模式和Saga模式是两种常用的范式。

分布式事务的核心挑战

在深入探讨TCC和Saga之前，我们先明确分布式事务的核心难点：

1. 原子性（Atomicity）： 确保所有参与的服务要么全部成功，要么全部失败回滚。
2. 隔离性（Isolation）： 避免并发事务之间的相互影响。
3. 持久性（Durability）： 事务提交后，数据更改是永久的。
4. 最终一致性（Eventual Consistency）： 分布式系统中常采用的一种妥协，即系统在一段时间后达到一致状态。

订单与库存场景对原子性要求较高，倾向于强一致性或接近强一致性。

方案一：TCC模式（Try-Confirm-Cancel）

TCC模式是一种基于业务层面的分布式事务解决方案，它将一个完整的业务操作拆分为三个阶段：

1. Try（尝试）：

   • 业务系统尝试执行操作，但不真正提交。
   • 对资源进行预留和锁定。例如，库存服务预扣减库存（冻结），订单服务创建待确认订单。
   • 这一阶段应是幂等的。

2. Confirm（确认）：

   • 当所有参与者的Try阶段都成功时，协调者会通知所有参与者执行Confirm操作。
   • Confirm操作是真正的提交，执行Try阶段预留的资源操作。
   • 这一阶段也应是幂等的，且理论上不会失败。

3. Cancel（取消）：

   • 如果在Try阶段有任何一个参与者失败，或在Confirm阶段发生异常，协调者会通知所有参与者执行Cancel操作。
   • Cancel操作是撤销Try阶段预留的资源，将系统恢复到事务发起前的状态。
   • 这一阶段也应是幂等的。

TCC模式在订单库存场景中的应用：

• Try阶段：
  • 订单服务：创建一条状态为“待确认”的订单记录，包含商品ID和数量。
  • 库存服务：根据订单请求预扣减（冻结）对应商品的库存数量。如果库存不足，Try失败。
• Confirm阶段（所有Try成功后）：
  • 订单服务：将“待确认”订单状态更新为“已完成”。
  • 库存服务：将预扣减的库存正式扣除。
• Cancel阶段（任一Try失败或Confirm异常时）：
  • 订单服务：删除“待确认”的订单记录。
  • 库存服务：解除库存冻结，恢复预扣减的库存。

TCC模式的优缺点：

• 优点： 强一致性保障，在业务层面实现了原子性，对业务侵入性相对较小（相对于传统两阶段提交）。
• 缺点： 业务代码改造量大，每个业务操作都需要实现Try、Confirm、Cancel三个接口；增加了业务服务的耦合性；事务协调者的实现相对复杂，需要考虑网络异常、宕机等情况下的重试和幂等性。

方案二：Saga模式

Saga模式是一系列本地事务的组合，每个本地事务更新自己的数据库，并发布事件触发下一个本地事务。如果在某个本地事务失败，Saga会执行一系列补偿事务来撤销之前成功的操作。Saga模式强调“最终一致性”，而不是强一致性。

Saga模式有两种实现方式：

1. 编排（Orchestration）：
   • 有一个集中的协调器（Orchestrator）来管理和调度Saga中的所有事务。
   • 协调器发送命令给每个服务，并订阅服务的回应事件。
   • 协调器负责根据事务结果决定下一步操作（继续、回滚）。
2. 协同（Choreography）：
   • 每个服务监听事件并执行自己的本地事务，然后发布新的事件来触发下一个服务。
   • 没有中心协调器，事务流程通过事件链自然流转。

Saga模式在订单库存场景中的应用（以编排为例）：

1. 订单服务 接收到下单请求，创建一条状态为“待付款”的订单记录。
2. Saga协调器 接收到订单创建事件。
3. 协调器 调用库存服务的deductInventory接口进行库存扣减。
4. 库存服务 成功扣减库存后，发布InventoryDeductedEvent。
5. 协调器 接收InventoryDeductedEvent，调用订单服务的updateOrderStatusToPaid接口更新订单状态为“已付款”。
6. 订单服务 更新成功，发布OrderPaidEvent，Saga完成。

如果库存扣减失败：

1. 库存服务 扣减失败，发布InventoryDeductionFailedEvent。
2. 协调器 接收InventoryDeductionFailedEvent，调用订单服务的cancelOrder接口（补偿事务）取消订单。
3. 订单服务 取消订单，发布OrderCancelledEvent，Saga回滚完成。

Saga模式的优缺点：

• 优点： 服务间解耦，更符合微服务的理念；适用于长事务和跨多个服务的复杂业务流程；相对于TCC，业务代码改造量更小（只需实现本地事务和补偿事务）。
• 缺点： 最终一致性，事务中间状态可见；补偿逻辑复杂，需要仔细设计；协同式Saga的流程追踪和故障排查困难。

TCC与Saga的对比与选择

如何为订单与库存场景选择？

对于订单创建与库存扣减这种核心且对原子性要求较高的场景，两种模式都可以考虑：

• TCC模式： 如果你追求接近实时的强一致性，并且订单创建与库存扣减的业务逻辑相对集中，涉及的服务数量不多（通常是订单服务和库存服务），那么TCC是一个可靠的选择。它的优点在于能够直接提供“全有或全无”的保障，避免中间状态的数据对外暴露。但你需要投入精力设计和实现Try、Confirm、Cancel接口，并确保协调器的健壮性。
• Saga模式： 如果你更倾向于微服务间的低耦合，并且系统允许短暂的最终一致性（即用户下单后，库存可能不会立即减少，但会在短时间内达到一致），或者你的订单流程非常复杂，除了库存还涉及优惠券、积分、物流等多个服务，那么Saga模式更具优势。通过事件驱动，各个服务可以独立演进，但你需要设计清晰的补偿逻辑和事件流，并处理好中间状态的展示。

在实际生产环境中，对于订单支付与库存的核心链路，很多系统会优先考虑TCC模式，因为它在保障一致性上更直接。但如果业务流程更长、更复杂，或者涉及到外部系统，Saga模式的灵活性和解耦性会使其成为更好的选择。

最佳实践建议：

1. 幂等性设计： 无论是TCC的Confirm/Cancel操作，还是Saga的补偿事务，都必须具备幂等性，以应对网络抖动和重试。
2. 事务状态追踪： 构建一个事务日志或追踪系统，能够清晰地查看分布式事务的当前状态，便于故障排查和恢复。
3. 异常处理与监控： 建立完善的异常处理机制，对分布式事务的失败和超时进行监控告警，及时介入处理。
4. 补偿机制的完备性： 仔细设计补偿逻辑，确保所有可能失败的路径都有对应的补偿措施。
5. 业务场景驱动： 最终的选择应基于业务对一致性的容忍度、系统的复杂度以及团队的技术栈和经验。没有银弹，只有最适合的方案。

选择TCC还是Saga，归根结底是对强一致性与系统复杂性、耦合度之间权衡的艺术。理解这两种模式的原理和特点，结合具体的业务场景需求，才能做出明智的决策。