微信支付 + redis + 商品超卖问题

Question

微信小程序中的商品存在超卖问题?
原方案: 用户调起微信支付->输入支付密码->服务器验证支付成功->扣减库存

场景1: 用户调起微信支付模态框(长时间停留页面,并不输入支付密码)
场景2: 前面输入支付密码后还未验证支付是否成功,这个时候并没有扣减库存(微信支付回调的响应时间),多个用户同时调起微信支付,

新方案: Redis建立商品虚拟库存->用户小程序中输入支付密码调用统一下单接口时 直接扣减虚拟库存 -> 验证微信回调后若支付失败更新虚拟库存;若支付成功扣减mysql实际库存

1.支付前
A. 库存10(虚拟库存8): => 1个用户打开支付模态框(未输入支付密码) 用户长时间未输入密码(停留页面)=> 扣减虚拟库存websocket更新页面 (redis可设置输入密码有效期强制更新用户页面)

B. 库存10(虚拟库存8): => 100个用户同时点击提交支付按钮(支付模态框前)->使用redis队列(包括A场景)->扣减虚拟库存至0 => 实时反馈另外93个用户商品售罄;

小程序调用统一下单接口时,服务器检查虚拟库存是否可以扣减;如果虚拟库存为0 ->返回错误参数到前台 ->支付失败

若还是存在用户付款并没有商品->原路退款

大家有没有什么更好的方案防止超卖? 交流一下

我觉得重点是尽量让用户付款后可以有库存扣减 -> 如果没有实时反馈->阻断支付

Answer 1

如果有购物车逻辑,一般可以选择在加入购物车的时候,就减库存了.超时未支付再加回去.

如果没有购物车逻辑,那么可以在拉起付款前通过 redis 计数器也好,提前扣库存,无库存时提示阻拦,有库存就生成预付单,这个预付单是有支付失效的,超时库存加回就好.

我们做的商城,页面库存都是直接读取 redis 里缓存的库存计数器,后续业务都是取 redis 数据,redis 里的数据会异步写入数据库持久化.当然,redis需要高可用方案

这样都不会超卖啊..

我们的秒杀场景也是这样来实现,没有问题.