电商场景单个库存商品的Stripe多PaymentIntents问题求解

方案1：预占库存+超时自动释放 #

这是最通用的解决思路，核心是把库存拆成「可用库存」和「锁定库存」两个状态：

• 用户发起下单请求时，原子性地将可用库存转为锁定库存（比如数据库执行UPDATE products SET available_stock = available_stock -1, locked_stock = locked_stock +1 WHERE id = ? AND available_stock > 0，用行锁保证操作不会被并发打断），只有操作成功的用户才能创建PaymentIntent。
• 给锁定库存设置超时时间（比如15-30分钟，根据你的支付流程时长调整）：
  • 用户在超时前完成支付（收到PaymentIntentSucceeded事件），就把锁定库存直接转为已售库存（UPDATE products SET locked_stock = locked_stock -1, sold_stock = sold_stock +1），完成交易。
  • 超时后用户未完成支付，或者主动取消支付，自动释放锁定库存（UPDATE products SET available_stock = available_stock +1, locked_stock = locked_stock -1）。
• 实现方式：可以用数据库定时任务扫描过期的锁定记录，或者用Redis存锁定状态（利用Redis的过期键自动触发释放逻辑）。

方案2：支付前校验库存+支付成功后二次校验+兜底退款 #

如果不想维护库存锁定状态，可以简化流程，但要处理支付成功后的异常情况：

• 用户发起下单请求时，先检查可用库存是否>0，只有库存充足才允许创建PaymentIntent。
• 收到PaymentIntentSucceeded事件时，再次执行库存扣减的原子操作（UPDATE products SET available_stock = available_stock -1 WHERE id = ? AND available_stock > 0）：
  • 操作成功，说明用户抢到商品，走后续流程。
  • 操作失败（库存已经被其他用户扣减为0），立即触发退款，给用户发通知：「商品已售罄，支付已原路退回」。
• 这个方案优势是逻辑简单，不用管锁定状态；缺点是可能出现用户支付成功但拿不到商品的情况，得做好退款和用户沟通。

方案3：排他锁控制并发下单 #

针对高并发抢购场景，用排他锁减少无效的PaymentIntent创建：

• 用户发起下单请求时，先尝试获取该商品的排他锁（比如用Redis的SETNX命令，或者数据库的行级排他锁）。
• 只有拿到锁的用户才能进入库存校验、PaymentIntent创建流程；没拿到锁的用户直接返回「商品抢购火爆，请稍后再试」。
• 注意锁的超时时间要设置合理，避免异常情况导致锁一直占用。

通用注意事项 #

• 所有库存操作必须是原子性的，避免并发导致的数据不一致。
• 支付回调（PaymentIntentSucceeded）要保证可靠性，比如加重试机制，防止网络问题导致库存未扣减但用户已支付。
• 所有下单请求要做幂等性处理，用唯一请求ID标识，避免重复创建PaymentIntent或重复扣减库存。

内容的提问来源于stack exchange，提问作者AidasV