30 | 如何使用Redis实现分布式锁？

久违の欢喜

已于 2022-08-25 19:48:30 修改

阅读量169

点赞数 1

分类专栏：《Redis核心技术与实战》学习笔记文章标签： redis 分布式锁 Redlock Redisson

于 2021-12-20 16:00:12 首次发布

本文链接：https://blog.csdn.net/TQ20160412/article/details/122040964

版权

《Redis核心技术与实战》学习笔记专栏收录该内容

34 篇文章 11 订阅

订阅专栏

文章目录

Redis核心技术与实战
- 实践篇
- - 30 | 如何使用Redis实现分布式锁？

Redis核心技术与实战

实践篇

30 | 如何使用Redis实现分布式锁？

Redis 属于分布式系统，当有多个客户端需要争抢锁时，必须要保证这把锁不能是某个客户端本地的锁。否则的话，其它客户端无法访问这把锁，当然也就不能获取这把锁。

在分布式系统中，当有多个客户端需要获取锁时，需要分布式锁。此时，锁保存在一个共享存储系统中，可以被多个客户端共享访问和获取。

Redis 本身可以被多个客户端共享访问，正好就是一个共享存储系统，可以用来保存分布式锁。而且 Redis 的读写性能高，可以应对高并发的锁操作场景。

单机上的锁和分布式锁的联系与区别

对于在单机上运行的多线程程序来说，锁本身可以用一个变量表示。

变量值为 0 时，表示没有线程获取锁；
变量值为 1 时，表示已经有线程获取到锁。

一个线程调用加锁操作，其实就是检查锁变量值是否为 0。如果是 0，就把锁的变量值设置为 1，表示获取到锁，如果不是 0，就返回错误信息，表示加锁失败，已经有别的线程获取到锁。而一个线程调用释放锁操作，其实就是将锁变量的值置为 0，以便其它线程可以来获取锁。

和单机上的锁类似，分布式锁同样可以用一个变量来实现。客户端加锁和释放锁的操作逻辑，也和单机上的加锁和释放锁操作逻辑一致：加锁时同样需要判断锁变量的值，根据锁变量值来判断能否加锁成功；释放锁时需要把锁变量值设置为 0，表明客户端不再持有锁。

但是，和线程在单机上操作锁不同的是，在分布式场景下，锁变量需要由一个共享存储系统来维护，多个客户端才可以通过访问共享存储系统来访问锁变量。 相应的，加锁和释放锁的操作就变成了读取、判断和设置共享存储系统中的锁变量值。

实现分布式锁的两个要求：

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

基于单个 Redis 节点实现分布式锁

作为分布式锁实现过程中的共享存储系统，Redis 可以使用键值对来保存锁变量，再接收和处理不同客户端发送的加锁和释放锁的操作请求。

在这里插入图片描述

因为加锁包含了三个操作（读取锁变量、判断锁变量值以及把锁变量值设置为 1），而这三个操作在执行时需要保证原子性。

要想保证操作的原子性，有两种通用的方法，分别是使用 Redis 的单命令操作和使用 Lua 脚本。

Redis 实现加锁操作的单命令：

SETNX 命令，它用于设置键值对的值。 具体来说，就是这个命令在执行时会判断键值对是否存在，如果不存在，就设置键值对的值，如果存在，就不做任何设置。
对于释放锁的操作，可以在执行完业务逻辑后，使用 DEL 命令删除锁变量。

使用 SETNX 和 DEL 命令组合实现分布锁，存在两个潜在的风险：

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

一个有效的解决方法是，给锁变量设置一个过期时间。这样，即使持有锁的客户端发生异常，无法主动地释放锁，Redis 也会根据锁变量的过期时间，在锁变量过期后，把它删除。其它客户端在锁变量过期后，就可以重新请求加锁，就不会出现无法加锁的问题。

疑问：锁过期时间不好评估怎么办？

客户端在拿到锁之后，在操作共享资源时，遇到的场景有可能很复杂，例如，程序内部发生异常、网络请求超时等等。

解决方案：

加锁时，先设置一个过期时间，然后开启一个守护线程，定时去检测这个锁的失效时间，如果锁快要过期了，而操作共享资源还未完成，则自动对锁进行续期，重新设置过期时间。

Redisson 是一个 Java 语言实现的 Redis SDK 客户端，在使用分布式锁时，采用了自动续期的方案来避免锁过期，这个守护线程一般也把它叫做看门狗线程。

在这里插入图片描述

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

解决方案：

区分来自不同客户端的锁操作。在使用 SETNX 命令进行加锁的方法中，通过把锁变量值设置为 1 或 0，表示是否加锁成功。1 和 0 只有两种状态，无法表示究竟是哪个客户端进行的锁操作。所以，在加锁操作时，可以让每个客户端给锁变量设置一个唯一值，用来标识当前操作的客户端。在释放锁操作时，客户端需要判断，当前锁变量的值是否和自己的唯一标识相等，只有在相等的情况下，才能释放锁。这样，就不会出现误释放锁的问题。

为了能达到和 SETNX 命令一样的效果，，Redis 给 SET 命令提供了类似的选项 NX，用来实现“不存在即设置”。如果使用 NX 选项，SET 命令只有在键值对不存在时，才会进行设置，否则不做赋值操作。此外，SET 命令在执行时还可以带上 EX 或 PX 选项，用来设置键值对的过期时间。

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

// 加锁, unique_value作为客户端唯一性的标识
SET lock_key unique_value NX PX 10000

在释放锁操作时，需要判断锁变量的值，是否等于执行释放锁操作的客户端的唯一标识，如下所示：

# 使用 Lua 脚本（unlock.script）实现的释放锁操作的伪代码
//释放锁 比较 unique_value 是否相等，避免误释放
if redis.call("get",KEYS[1]) == ARGV[1] then
    return redis.call("del",KEYS[1])
else
    return 0
end

释放锁操作的逻辑包含读取锁变量、判断值、删除锁变量的多个操作，而 Redis 在执行 Lua 脚本时，可以以原子性的方式执行，从而保证锁释放操作的原子性。

最后，执行下面的命令，就可以完成锁释放操作。

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

基于多个 Redis 节点实现高可靠的分布式锁

为了避免 Redis 实例故障而导致的锁无法工作的问题，Redis 的开发者 Antirez 提出了分布式锁算法 Redlock。

Redlock 算法的基本思路

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

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

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

如果某个 Redis 实例发生故障，为了保证在这种情况下，Redlock 算法能够继续运行，需要给加锁操作设置一个超时时间。如果客户端在和一个 Redis 实例请求加锁时，一直到超时都没有成功，那么此时，客户端会和下一个 Redis 实例继续请求加锁。加锁操作的超时时间需要远远地小于锁的有效时间，一般也就是设置为几十毫秒。

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