在分布式系统中，当有多个客户端需要获取锁时，我们需要分布式锁。此时，锁是保存在一个共享存储系统中的，可以被多个客户端共享访问和获取。Redis 本身可以被多个客户端共享访问，正好就是一个共享存储系统，可以用来保存分布式锁。而且 Redis 的读写性能高，可以应对高并发的锁操作场景。

和单机上的锁类似，分布式锁同样可以用一个变量来实现。客户端加锁时需要判断锁变量的值，根据锁变量值来判断能否加锁成功；释放锁时需要把锁变量值设置为 0，表明客户端不再持有锁。但和线程在单机上操作锁不同的是，在分布式场景下，锁变量需要由一个共享存储系统来维护，这样多个客户端才可以通过访问共享存储系统来访问锁变量。相应的，加锁和释放锁的操作就变成了读取、判断和设置共享存储系统中的锁变量值。

这样一来，我们就可以得出实现分布式锁的两个要求。

  • 要求一：分布式锁的加锁和释放锁的过程，涉及多个操作。所以，在实现分布式锁时，我们需要保证这些锁操作的原子性；
  • 要求二：共享存储系统保存了锁变量，如果共享存储系统发生故障或宕机，那么客户端也就无法进行锁操作了。在实现分布式锁时，我们需要考虑保证共享存储系统的可靠性，进而保证锁的可靠性。

下面，我们就来学习下 Redis 是怎么实现分布式锁的。

分布式锁操作过程

作为分布式锁实现过程中的共享存储系统，Redis 可以使用键值对来保存锁变量，再接收和处理不同客户端发送的加锁和释放锁的操作请求。我们需要赋予锁变量一个变量名，把这个变量名作为键，而锁变量的值则是键值对的值，这样 Redis 就能保存锁变量了，客户端也就可以通过 Redis 的命令操作来实现锁操作。
1d18742c1e5fc88835ec27f1becfc145.webp
可以看到，Redis 可以使用一个键值对 lock_key:0 来保存锁变量，其中，锁变量的名称是 lock_key，锁变量的初始值是 0。图中客户端 A 和 C 同时请求加锁。因为 Redis 使用单线程处理请求，即使客户端 A 和 C 同时把加锁请求发给了 Redis，Redis 也会串行处理它们的请求。

假设 Redis 先处理客户端 A 的请求，读取 lock_key 的值，发现 lock_key 为 0，所以 Redis 就把 lock_key 的值设为 1，表示已经加锁了。紧接着，Redis 处理客户端 C 的请求，此时，Redis 会发现 lock_key 的值已经为 1 了，所以就返回加锁失败的信息。相应地，释放锁就是直接把锁变量值设置为 0。

分布式锁的原子性

因为分布式锁的加锁过程包含了三个操作（读取锁变量、判断锁变量值以及把锁变量值设置为 1），而这三个操作在执行时需要保证原子性。我们可以使用 Redis 的单命令操作和使用 Lua 脚本来保证原子性。

1. SETNX

首先是 SETNX 命令，它用于设置键值对的值。具体来说，就是这个命令在执行时会判断键值对是否存在，如果不存在，会先创建键值对，然后设置它的值；如果存在，就不做任何设置。

  1. SETNX key value

为了能达到和 SETNX 命令一样的效果，Redis 也给 SET 命令提供了 NX 选项。此外，SET 命令在执行时还可以带上 EX 或 PX 选项，用来设置键值对的过期时间。

  1. SET key value [EX seconds | PX milliseconds]  [NX]

对于释放锁操作来说，我们可以在执行完业务逻辑后，使用 DEL 命令删除锁变量。不过，使用 SETNX 和 DEL 命令组合实现分布锁，存在两个潜在的风险。

第一个风险是，假如某个客户端在执行了 SETNX 命令、加锁之后，紧接着却在操作共享数据时发生了异常，结果一直没有执行最后的 DEL 命令释放锁。因此，锁就一直被这个客户端持有，其它客户端无法拿到锁，也无法访问共享数据和执行后续操作，这会给业务应用带来影响。

针对这个问题，我们可以给锁变量设置一个过期时间。这样，即使持有锁的客户端发生了异常，无法主动地释放锁，Redis 也会根据锁变量的过期时间，在锁变量过期后把它删除。其它客户端在锁变量过期后就可以重新请求加锁，这就不会出现无法加锁的问题了。注意，设置过期时间时要使用 SET 命令原子性地设置过期时间。

第二个风险是，如果客户端 A 执行了 SETNX 命令加锁后，假设客户端 B 执行了 DEL 命令释放锁，此时，客户端 A 的锁就被误释放了。如果客户端 C 正好也在申请加锁，就可以成功获得锁，进而开始操作共享数据。这样一来，客户端 A 和 C 同时在对共享数据进行操作，数据就会被修改错误，这也是业务层不能接受的。

