Redis分布式锁 + 队列 + crontab 实现高并发下的抢购流程

首先，想象一个场景，商品A预售量1000件，早上10点准时开抢，10W个人一起来抢，在正式开始之后，我们将面对两个问题
1  大批的数据库请求和大量的订单创建，数据库压力巨大，有可能宕机
2  商品可能出现超卖的情况
解决方案如下：

这里我们先看商品超卖的问题
最原始的下单流程无非就是： 判断商品库存是否足够 -> 足够则下单
这种处理方式在没什么并发的情况下不会出现问题，但是一旦并发量一大，这种流程就肯定会出现超卖
假设有A和B两个进程，A要买1个，B也要买1个，可是商品库存就剩下一个了，这两个进程同时进入库存判断，都通过了，然后进入：下单->减库存  最后结果就是商品库存变成了负数，这显然是不符合需求的
所以我们要做的就是，库存判断 ->下单 -> 减库存  让这整个流程原子化  ，要么都能执行，要么先等着，别上赶着。

我们利用redis的单线程，可以实现这一点，也就是俗称的分布式锁
网上关于分布式锁的做法良莠不齐，博主之前也陷入过误区，这里挨个给大家爬坑，抛砖引玉
为了让大家只关注这个锁的意义，这里关于商品过多的信息不作完整赘述，只做简单的举例
这里是redis中存放的商品信息：productInfo:16 指的是ID为16的商品信息（秒杀活动商品详情页打开非常频繁，建议缓存起来）
limitBuy 指的是这件商品的限购数量，一会用得上

 

storage:16 指的是ID为16的商品库存，也建议在添加抢购活动的时候就缓存到redis中