Redisson 分布式锁实现分析（一）

Why 分布式锁

java.util.concurrent.locks 中包含了 JDK 提供的在多线程情况下对共享资源的访问控制的一系列工具，它们可以帮助我们解决进程内多线程并发时的数据一致性问题。

但是在分布式系统中，JDK 原生的并发锁工具在一些场景就无法满足我们的要求了，这就是为什么要使用分布式锁。我总结了一句话，分布式锁是用于解决分布式系统中操作共享资源时的数据一致性问题。

设计分布式锁要注意的问题

互斥

分布式系统中运行着多个节点，必须确保在同一时刻只能有一个节点的一个线程获得锁，这是最基本的一点。

死锁

分布式系统中，可能产生死锁的情况要相对复杂一些。分布式系统是处在复杂网络环境中的，当一个节点获取到锁，如果它在释放锁之前挂掉了，或者因网络故障无法执行释放锁的命令，都会导致其他节点无法申请到锁。

因此分布式锁有必要设置时效，确保在未来的一定时间内，无论获得锁的节点发生了什么问题，最终锁都能被释放掉。

性能

对于访问量大的共享资源，如果针对其获取锁时造成长时间的等待，导致大量节点阻塞，是绝对不能接受的。

所以设计分布式锁时要能够掌握锁持有者的动态，若判断锁持有者处于不活动状态，要能够强制释放其持有的锁。
此外，排队等待锁的节点如果不知道锁何时会被释放，则只能隔一段时间尝试获取一次锁，这样无法保证资源的高效利用，因此当锁释放时，要能够通知等待队列，使一个等待节点能够立刻获得锁。

重入

考虑到一些应用场景和资源的高效利用，锁要设计成可重入的，就像 JDK 中的 ReentrantLock 一样，同一个线程可以重复拿到同一个资源的锁。

RedissonLock 实现解读

本文中 Redisson 的代码版本为 2.2.17-SNAPSHOT。

这里以 lock() 方法为例，其他一系列方法与其核心实现基本一致。

先来看 lock() 的基本用法

1. 通过 RedissonClient 的 getLock() 方法取得一个 RLock 实例。

2. lock() 方法尝试获取锁，如果成功获得锁，则继续往下执行，否则等待锁被释放，然后再继续尝试获取锁，直到成功获得锁。

3. unlock() 方法释放获得的锁，并通知等待的节点锁已释放。

下面来看看 RedissonLock 的具体实现

org.redisson.Redisson#getLock()

这里的 RLock 是继承自 java.util.concurrent.locks.Lock 的一个 interface，getLock 返回的实际上是其实现类 RedissonLock 的实例。

来看看构造 RedissonLock 的参数

• commandExecutor: 与 Redis 节点通信并发送指令的真正实现。需要说明一下，Redisson 缺省的 CommandExecutor 实现是通过 eval 命令来执行 Lua 脚本，所以要求 Redis 的版本必须为 2.6 或以上，否则你可能要自己来实现CommandExecutor。关于 Redisson 的 CommandExecutor 以后会专门解读，所以本次就不多说了。

• name: 锁的全局名称，例如上面代码中的 "foobar"，具体业务中通常可能使用共享资源的唯一标识作为该名称。

• id: Redisson 客户端唯一标识，实际上就是一个 UUID.randomUUID()。

org.redisson.RedissonLock#lock()

此处略过前面几个方法的层层调用，直接看最核心部分的方法 lockInterruptibly()，该方法在 RLock 中声明，支持对获取锁的线程进行中断操作。在直接使用 lock() 方法获取锁时，最后实际执行的是 lockInterruptibly(-1, null)。

1. 首先尝试获取锁，具体代码下面再看，返回结果是已存在的锁的剩余存活时间，为 null 则说明没有已存在的锁并成功获得锁。

2. 如果获得锁则结束流程，回去执行业务逻辑。

3. 如果没有获得锁，则需等待锁被释放，并通过 Redis 的 channel 订阅锁释放的消息，这里的具体实现本文也不深入，只是简单提一下 Redisson 在执行 Redis 命令时提供了同步和异步的两种实现，但实际上同步的实现都是基于异步的，具体做法是使用 Netty 中的异步工具 Future 和 FutureListener 结合 JDK 中的CountDownLatch 一起实现。

