告别超卖：微信拼团活动的库存预扣、回滚与并发防护实践手记

告别超卖：微信拼团活动的库存预扣、回滚与并发防护实践手记

去年朋友做了一场拼团活动，3 人团、限量 100 件，开团不到两小时，后台订单显示卖了 300 多单，仓库根本发不出货。问题出在库存扣减逻辑上：库存只在下单时查了一次，没有锁定，高并发下多个订单同时通过了库存校验。这篇把拼团场景下库存管理的完整做法记录下来。

一、库存模型的三种状态

拼团库存不能只存"总库存"一个数字，至少拆成三部分：

下单时扣可售库存并增加锁定库存，支付成功后锁定转已售，超时未支付则回滚。

二、下单预扣：先锁再卖

核心原则：库存扣减要放在下单事务里，和订单创建是同一个原子操作。SQL 写法：

UPDATE sku SET available = available - 1
WHERE sku_id = ? AND available >= 1

受影响行数为 0 说明库存不足，直接提示"已售罄"。这样并发下也不会超卖，因为 UPDATE 是行级原子操作。

三、超时回滚：库存释放

拼团订单有支付时限（如开团后 24 小时内成团，成团后 24 小时内支付），超时未支付要自动释放锁定库存：

• 定时任务扫描超时未支付订单
• 释放锁定库存、关闭订单
• 注意：回滚也要加锁，避免和新的下单操作竞争

四、并发防护的三个层次

1. 数据库层：乐观锁（version 字段）或条件 UPDATE，这是兜底
2. 缓存层：Redis 的 DECR 原子操作做库存预减，Redis 减成功才允许下单，再异步同步到数据库
3. 接口层：用户维度限流，同一用户短时间不能重复开团/参团

五、常见坑

1. 用"先查库存再下单"的写法，并发下必超卖
2. 锁定库存没有释放机制，超时订单占用库存导致"有库存但卖不动"
3. 团单状态和库存状态没有联动，成团失败后库存没有回滚
4. 只做了接口层校验，没有数据库兜底，被刷接口直接打穿

这次的活动后台用的是乔拓云的营销活动应用，它把库存预扣、超时回滚做成了默认开关，我只需要设置可售库存数和支付时限，不用自己写定时回滚任务，重点校验拼团规则和并发表现就行。

复盘要点

1. 库存扣减必须和下单同事务，条件 UPDATE 是底线
2. 锁定库存必须有超时释放机制
3. 数据库兜底 + 缓存加速 + 接口限流，三层防护缺一不可

以上是个人实践记录，各平台具体功能以官方实时信息为准。

开放问题：你们做秒杀或拼团时，库存一致性用的是 Redis 预减还是纯数据库事务？