针对这个问题，我们需要能区分来自不同客户端的锁操作，具体就是在加锁操作时，针对每个客户端给锁变量设置一个唯一值，这里的唯一值就可以用来标识当前操作的客户端。在释放锁操作时，客户端需要判断，当前锁变量的值是否和自己的唯一标识相等，只有在相等的情况下，才能释放锁。

总结下来，我们可以用下面的命令来实现加锁操作了。

  1. SET lock_key unique_value NX PX 10000

其中，unique_value 是客户端的唯一标识，可以用一个随机生成的字符串来表示，PX 10000 则表示 lock_key 会在 10s 后过期，以免客户端在这期间发生异常而无法释放锁。

2. Lua 脚本

和加锁类似，释放锁也包含了读取锁变量值、判断锁变量值和删除锁变量三个操作，不过，我们无法使用单个命令来实现，所以，我们可以采用 Lua 脚本执行释放锁操作，通过 Redis 原子性地执行 Lua 脚本，来保证释放锁操作的原子性。如下伪代码为释放锁的逻辑，每个客户端都使用了一个唯一标识，所以在释放锁操作时，我们需要判断锁变量的值，是否等于执行释放锁操作的客户端的唯一标识：

  1. //释放锁 比较unique_value是否相等，避免误释放
  2. if redis.call("get",KEYS[1]) == ARGV[1] then
  3.     return redis.call("del",KEYS[1])
  4. else
  5.     return 0
  6. end

其中，KEYS[1] 表示 lock_key，ARGV[1] 是当前客户端的唯一标识，这两个值都是我们在执行 Lua 脚本时作为参数传入的。最后执行以下命令就完成了锁释放操作。

  1. redis-cli  --eval  unlock.script lock_key , unique_value

分布式锁的高可靠

如果我们只用一个 Redis 实例来保存锁变量，当这个 Redis 实例发生故障宕机时，这个锁变量就没有了。此时，客户端也无法进行锁操作了，这就会影响到业务的正常执行。所以，我们在实现分布式锁时，还需要保证锁的可靠性，也就是基于多个 Redis 节点来实现分布式锁。

当我们要实现高可靠的分布式锁时，就不能只依赖单个的命令操作了，我们需要按照一定的步骤和规则进行加解锁操作，否则，就可能会出现锁无法工作的情况。为了避免 Redis 实例故障而导致的锁无法工作的问题，Redis 的开发者 Antirez 提出了分布式锁算法 RedLock 算法，用来实现基于多个实例的分布式锁。这样一来，锁变量由多个实例维护，即使有实例发生了故障，锁变量仍然是存在的，客户端还是可以完成锁操作。

使用主从集群模式是否可以保证锁的可靠性？答案是不能。因为如果刚在 master 上加锁成功，此时 master 宕机，由于主从复制是异步的，加锁操作的命令还未同步到 slave，此时主从切换，新 master 节点依旧会丢失该锁，对业务来说也相当于锁失效了。

1. RedLock 执行步骤

RedLock 算法的基本思路，是让客户端和多个独立的 Redis 实例依次请求加锁，如果客户端能够和半数以上的实例成功地完成加锁操作，那么我们就认为，客户端成功地获得分布式锁了，否则加锁失败。这样一来，即使有单个 Redis 实例发生故障，因为锁变量在其它实例上也有保存，所以，客户端仍然可以正常地进行锁操作，锁变量并不会丢失。

RedLock 算法的实现需要有 N 个独立的 Redis 实例。接下来，我们可以分成 3 步来完成加锁操作。

第一步：客户端获取当前时间。

第二步：客户端按顺序依次向 N 个 Redis 实例执行加锁操作。

这里的加锁操作和在单实例上执行的加锁操作一样，使用 SET 命令，带上 NX，EX/PX 选项，以及带上客户端的唯一标识。当然，如果某个 Redis 实例发生故障了，为了保证在这种情况下，Redlock 算法能够继续运行，我们需要给加锁操作设置一个超时时间。

如果客户端在和一个 Redis 实例请求加锁时，一直到超时都没有成功，那么此时，客户端会和下一个 Redis 实例继续请求加锁。加锁操作的超时时间需要远远地小于锁的有效时间，一般也就是设置为几十毫秒。

第三步：一旦客户端完成了和所有 Redis 实例的加锁操作，客户端就要计算整个加锁过程的总耗时。

客户端只有在满足下面的这两个条件时，才能认为是加锁成功。

  • 条件一：客户端从超过半数（大于等于 N/2+1）的 Redis 实例上成功获取到了锁；
  • 条件二：客户端获取锁的总耗时没有超过锁的有效时间。

