【面试题】Redisson实现Redis分布式锁的底层原理

Redis如何实现分布式锁

1. 最简单的版本：setnx key value

基于setnx命令的特性，我们就可以实现一个最简单的分布式锁了。我们通过向Redis发送 setnx 命令，然后判断Redis返回的结果是否为1，结果是1就表示setnx成功了，那本次就获得锁了，可以继续执行业务逻辑；如果结果是0，则表示setnx失败了，那本次就没有获取到锁，可以通过循环的方式一直尝试获取锁，直至其他客户端释放了锁（delete掉key）后，就可以正常执行setnx命令获取到锁。流程如下：

存在的问题：死锁

这种方式虽然实现了分布式锁的功能，但有一个很明显的问题：没有给key设置过期时间，万一程序在发送delete命令释放锁之前宕机了，那么这个key就会永久的存储在Redis中了，其他客户端也永远获取不到这把锁了。

2. 升级版本：设置key的过期时间SET key value [expiration EX seconds|PX milliseconds] [NX|XX]

SET key value [expiration EX seconds|PX milliseconds] [NX|XX]

EX: 设置超时时间，单位是秒
PX: 设置超时时间，单位是毫秒
NX: IF NOT EXIST 的缩写，只有 KEY不存在的前提下 才会设置值
XX: IF EXIST 的缩写，只有在 KEY存在的前提下 才会设置值

存在的问题：超时失效(下面可以用Redisson来实现锁的自动续期)

存在的问题：锁误删

3. 二次升级版本：value使用唯一值，删除锁时判断value是否当前线程的

要解决上面的问题，最省事的做法就是把锁的过期时间设置长一点，要远大于业务处理时间，但这样就会严重影响系统的性能，假如一台服务器在释放锁之前宕机了，而锁的超时时间设置了一个小时，那么在这一个小时内，其他线程访问这个服务时就一直阻塞在那里。所以，一般不推荐使用这种方式。

另一种解决方法就是在set key value ex seconds nx时，把value设置成一个唯一值，每个线程的value都不一样，在删除key之前，先通过get key命令得到value，然后判断value是否是自己线程生成的，如果是，则删除掉key释放锁，如果不是，则不删除key。正常流程如下：

当业务处理还没结束的时候，key自动过期了，也可以正常释放自己的锁，不影响其他线程：

二次升级后的方案看起来似乎已经没什么问题了，但其实不然。仔细分析流程后我们发现，判断锁是否属于当前线程和释放锁两个步骤并不是原子操作。正常来说，如果线程1通过get操作从Redis中得到的value是123，那么就会执行删除锁的操作，但假如在执行删除锁的动作之前，系统卡顿了几秒钟，恰好在这几秒钟内，key自动过期了，线程2就顺利获取到锁开始执行自己的逻辑了，此时，线程1卡顿恢复了，开始继续执行删除锁的动作，那么此时删除的还是线程2的锁。

4. 终极版本：Lua脚本

针对上述Redis原始命令无法满足部分业务原子性操作的问题，Redis提供了Lua脚本的支持。Lua脚本是一种轻量小巧的脚本语言，它支持原子性操作，Redis会将整个Lua脚本作为一个整体执行，中间不会被其他请求插入，因此Redis执行Lua脚本是一个原子操作。

在上面的流程中，我们把get key value、判断value是否属于当前线程、删除锁这三步写到Lua脚本中，使它们变成一个整体交个Redis执行，改造后流程如下：

这样改造之后，就解决了释放锁时取值、判断值、删除锁等多个步骤无法保证原子操作的问题了。关于Lua脚本的语法可以自行学习，并不复杂，很简单，这里就不做过多讲述。

Lua脚本实现可重入锁

既然Lua脚本可以在释放锁时使用，那肯定也能在加锁时使用，而且一般情况下，推荐使用Lua脚本，因为在使用上面set key value ex seconds nx命令加锁时，并不能做到重入锁的效果，也就是当一个线程获取到锁后，在没有释放这把锁之前，当前线程自己也无法再获得这把锁，这显然会影响系统的性能。使用Lua脚本就可以解决这个问题，我们可以在Lua脚本中先判断锁（key）是否存在，如果存在则再判断持有这把锁的线程是否是当前线程，如果不是则加锁失败，否则当前线程再次持有这把锁，并把锁的重入次数+1。在释放锁时，也是先判断持有锁的线程是否是当前线程，如果是则将锁的重入次数-1，直至重入次数减至0，即可删除该锁（key）。

实际项目开发中，其实基本不用自己写上面这些分布式锁的实现逻辑，而是使用一些很成熟的第三方工具，当下比较流行的就是Redisson，它既提供了Redis的基本命令的封装，也提供了Redis分布式锁的封装，使用非常简单，只需直接调用相应方法即可。

Redisson框架

1. Redisson实现Redis分布式锁的底层原理

2. 加锁机制

