面试专栏：分布式锁

分布式锁场景

如果想真正了解分布式锁，需要结合一定场景; 举个例子，某夕夕上抢购 AirPods Pro 的 100 元优惠券。

如果使用下面这段代码当作抢购优惠券的后台程序，我们一起看一下，可能存在什么样的问题。

很明显的就是这段流程在并发场景下并不安全，会导致优惠券发放超过预期，类似电商抢购超卖问题。

想一哈有什么方式可以避免这种分布式下超量问题?

互斥加锁，Java 中互斥锁的语义就是 同一时间，只允许一个客户端对资源进行操作。

比如 Java 中的关键字 Synchronized，以及 JUC Lock 包下的 ReentrantLock 都可以实现互斥锁。

1. JVM 本地锁

如图所示，加入 JVM synchronized 锁确实可以解决单机下并发问题。

但是生产环境为了保证服务高可用，起码要 部署两台服务，这样的话 synchronized 就不起作用了，因为它的 作用域只是单个 JVM。

分布式情况下只能通过 分布式锁 来解决多个服务资源共享的问题了。

2. 分布式锁

分布式锁的定义：保证同一时间只能有一个客户端对共享资源进行操作。

比对刚才举的例子，不论部署多少台优惠券服务，只会有 一台服务能够对优惠券数量进行增删操作。

另外有几点要求也是必须要满足的:

1. 不会发生死锁。即使有一个客户端在持有锁的期间崩溃而没有主动解锁，也能保证后续其他客户端能加锁。
2. 具有容错性。只要大部分的 Redis 节点正常运行，客户端就可以加锁和解锁。
3. 解铃还须系铃人。加锁和解锁必须是同一个客户端，客户端自己不能把别人加的锁给解了。

分布式锁实现大致分为三种，Redis、Zookeeper、数据库，文章以 Redis 展开分布式锁的讨论。

分布式锁演进史

先来构思下分布式锁实现思路。

首先我们必须保证同一时间只有一个客户端(部署的优惠券服务)操作数量加减。其次本次 客户端操作完成后，需要让 其它客户端继续执行：

1. 客户端一存放一个标志位，如果添加成功，操作减优惠券数量操作。
2. 客户端二添加标志位失败，本次减库存操作失败（或继续尝试获取等）。
3. 客户端一优惠券操作完成后，需要将标志位释放，以便其余客户端对库存进行操作。

1. 第一版 setnx

向 Redis 中添加一个 lockKey 锁标志位，如果添加成功则能够继续向下执行扣减优惠券数量操作，最后再释放此标志位。

由于使用的是 Spring 提供的 Redis 封装的 Start 包，所有有些命令与 Redis 原生命令不相符。

setIfAbsent(key，val) -> setnx(key，val)

加了简单的几行代码，一个简单的分布式锁的雏形就出来了。

2. 第二版 expire

上面第一版基于 setnx 命令实现分布式锁的缺陷也是很明显的，那就是 一定情况下可能发生死锁。

画个图，举个例子说明哈。

上图说明，线程 1 在成功获取锁后，执行流程时异常结束，没有执行释放锁操作，这样就会 产生死锁。

如果方法执行异常导致的线程被回收，那么可以将解锁操作放到 finally 块中。

但是还有存在死锁问题，如果获得锁的线程在执行中，服务被强制停止或服务器宕机，锁依然不会得到释放。

这种极端情况下我们还是要考虑的，毕竟不能只想着服务没问题对吧。

对 Redis 的 锁标志位加上过期时间 就能很好的防止死锁问题，继续更改下程序代码。

虽然 小红旗处 对分布式锁添加了过期时间，但依然无法避免极端情况下的死锁问题。

那就是如果在客户端加锁成功后，还没有设置过期时间时宕机。

如果想要避免添加锁时死锁，那就对添加锁标志位 & 添加过期时间命令 保证一个原子性，要么一起成功，要么一起失败。

3. 第三版 set

我们的添加锁原子命令就要登场了，从 Redis 2.6.12 版本起，提供了可选的 字符串 set 复合命令。

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

可选参数如下:

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

继续完善分布式锁的应用程序，代码如下:

我使用的 2.0.9.RELEASE 版本的 SpringBoot，RedisTemplate 中不支持 set 复合命令，所以临时换个 Jedis 来实现。

加锁以及设置过期时间确实保证了原子性，但是这样的分布式锁就没有问题了么?

我们根据图片以及流程描述设想一下这个场景：

1. 线程一获取锁成功，设置过期时间五秒，接着执行业务逻辑；
2. 接着线程一获取锁后执行业务流程，执行的时间超过了过期时间，锁标志位过期进行释放，此时线程二获取锁成功；
3. 然而此时线程一执行完业务后，开始执行释放锁的流程，然后顺手就把线程二获取的锁释放了。

如果线上真的发生上述问题，就可能会造成线上数据和业务的运行异常，更甚者可能存在线程一将线程二的锁释放掉之后，线程三获取到锁，然后线程二执行完将线程三的锁释放。

4. 第四版 verify value

事当如今，只能创建辨别客户端身份的唯一值了，将加锁及解锁归一化，上代码。

这一版的代码相当于我们添加锁标志位时，同时为每个客户端设置了 uuid 作为锁标志位的 val，解锁时需要判断锁的 val 是否和自己客户端的相同，辨别成功才会释放锁。

但是上述代码执行业务逻辑如果抛出异常，锁只能等待过期时间，我们可以将解锁操作放到 finally 块。

大眼一看，上上下下实现了四版分布式锁，也该没问题了吧。

真相就是: 解锁时， 由于判断锁和删除标志位并不是原子性的，所以可能还是会存在误删。

