本文主要是介绍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中
好，准备工作做好了，正式开始！
先上代码
可以看到，我们的下单流程是 加分布式锁 -> 判断库存 -> 限购 -> 订单信息放入Redis列表
我们重点来看这个分布式锁如何实现
这里的锁保存的值是一个过期时间的时间戳（毫秒级）
有人说为什么要记录个时间戳呢？为什么不直接利用redis的自动过期时间呢？
有两个原因：
1 redis的set设置健值 和 设置过期时间 是分开的，假设设置了健值，在设置过期时间之前，程序出错了，这个锁就没有过期时间了，就会一直存在redis中，形成死锁
2 把值设为过期时间，可以通过getset方法在设置新过期时间的时候，取得旧的过期时间，判断是否已经被别的进程抢先获得锁
看这段代码：
流程解释：
setnx 判断当前是否有锁
当前没有锁，则获得锁，返回过期时间
当前有锁，判断锁是否过期
如果过期则更新过期时间，getset获得锁，判断返回的的过期时间是否已经被抢先重置了，被抢先则等待20毫秒，没被抢先则返回过期时间
没有过期则等待20毫秒
返回的过期时间，是为了解锁的时候配对上，谁加的锁，只有谁能解。防止执行时间过长的进程解掉了别人的锁，把后面的进程放进来
这样，分布式锁基本就完成了，解锁的时候直接让锁过期即可
这样就可以保证 永远只有一个进程获得锁，永远只有一个进程在进行库存的相关判断和操作，防止超卖
我们进行测试：
商品库存为2000
并发5000次请求
10秒完成，平均每秒500个并发
可以每人买一件的话，生成了2000个订单，写入redis列表
库存为0 没有出现超卖的情况
接下来后来启动个定时任务，每分钟启动一次，每次弹出3000个元素，写入数据库
linux添加定时任务
过一分钟我们看到,队列里的订单已被弹出批量写入数据库了
这篇关于Redis分布式锁 + 队列 + crontab 实现高并发下的抢购流程的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