咱们来看上面那张图，现在某个客户端要加锁。如果该客户端面对的是一个redis cluster集群，他首先会根据hash节点选择一台机器。
这里注意，仅仅只是选择一台机器！这点很关键！
紧接着，就会发送一段lua脚本到redis上，那段lua脚本如下所示：

为啥要用lua脚本呢？

因为一大坨复杂的业务逻辑，可以通过封装在lua脚本中发送给redis，保证这段复杂业务逻辑执行的原子性。

lua脚本分析

KEYS[1]代表的是你加锁的那个key，比如说：RLock lock = redisson.getLock("myLock");这里你自己设置了加锁的那个锁key就是“myLock”。
ARGV[2]代表的是加锁的客户端的ID，类似于下面这样：8743c9c0-0795-4907-87fd-6c719a6b4586:1
ARGV[1]代表的就是锁key的默认生存时间，默认30秒。

hset myLock 8743c9c0-0795-4907-87fd-6c719a6b4586:1 1

通过这个命令设置一个hash数据结构，这行命令执行后，会出现一个类似下面的数据结构：

上述就代表8743c9c0-0795-4907-87fd-6c719a6b4586:1这个客户端对myLock这个锁key完成了加锁。
接着会执行pexpire myLock 30000命令，设置myLock这个锁key的生存时间是30秒。
好了，到此为止，ok，加锁完成了。

3. 锁互斥机制（客户端2来尝试加锁）

那么在这个时候，如果客户端2来尝试加锁，执行了同样的一段lua脚本，会咋样呢？
很简单，第一个if判断会执行exists myLock，发现myLock这个锁key已经存在了。
接着第二个if判断，判断一下，myLock锁key的hash数据结构中，是否包含客户端2的ID，但是明显不是的，因为那里包含的是客户端1的ID。
所以，客户端2会获取到pttl myLock返回的一个数字，这个数字代表了myLock这个锁key的剩余生存时间。比如还剩15000毫秒的生存时间。
此时客户端2会进入一个while循环，不停的尝试加锁（类似于自旋锁）。

4. 可重入加锁机制

第一个if判断肯定不成立，exists myLock会显示锁key已经存在了。
第二个if判断会成立，因为myLock的hash数据结构中包含的那个ID，就是客户端1的那个ID，也就是8743c9c0-0795-4907-87fd-6c719a6b4586:1
此时就会执行可重入加锁的逻辑，他会用：
incrby myLock 8743c9c0-0795-4907-87fd-6c71a6b4586:1 1
通过这个命令，对客户端1的加锁次数，累加1。
此时myLock数据结构变为下面这样（myLock的hash数据结构中的那个客户端ID，就对应着加锁的次数）：

5. watch dog自动延期机制

客户端1加锁的锁key默认生存时间才30秒，如果超过了30秒，客户端1还想一直持有这把锁，怎么办呢？

简单！只要客户端1一旦加锁成功，就会启动一个watch dog看门狗，他是一个后台线程，会每隔10秒检查一下，如果客户端1还持有锁key，那么就会不断的延长锁key的生存时间。

6. 解锁

如果执行lock.unlock()，就可以释放分布式锁，此时的业务逻辑也是非常简单的。
其实说白了，就是每次都对myLock数据结构中的那个加锁次数减1。如果发现加锁次数是0了，说明这个客户端已经不再持有锁了，此时就会用del myLock命令，从redis里删除这个key。
然后呢，另外的客户端2就可以尝试完成加锁了。

一般我们在生产系统中，可以用Redisson框架提供的这个类库来基于redis进行分布式锁的加锁与释放锁。

实际业务开发场景：每秒上千订单场景下的分布式锁高并发优化

问题描述

假如下单时，用分布式锁来防止库存超卖，但是是每秒上千订单的高并发场景，如何对分布式锁进行高并发优化来应对这个场景？
既然面试官限定死了用分布式锁来解决库存超卖，我估计就是想问一个点：在高并发场景下如何优化分布式锁的并发性能。因为在实际落地生产的时候，分布式锁这个东西保证了数据的准确性，但是它天然并发能力有点弱。

电商高并发秒杀场景下的库存超卖解决方案

因为库存超卖问题是有很多种技术解决方案的，比如悲观锁，分布式锁，乐观锁，队列串行化，Redis原子操作，等等吧。

库存超卖现象是怎么产生的？

这个图，其实很清晰了，假设订单系统部署两台机器上，不同的用户都要同时买10台iphone，分别发了一个请求给订单系统。接着每个订单系统实例都去数据库里查了一下，当前iphone库存是12台。俩大兄弟一看，乐了，12台库存大于了要买的10台数量啊！于是乎，每个订单系统实例都发送SQL到数据库里下单，然后扣减了10个库存，其中一个将库存从12台扣减为2台，另外一个将库存从2台扣减为-8台。现在完了，库存出现了负数！泪奔啊，没有20台iphone发给两个用户啊！这可如何是好。

