我直接说：中秋集中兑换崩盘，十有八九不是服务器太烂，是预扣库存这层没做扎实。库存没锁住，再多机器也扛不住。

中秋一到，兑换系统就成了重灾区。链接点不开、库存秒空又显示有货、用户兑成功了你查不到订单——这些破事儿，九成跟兑换系统预扣库存机制没做对。高并发预扣库存听着玄乎，其实就是一句话：用户点兑换那一瞬间，先把库存"占住"，订单成了再扣，订单废了再还。这层做不扎实，中秋那天就是事故现场。

中秋集中兑换为啥老崩？预扣库存是干啥用的

预扣库存就是用户点兑换那一瞬间，系统先把对应数量从可兑池子里"冻"住，谁也动不了，等支付或订单确认了再真正扣掉，超时没成单就自动还回去。这玩意儿防的就是超卖和并发撞车。

库存不预扣，中秋秒兑就是秒超卖。十个人抢同一份礼品，最后系统能给出十一份，剩下那一份就是你的退款单加投诉工单。

去年中秋前在老李家门店吃饭，他家搞月饼兑换活动，链接提前一周预热，结果兑换那天下午三点开闸，五分钟服务器就跪了。老李当时跟我吐槽：服务器配置明明升了一档，怎么还是崩。我跟他掰扯——你这崩的不是机器，是库存逻辑。用户点一下，系统去查库存还剩多少，查完发现够，再扣——这一查一扣中间隔了零点几秒，几百个请求同时查，都查到"够"，全扣下去，库存直接负数。这就叫高并发下的库存超卖。

预扣库存就是给这个口子打补丁。用户点兑换，系统不等支付，先把库存占住，给一个"已预扣"的状态。后面支付失败、订单超时、用户取消，库存自动回滚。这么一搞，再多人同时点，库存池子里始终是真实可兑数，不会出现"明明显示有货，点进去提示已兑完"的尴尬。

兑换系统预扣库存咋扛高并发？机制拆给你看

预扣库存扛高并发，核心三件事：库存放内存数据库别直接读磁盘、扣减用原子操作、订单超时自动回滚。三件套凑齐，中秋那波并发才扛得住。

真正抗并发的预扣库存，库存数永远只在内存里跑，数据库只负责最终落账。一秒钟一万个请求过来，扣的是内存里的数字，不是数据库的行锁。

这一套里头，内存数据库是主角。库存数字放进去，用原子命令扣减——啥叫原子？就是"减一"这个动作不可分割，一千个请求同时来，也是一个一个排队减，绝不会两个请求减到同一个数字上。数据库呢？数据库这时候歇着，只等订单真正成交了再去写一笔记录。

对了，有人问这玩意儿难做吗？其实也不算太难，难的是超时回滚那一段。用户预扣了库存，结果支付页面挂着不动，二十分钟没成单，这库存是不是得还回去？得还。但还回去的时机很讲究——还早了，用户还在支付你把库存放走，体验崩；还晚了，库存被占着别的用户兑不了。市面常见的做法是订单挂个十五到二十分钟的"预扣锁"，超时由后台定时任务统一扫，扫到就回滚。这一段写不好，中秋那天就会出现"明明没人兑，库存却显示不足"的鬼故事。

再就是分布式锁。兑换系统跑好几台机器的话，光内存数据库还不够，还得防着几台机器同时回滚同一笔库存。这层用RedLock或者基于内存数据库的分布式锁都行，道理一样——同一时刻只有一台机器能动这笔库存，避免重复回滚。

预扣库存也有坑，老兵给你提个醒

预扣库存不是装上就万事大吉，超时时间设太长库存被占死、设太短用户支付完发现库存没了、回滚任务挂了库存永远不回来——这三个坑，中秋前必须自己趟一遍。

预扣库存机制装上只是开始，超时回滚任务才是真正的命门。这个定时任务挂了，你库存池子里全是"幽灵预扣"，看着有货兑不出去。

我去年见过一家店翻车，预扣逻辑写得没毛病，Redis也接了，结果中秋当天兑换页面看着库存充足，点进去全提示"库存不足"。排查半天，是回滚任务那台机器硬盘满了，定时任务卡死，几千笔超时预扣全堆在库存池里没还回去。可见库存看着够，其实被一堆"僵尸订单"占着，真实可兑数早就是零。

还有一个坑是预扣数量算错。比如一个用户一次兑5份礼品，预扣的时候只扣了1份库存，结果前4份兑出去，第5份超卖。这种错误一般出在SKU配置上，礼品本身是组合装的，预扣按单品算，最后必然对不上。中秋前一定把SKU和预扣数量的映射关系捋一遍，别等出事再补。

合规这块也提一嘴——预付卡、储值余额相关的兑换，预扣状态必须给用户清楚展示，"已锁定、待确认"几个字别省。用户看不到预扣状态，钱扣了订单没成，第一个投诉的就是你。这事看着小，中秋那天就是爆点。

---

预扣库存这层做扎实了，中秋那天你才能踏实喝茶看数据，而不是在工位上道歉。