4. 订阅锁的释放消息成功后，进入一个不断重试获取锁的循环，循环中每次都先试着获取锁，并得到已存在的锁的剩余存活时间。

5. 如果在重试中拿到了锁，则结束循环，跳过第 6 步。

6. 如果锁当前是被占用的，那么等待释放锁的消息，具体实现使用了 JDK 并发的信号量工具 Semaphore 来阻塞线程，当锁释放并发布释放锁的消息后，信号量的 release() 方法会被调用，此时被信号量阻塞的等待队列中的一个线程就可以继续尝试获取锁了。

7. 在成功获得锁后，就没必要继续订阅锁的释放消息了，因此要取消对 Redis 上相应channel 的订阅。

下面着重看看 tryAcquire() 方法的实现，

1. 上面说过 Redisson 实现的执行 Redis 命令都是异步的，但是它在异步的基础上提供了以同步的方式获得执行结果的封装。

2. 前面提到分布式锁要确保未来的一段时间内锁一定能够被释放，因此要对锁设置超时释放的时间，在我们没有指定该时间的情况下，Redisson 默认指定为30秒。

3. 在成功获取到锁的情况下，为了避免业务中对共享资源的操作还未完成，锁就被释放掉了，需要定期（锁失效时间的三分之一）刷新锁失效的时间，这里 Redisson 使用了 Netty 的 TimerTask、Timeout 工具来实现该任务调度。

4. 获取锁真正执行的命令，Redisson 使用 EVAL 命令执行上面的 Lua 脚本来完成获取锁的操作：

   1. 如果通过 exists 命令发现当前 key 不存在，即锁没被占用，则执行 hset写入 Hash 类型数据 key:全局锁名称（例如共享资源ID）, field:锁实例名称（Redisson客户端ID:线程ID）, value:1，并执行 pexpire 对该 key 设置失效时间，返回空值 nil，至此获取锁成功。

   2. 如果通过 hexists 命令发现 Redis 中已经存在当前 key 和 field 的 Hash 数据，说明当前线程之前已经获取到锁，因为这里的锁是可重入的，则执行 hincrby 对当前 key field 的值加一，并重新设置失效时间，返回空值，至此重入获取锁成功。

   3. 最后是锁已被占用的情况，即当前 key 已经存在，但是 Hash 中的 Field 与当前值不同，则执行 pttl 获取锁的剩余存活时间并返回，至此获取锁失败。

以上就是对 lock() 的解读，不过在实际业务中我们可能还会经常使用 tryLock()，虽然两者有一定差别，但核心部分的实现都是相同的，另外还有其他一些方法可以支持更多自定义参数，本文中就不一一详述了。

org.redisson.RedissonLock#unlock()

最后来看锁的释放，

1. 使用 EVAL 命令执行 Lua 脚本来释放锁：

   1. key 不存在，说明锁已释放，直接执行 publish 命令发布释放锁消息并返回 1。

   2. key 存在，但是 field 在 Hash 中不存在，说明自己不是锁持有者，无权释放锁，返回 nil。

   3. 因为锁可重入，所以释放锁时不能把所有已获取的锁全都释放掉，一次只能释放一把锁，因此执行 hincrby 对锁的值减一。

   4. 释放一把锁后，如果还有剩余的锁，则刷新锁的失效时间并返回 0；如果刚才释放的已经是最后一把锁，则执行 del 命令删除锁的 key，并发布锁释放消息，返回 1。

2. 上面执行结果返回 nil 的情况（即第2中情况），因为自己不是锁的持有者，不允许释放别人的锁，故抛出异常。

3. 执行结果返回 1 的情况，该锁的所有实例都已全部释放，所以不需要再刷新锁的失效时间。

总结

写了这么多，其实最主要的就是上面的两段 Lua 脚本，基于 Redis 的分布式锁的设计完全体现在其中，看完这两段脚本，再回顾一下前面的 设计分布式锁要注意的问题 就豁然开朗了。

原文：https://mp.weixin.qq.com/s/Bmgptbc7QyGIk5_CKh0lBA