在 Java 中利用 redis 实现一个分布式锁服务

Posted 2021-05-01 猿助猿

在现代的编程语言中，接触过多线程编程的程序员多多少少对锁有一定的了解。简单的说，多线程中的锁就是在多线程环境下，多个线程对共享资源进行修改的时候，保证共享资源一致性的机制。

在分布式环境下，原来的多线程的锁就不管用了，也就出现了分布式锁的需求。所谓分布式锁服务也就是在分布式环境下，保证多个分布式的服务共享的资源一致性的服务。

在分布式环境下实现一个分布式锁服务并不太容易，需要考虑很多在单进程下的锁服务不需要考虑的问题。分布式锁锁的实现也有很多。

这里我们讨论在 Java 中通过 redis 来实现。在 GitHub 中的 redisson 项目中已经有开源的实现。但是那个太复杂了。现在我们来基于单机的 redis 实现一个简单的分布式锁服务。

这个服务必须满足下面的要求

1. 支持立即获取锁方式，如果获取到返回true，获取不到则返回false；

2. 支持等待获取锁方式，如果获取到，直接返回true，获取不到在等待一小段时间，在这一小段时间内反复尝试，如果尝试成功，则返回true，等待时间过后还获取不到则返回false；

3. 不能产生死锁的情况；

4. 不能释放非自己加的锁；

下面我们用实例来演示在 Java 中利用 redis 实现分布式锁服务

##加锁

通过 redis 来实现分布式锁的加锁逻辑如下所示：

根据这个逻辑，实现上锁的核心代码如下所示：

表面上看这段代码好像没有什么问题，实际上并不能在分布式环境中正确的实现加锁的操作。要能够正确的实现加锁操作，“判断 key 是否存在”、“保存 key-value”、**“设置 key 的过期时间”**这三步操作必须是原子操作。如果不是原子操作，那么可能会出现下面两种情况：

1. 在**“判断 key 是否存在”得出 key 不存在的结果步骤后，“保存 key-value”步骤前，另一个客户端执行同样的逻辑，并且执行到了“判断 key 是否存在”**步骤，同样得出了 key 不存在的结果。这样回导致多个客户端获得了同一把锁；

2. 在客户端执行完**“保存 key-value”** 步骤后，需要设置一个 key 的过期时间，防止客户端因为代码质量未解锁，在或者进程崩溃未解锁导致的死锁情况。在**“保存 key-value”步骤之后，“设置 key 的过期时间”步骤之前，可能进程崩溃，导致“设置 key 的过期时间”**步骤失败；

redis 在2.6.12版本之后，对 set 命令进行了扩充，能够规避上面的两个问题。新版的 redis set 命令的参数如下

新版的 set 命令增加了 EX 、 PX 、 NX|XX 参数选项。他们的含义如下

EX seconds – 设置键 key 的过期时间，单位时秒 PX milliseconds – 设置键 key 的过期时间，单位时毫秒 NX – 只有键 key 不存在的时候才会设置 key 的值 XX – 只有键 key 存在的时候才会设置 key 的值

这样，原来的三步操作就可以在一个 set 的原子操作里面来完成，规避了上面我们提到的两个问题。新版的 redis 加锁核心代码修改如下所示：

##解锁 解锁的基本流程如下：

根据这个逻辑，在 Java 中解锁的核心代码如下所示：

和加锁的时候一样，key 是否存在、判断是否自己持有锁、**删除 key-value **这三步操作需要是原子操作，否则当一个客户端执行完“判断是否自己持有锁”步骤后，得出自己持有锁的结论，此时锁的过期时间到了，自动被 redis 释放了，同时另一个客户端又基于这个 key 加锁成功，如果第一个客户端还继续执行删除 key-value的操作，就将不属于自己的锁给释放了。这显然是不运行的。在这里我们利用 redis 执行 Lua 脚本的能力来解决原子操作的问题。修改后的解锁核心代码如下所示：

另外，判断是否自己持有锁的机制是用加锁的时候的 key-value 来判断当前的 key 的值是否等于自己持有锁时获得的值。所以加锁的时候的 value 必须是一个全局唯一的字符串。

##完整的代码如下所示

##测试代码

测试结果

从测试结果来看可以看到，9个线程同时给一个 key 加锁，只有一个能够成功获取到锁，其余的客户端都无法获取到锁。

 这个代码里面还实现了一个 tryLock 的接口。这个主要是客户端无法获取到锁的时候会在一小段时间内反复尝试是否能够获取到锁。

觉得本文有帮助？请分享给更多人