如何保障Microservices事务？本地部署场景下的技术问询

针对你提到的订单服务（sales）和库存服务（stock）的一致性问题，直接给你明确结论和着手方向：

疑问解答 #

1. 是否在订单提交前请求库存服务修改库存？ #

不建议直接在订单提交前同步扣减库存。单体应用的本地事务逻辑无法延伸到分布式场景——如果订单服务提交失败但库存已完成扣减，或是库存扣减成功但订单创建失败，都会直接导致数据不一致。

正确思路是先预留库存，而非直接扣减：

• 用户下单时，调用库存服务将对应数量的可用库存转为预留库存
• 订单完成支付后，通知库存服务将预留库存转为实际扣减
• 若订单超时取消、支付失败，则通知库存服务释放预留库存，返还至可用库存

2. 实时执行还是定时任务同步？ #

• 核心流程必须实时执行：用户下单时的库存预留操作必须是实时的，否则用户看到的库存状态会过期，极易引发超卖问题。
• 定时任务仅用于补偿和对账：比如扫描超时未支付的订单自动释放预留库存，或是每日对账修正异常数据，但绝对不能替代核心流程的实时交互。

着手解决的步骤 #

• 先明确业务规则：确定库存扣减的触发节点（下单/支付）、订单超时时间、超卖容忍度等，这是所有技术方案的基础。
• 实现幂等性机制：给每个库存操作请求生成唯一ID，避免网络重试导致的重复扣减/预留。
• 选择分布式一致性方案：
  • 用消息队列实现最终一致性：订单创建成功后发送事务消息到MQ，库存服务消费消息完成预留；若订单后续取消，再发送消息释放库存。
  • 采用Saga模式：拆分订单创建、库存预留为两个子事务，任一子事务失败则执行补偿操作（比如订单创建失败就回滚库存预留）。
• 设计库存表结构：区分可用库存、预留库存两个字段，通过字段转换实现锁定和释放逻辑。
• 加重试和降级策略：调用库存服务失败时，设置有限次数的重试；极端情况下可临时限制下单，避免服务雪崩。

内容的提问来源于stack exchange，提问作者Leandro De Mello Fagundes