超卖问题切入

我们先来看一个项目中的真实的场景： 抢卷的场景

咋一看流程好像特别正常，但是但是这是一个抢卷的过程，疯狂程度可想而知，并且线程又是交替进行的，可能在线程1刚查询到库存时，线程2同时也拿到了库存，此时线程1和线程2拿到的库存量是相同的，比如都是1，但是线程1先进行了-1操作，而线程2此时拿到的值仍然是1，他并不知道有别的线程已经修改了值为0，那么当线程2进行-1操作时，就会出现超卖的问题，具体的流程图如下：

可以使用互斥锁给先获取到锁的线程加锁吗？

如果你的项目是一个单体的项目，只启动了一个服务，那么是完全没问题的，具体的流程以及代码可以参考下面：


如果我们把项目代码通过nginx反向代理部署到多个服务器上，那么这种方案就不行了，单个JVM下能保证线程和线程之间的互斥，但是多个服务器多个JVM之间是无法互斥的

使用redis分布式锁解决超卖问题

在上面我们讲到多个服务之间我们无法让不同JVM之间的互斥锁产生效果，那么我们可以想一下，如果我们通过一个媒介，在多个服务内只要有线程加到锁了，那么就记录一下，如果有别的线程再来加锁，就能产生互斥的效果了，这个媒介就是分布式锁，具体的流程可以参考下图

setnx命令实现分布式锁

/**
获取锁
**/
SET lock value NX EX 10
/**
释放锁
**/
DEL key

为什么需要设置过期时间？

如果不设置过期时间，通过setnx命令获取到锁之后，在还没释放锁之前，如果业务超时或者服务宕机，那么就会一直占用着这把锁，会出现死锁的问题，但是如果设置了过期时间的话，当这把锁过期之后就会自动的将锁给释放。

Redis实现分布式锁如何合理控制锁的有效时长

过期时间太长了，如果业务代码早早的就执行完了，影响整体的效率
过期时间太短了，如果业务代码还没执行完就过期了也不行
如果我们自己凭感觉去填一个过期时间，其实是非常不靠谱的一件事情，那如果我们再开一个线程来监控这把锁呢？当锁过期之后给锁续期，这个是不是听着就比较靠谱了，其实市面上早就已经有了这种技术实现了，下面我们就来讲一下redisson

redisson实现分布式锁

我们来看一下具体的流程：

通过看门狗机制能够实现续期，默认是每隔10秒的时间做一次续期，而抢不到锁的线程会进行尝试等待，进行while循环不断尝试获取锁