1. 线程一获取锁后，执行流程 balabala... 判断锁也是自家的，这时 CPU 转头去做别的事情了，恰巧线程一的锁过期时间到了；
2. 线程二此时顺理成章的获取到了分布式锁，执行业务逻辑 balabala；
3. 线程一再次分配到时间片继续执行删除操作。

解决这种非原子操作的方式只能 将判断元素值和删除标志位当作一个原子操作。

5. 第五版 lua

很不友好的是，del 删除操作并没有提供原子命令，所以我们需要想点办法。

Redis 在 2.6 推出了脚本功能，允许开发者使用 Lua 语言编写脚本传到 Redis 中执行。

使用 Lua 脚本有什么好处呢?

1. 减少网络开销：原本我们需要向 Redis 服务请求多次命令，可以将命令写在 Lua 脚本中，这样执行只会发起一次网络请求。
2. 原子操作：Redis 会将 Lua 脚本中的命令当作一个整体执行，中间不会插入其它命令。
3. 复用：客户端发送的脚步会存储 Redis 中，其他客户端可以复用这一脚本而不需要使用代码完成相同的逻辑。

那我们编写一个简单的 Lua 脚本实现原子删除操作。

重点就在 Lua 脚本这一块，重点说一下这块的逻辑。

script 脚本就是我们在 Redis 中执行的 Lua 脚本，后面跟的两个 List 分别是 KEYS、ARGV。

cache.eval(script，Lists.newArrayList(lockKey)，Lists.newArrayList(lockValue));

• KEYS[1]: lockKey
• ARGV[1]: lockValue

代码不是很多，也比较简单，就是在 Java 中代码实现的逻辑放到了一个 Lua 脚本中。

# 获取 KEYS[1] 对应的 Val
local cliVal = redis.call('get'，KEYS[1])
# 判断 KEYS[1] 与 ARGV[1] 是否保持一致
if(cliVal == ARGV[1]) then
  # 删除 KEYS[1]
  redis.call('del'，KEYS[1])
  return 'OK'
else
  return nil
end

到了这种程度，已经可以放到一些并发量不大的项目中生产使用了。

Redission分布式锁

虽然上述代码已经很大程度上解决了分布式锁可能存在的一些问题。

但是下述列出的问题部分就不是客户端代码范畴内的事情了：

• 如何实现可重入锁。
• 如何解决代码执行锁超时。
• 主从节点同步数据丢失导致锁丢失问题。

上述问题等下一篇介绍 Redisson 源码时会一一说明，顺道向大家推出一款 Redis 官方推荐的客户端: Redisson。

Jedis... 等客户端平常使用是绰绰有余的，但是在功能上还是和 Redisoon 比不了。

并不是推荐一定要用 Redisson，根据不同场景选用不同客户端。

Redisson 就是为分布式提供 各种不同锁以及多样化的技术支持, 感兴趣的小伙伴可以看一下 Giuhub 上的介绍，挺详细的。

 Redisson原理分析

加锁机制

线程去获取锁，获取成功: 执行lua脚本，保存数据到redis数据库。

线程去获取锁，获取失败: 一直通过while循环尝试获取锁，获取成功后，执行lua脚本，保存数据到redis数据库。

watch dog自动延期机制

这个比较难理解，找了些许资料感觉也并没有解释的很清楚。这里我自己的理解就是:

在一个分布式环境下，假如一个线程获得锁后，突然服务器宕机了，那么这个时候在一定时间后这个锁会自动释放，你也可以设置锁的有效时间(不设置默认30秒），这样的目的主要是防止死锁的发生。

但在实际开发中会有下面一种情况:

   //设置锁1秒过去
        redissonLock.lock("redisson", 1);
        /**
         * 业务逻辑需要咨询2秒
         */
        redissonLock.release("redisson");

      /**
       * 线程1 进来获得锁后，线程一切正常并没有宕机，但它的业务逻辑需要执行2秒，这就会有个问题，在 线程1 执行1秒后，这个锁就自动过期了，
       * 那么这个时候 线程2 进来了。那么就存在 线程1和线程2 同时在这段业务逻辑里执行代码，这当然是不合理的。
       * 而且如果是这种情况，那么在解锁时系统会抛异常，因为解锁和加锁已经不是同一线程了，具体后面代码演示。
       */

所以这个时候看门狗就出现了，它的作用就是 线程1 业务还没有执行完，时间就过了，线程1 还想持有锁的话，就会启动一个watch dog后台线程，不断的延长锁key的生存时间。

注意 正常这个看门狗线程是不启动的，还有就是这个看门狗启动后对整体性能也会有一定影响，所以不建议开启看门狗。

为啥要用lua脚本呢？

这个不用多说，主要是如果你的业务逻辑复杂的话，通过封装在lua脚本中发送给redis，而且redis是单线程的，这样就保证这段复杂业务逻辑执行的原子性。

可重入加锁机制

Redisson可以实现可重入加锁机制的原因，我觉得跟两点有关：

1、Redis存储锁的数据类型是 Hash类型

2、Hash数据类型的key值包含了当前线程信息

缺点 

Redis分布式锁会有个缺陷，就是在Redis哨兵模式下:

客户端1 对某个master节点写入了redisson锁，此时会异步复制给对应的 slave节点。但是这个过程中一旦发生 master节点宕机，主备切换，slave节点从变为了 master节点。

这时客户端2 来尝试加锁的时候，在新的master节点上也能加锁，此时就会导致多个客户端对同一个分布式锁完成了加锁。

这时系统在业务语义上一定会出现问题，导致各种脏数据的产生。

缺陷在哨兵模式或者主从模式下，如果 master实例宕机的时候，可能导致多个客户端同时完成加锁。