在满足了这两个条件后，我们需要重新计算这把锁的有效时间，计算的结果是锁的最初有效时间减去客户端为获取锁的总耗时。如果锁的有效时间已经来不及完成共享数据的操作了，我们可以释放锁，以免出现还没完成数据操作，锁就过期了的情况。

当然，如果客户端在和所有实例执行完加锁操作后，没能同时满足这两个条件，那么客户端向所有 Redis 节点发起释放锁的操作。释放锁时，要对所有节点释放（即使某个节点加锁失败了），因为加锁时可能发生服务端加锁成功，由于网络问题，给客户端回复网络包失败的情况，所以需要把所有节点可能存的锁都释放掉。

在 RedLock 算法中，释放锁的操作和在单实例上释放锁的操作一样，只要执行释放锁的 Lua 脚本就可以。这样一来，只要 N 个 Redis 实例中的半数以上实例能正常工作，就能保证分布式锁的正常工作了。所以，在实际的业务应用中，如果想提升分布式锁的可靠性，可以通过 RedLock 算法来实现。不过 RedLock 算法还需要考虑出错重试、时钟漂移等很多细节问题，同时因为 RedLock 需要向多个节点进行读写，意味着相比单实例 Redis 的性能会下降一些。

2. RedLock 缺陷

使用 Redlock 时要避免机器时钟发生跳跃，需要运维来保证，对运维有一定要求，否则可能会导致 Redlock 失效。例如共 3 个节点，线程 A 操作 2 个节点加锁成功，但其中 1 个节点机器时钟发生跳跃，锁提前过期，线程 B 正好在另外 2 个节点也加锁成功，此时 Redlock 相当于失效了。

参考链接：http://zhangtielei.com/posts/blog-redlock-reasoning.html

3. Redisson 分布式锁

Redisson 由 Redis 官方推出的组件，它不仅提供了一系列的分布式的 Java 常用对象，还提供了许多分布式服务。Redisson 是基于 netty 通信框架实现的，所以支持非阻塞通信，性能相对 Jedis 会好一些。Redisson 中实现了 Redis 分布式锁，且支持单点模式和集群模式。在集群模式下，Redisson 使用了 Redlock 算法，避免在 Master 节点崩溃切换到另外一个 Master 时，多个应用同时获得锁。

Redisson 的 maven 依赖：

  1. <dependency>
  2.       <groupId>org.redisson</groupId>
  3.       <artifactId>redisson</artifactId>
  4.       <version>3.8.2</version>
  5. </dependency>

实现 Redisson 的配置文件：

  1. @Bean
  2. public RedissonClient redissonClient() {
  3.     Config config = new Config();
  4.     config.useClusterServers()
  5.             .setScanInterval(2000) // 集群状态扫描间隔时间，单位是毫秒
  6.             .addNodeAddress("redis://127.0.0.1:7000).setPassword("1")
  7.             .addNodeAddress("redis://127.0.0.1:7001").setPassword("1")
  8.             .addNodeAddress("redis://127.0.0.1:7002")
  9.             .setPassword("1");
  10.     return Redisson.create(config);
  11. }

Redisson 获取分布式锁操作：

  1. long waitTimeout = 10;
  2. long leaseTime = 1;
  3. RLock lock1 = redissonClient1.getLock("lock1");
  4. RLock lock2 = redissonClient2.getLock("lock2");
  5. RLock lock3 = redissonClient3.getLock("lock3");
  7. RedissonRedLock redLock = new RedissonRedLock(lock1, lock2, lock3);
  8. // 同时加锁：lock1 lock2 lock3
  9. // ReadLock在大部分节点上加锁成功就算成功，且设置总超时时间以及单个节点超时时间
  10. redLock.trylock(waitTimeout,leaseTime,TimeUnit.SECONDS);
  11. ...
  12. redLock.unlock();

Watch Dog 自动延时机制：

假设线程获取锁成功，并设置了 30 s 超时，但是在 30s 内业务逻辑还没执行完，锁就超时释放了，就会导致其他线程获取不该获取的锁。为此，Redisson 提供了 watch dog 自动延时机制，提供了一个监控锁的看门狗，它的作用是在 Redisson 实例被关闭前，不断的延长锁的有效期。也就是说，如果一个拿到锁的线程一直没有完成逻辑，那么看门狗会帮助线程不断的延长锁超时时间，锁不会因为超时而被释放。

默认情况下，看门狗的续期时间是 30s，也可以通过修改 Config.lockWatchdogTimeout 方法来指定。另外 Redisson 还提供了可以指定 leaseTime 参数的加锁方法来指定加锁的时间。超过这个时间后锁便自动解开了，也不会再延长锁的有效期。
image.png