用分布式锁如何解决库存超卖问题？

同一个锁key，同一时间只能有一个客户端拿到锁，其他客户端会陷入无限的等待来尝试获取那个锁，只有获取到锁的客户端才能执行下面的业务逻辑。

流程图

从上图可以看到，只有一个订单系统实例可以成功加分布式锁，然后只有他一个实例可以查库存、判断库存是否充足、下单扣减库存，接着释放锁。
释放锁之后，另外一个订单系统实例才能加锁，接着查库存，一下发现库存只有2台了，库存不足，无法购买，下单失败。不会将库存扣减为-8的。

分布式锁的方案在高并发场景下的缺陷

分布式锁一旦加了之后，对同一个商品的下单请求，会导致所有客户端都必须对同一个商品的库存锁key进行加锁。比如，对iphone这个商品的下单，都必对“iphone_stock”这个锁key来加锁。这样会导致对同一个商品的下单请求，就必须串行化，一个接一个的处理。

假设加锁之后，释放锁之前，查库存 -> 创建订单 -> 扣减库存，这个过程性能很高吧，算他全过程20毫秒，这应该不错了。那么1秒是1000毫秒，只能容纳50个对这个商品的请求依次串行完成处理。比如一秒钟来50个请求，都是对iphone下单的，那么每个请求处理20毫秒，一个一个来，最后1000毫秒正好处理完50个请求。

所以看到这里，大家起码也明白了，简单的使用分布式锁来处理库存超卖问题，存在什么缺陷。
缺陷就是同一个商品多用户同时下单的时候，会基于分布式锁串行化处理，导致没法同时处理同一个商品的大量下单的请求。
这种方案，要是应对那种低并发、无秒杀场景的普通小电商系统，可能还可以接受。因为如果并发量很低，每秒就不到10个请求，没有瞬时高并发秒杀单个商品的场景的话，其实也很少会对同一个商品在一秒内瞬间下1000个订单，因为小电商系统没那场景。

分布式锁的方案在高并发场景下的性能优化

面试官说，我现在就卡死，库存超卖就是用分布式锁来解决，而且一秒对一个iphone下上千订单，怎么优化？
现在按照刚才的计算，你一秒钟只能处理针对iphone的50个订单。
其实说出来也很简单，相信很多人看过java里的ConcurrentHashMap的源码和底层原理，应该知道里面的核心思路，就是分段加锁！
把数据分成很多个段，每个段是一个单独的锁，所以多个线程过来并发修改数据的时候，可以并发的修改不同段的数据。不至于说，同一时间只能有一个线程独占修改ConcurrentHashMap中的数据。
另外，Java 8中新增了一个LongAdder类，也是针对Java 7以前的AtomicLong进行的优化，解决的是CAS类操作在高并发场景下，使用乐观锁思路，会导致大量线程长时间重复循环。LongAdder中也是采用了类似的分段CAS操作，失败则自动迁移到下一个分段进行CAS的思路。

原理图

原理分析

其实这就是分段加锁。你想，假如你现在iphone有1000个库存，那么你完全可以给拆成20个库存段，要是你愿意，可以在数据库的表里建20个库存字段，比如stock_01，stock_02，类似这样的，也可以在redis之类的地方放20个库存key。
总之，就是把你的1000件库存给他拆开，每个库存段是50件库存，比如stock_01对应50件库存，stock_02对应50件库存。

接着，每秒1000个请求过来了，好！此时其实可以是自己写一个简单的随机算法，每个请求都是随机在20个分段库存里，选择一个进行加锁。
这样就好了，同时可以有最多20个下单请求一起执行，每个下单请求锁了一个库存分段，然后在业务逻辑里面，就对数据库或者是Redis中的那个分段库存进行操作即可，包括查库存 -> 判断库存是否充足 -> 扣减库存。
这相当于什么呢？相当于一个20毫秒，可以并发处理掉20个下单请求，那么1秒，也就可以依次处理掉20 * 50 = 1000个对iphone的下单请求了。

一旦对某个数据做了分段处理之后，有一个坑大家一定要注意：就是如果某个下单请求，咔嚓加锁，然后发现这个分段库存里的库存不足了，此时咋办？这时你得自动释放锁，然后立马换下一个分段库存，再次尝试加锁后尝试处理。这个过程一定要实现。

存在的问题

不足肯定是有的，最大的不足，大家发现没有，很不方便啊！实现太复杂了。
首先，你得对一个数据分段存储，一个库存字段本来好好的，现在要分为20个分段库存字段；
其次，你在每次处理库存的时候，还得自己写随机算法，随机挑选一个分段来处理；
最后，如果某个分段中的数据不足了，你还得自动切换到下一个分段数据去处理。
这个过程都是要手动写代码实现的，还是有点工作量，挺麻烦的。

来源：
Redis如何实现分布式锁
Redisson分布式锁实现、实际业务开发场景：每秒上千订单场景下的分布式锁高并发优化