Redis实现分布式锁

Posted 2023-04-01 CSDN砖家

1、使用背景

几乎每个互联网公司中都使用了分布式部署，分布式服务下，就会遇到对同一个资源的并发访问的技术难题，如秒杀、下单减库存等场景。这些场景有一个共同特点就是访问量激增，虽然在系统设计时会通过限流、异步、排队等方式优化，但整体的并发还是平时的数倍以上，为了避免并发问题，防止库存超卖，给用户提供一个良好的购物体验，这些系统中都会用到锁的机制。

如果在分布式场景中，实现不同客户端的线程对代码和资源的同步访问，保证在多线程下处理共享数据的安全性，就需要用到分布式锁技术。

2、分布式锁是什么

分布式锁是什么？分布式锁是控制分布式系统或不同系统之间共同访问共享资源的一种锁实现，如果不同系统或同一系统不同主机之间共享了某个资源时，往往需要互斥防止干扰保证一致性。

一个相对安全的分布式锁需要具有以下几个特征：

1. 互斥性。互斥是锁的基本特征，同一时刻锁只能被一个线程持有，执行临界区操作。

2. 超时释放。通过超时释放可以避免死锁，防止不必要的等待和资源浪费。

3. 可重入性。一个线程在持有锁的情况下可以对其再次请求加锁，防止锁在线程执行完临界区操作之前释放。

4. 高性能和高可用。加锁和释放锁的过程性能开销要尽可能的低，同时也要保证高可用，防止分布式锁意外失效。

可以看出实现分布式锁，并不是锁住资源就可以了，还需要满足一些额外的特征，避免出现死锁、锁失效等问题。

3、分布式锁的实现方式

目前实现分布式锁的方式有很多，其中常见的有以下几种：

3.1 Memcached 分布式锁

利用 Memcached 的 add 命令。此命令是原子性操作，只有在 key 不存在的情况下，才能 add 成功，也就意味着线程得到了锁。

3.2 Zookeeper 分布式锁

利用 Zookeeper 的顺序临时节点，来实现分布式锁和等待队列。ZooKeeper 作为一个专门为分布式应用提供方案的框架，它提供了一些非常好的特性，如 ephemeral 类型的 znode 自动删除的功能，同时 ZooKeeper 还提供 watch 机制，可以让分布式锁在客户端用起来就像一个本地的锁一样：加锁失败就阻塞住，直到获取到锁为止。

3.3 Redis 分布式锁

基于 Redis 单机实现的分布式锁，其方式和 Memcached 的实现方式类似，利用 Redis 的 SETNX 命令，此命令同样是原子性操作，只有在 key 不存在的情况下，才能 set 成功。而基于 Redis 多机实现的分布式锁Redlock，是Redis 的作者 antirez 为了规范 Redis 分布式锁的实现，提出的一个更安全有效的实现机制。

4、Redis分布式锁

使用Redis作为分布式锁，本质上要实现的目标就是一个进程在 Redis 里面占据了仅有的一个“茅坑”，当别的进程也想来占坑时，发现已经有人蹲在那里了，就只好放弃或者等待稍后再试。

目前基于 Redis 实现分布式锁主要有两大类，一类是基于单机，另一类是基于 Redis 多机，不管是哪种实现方式，均需要实现加锁、解锁、锁超时这三个分布式锁的核心要素。

4.1 基于 Redis 单机实现的分布式锁

4.1.1 使用 SETNX 指令

最简单的加锁方式就是直接使用 Redis 的 SETNX 指令，该指令只在 key 不存在的情况下，将 key 的值设置为 value，若 key 已经存在，则 SETNX 命令不做任何动作。key 是锁的唯一标识，可以按照业务需要锁定的资源来命名。

比如在某商城的秒杀活动中对某一商品加锁，那么 key 可以设置为 lock_resource_id ，value 可以设置为任意值，在资源使用完成后，使用 DEL 删除该 key 对锁进行释放，整个过程如下：

很显然，这种获取锁的方式很简单，但也存在一个问题，就是我们上面提到的分布式锁三个核心要素之一的锁超时问题，即如果获得锁的进程在业务逻辑处理过程中出现了异常，可能会导致 DEL 指令一直无法执行，导致锁无法释放，该资源将会永远被锁住。

所以，在使用 SETNX 拿到锁以后，必须给 key 设置一个过期时间，以保证即使没有被显式释放，在获取锁达到一定时间后也要自动释放，防止资源被长时间独占。由于 SETNX 不支持设置过期时间，所以需要额外的 EXPIRE 指令，整个过程如下：

这样实现的分布式锁仍然存在一个严重的问题，由于 SETNX 和 EXPIRE 这两个操作是非原子性的， 如果进程在执行 SETNX 和 EXPIRE 之间发生异常，SETNX 执行成功，但 EXPIRE 没有执行，导致这把锁变得“长生不老”，这种情况就可能出现前文提到的锁超时问题，其他进程无法正常获取锁。

4.1.2 使用 SET 扩展指令

为了解决 SETNX 和 EXPIRE 两个操作非原子性的问题，可以使用 Redis 的 SET 指令的扩展参数，使得 SETNX 和 EXPIRE 这两个操作可以原子执行，整个过程如下：

在这个 SET 指令中：

NX 表示只有当 lock_resource_id 对应的 key 值不存在的时候才能 SET 成功。保证了只有第一个请求的客户端才能获得锁，而其它客户端在锁被释放之前都无法获得锁。

EX 10 表示这个锁10秒钟后会自动过期，业务可以根据实际情况设置这个时间的大小。

但是这种方式仍然不能彻底解决分布式锁超时问题：

锁被提前释放。假如线程 A 在加锁和释放锁之间的逻辑执行的时间过长（或者线程 A 执行过程中被堵塞），以至于超出了锁的过期时间后进行了释放，但线程 A 在临界区的逻辑还没有执行完，那么这时候线程 B 就可以提前重新获取这把锁，导致临界区代码不能严格的串行执行。

锁被误删。假如以上情形中的线程A执行完后，它并不知道此时的锁持有者是线程 B，线程A会继续执行 DEL 指令来释放锁，如果线程 B 在临界区的逻辑还没有执行完，线程 A 实际上释放了线程 B 的锁。

为了避免以上情况，建议不要在执行时间过长的场景中使用 Redis 分布式锁，同时一个比较安全的做法是在执行 DEL 释放锁之前对锁进行判断，验证当前锁的持有者是否是自己。

具体实现就是在加锁时将 value 设置为一个唯一的随机数（或者线程 ID ），释放锁时先判断随机数是否一致，然后再执行释放操作，确保不会错误地释放其它线程持有的锁，除非是锁过期了被服务器自动释放，整个过程如下：

但判断 value 和删除 key 是两个独立的操作，并不是原子性的，所以这个地方需要使用 Lua 脚本进行处理，因为 Lua 脚本可以保证连续多个指令的原子性执行。

基于 Redis 单节点的分布式锁基本完成了，但是这并不是一个完美的方案，只是相对完全一点，因为它并没有完全解决当前线程执行超时锁被提前释放后，其它线程乘虚而入的问题。

4.1.3 使用 Redisson 的分布式锁

怎么能解决锁被提前释放这个问题呢？

可以利用锁的可重入特性，让获得锁的线程开启一个定时器的守护线程，每 expireTime/3 执行一次，去检查该线程的锁是否存在，如果存在则对锁的过期时间重新设置为 expireTime，即利用守护线程对锁进行“续命”，防止锁由于过期提前释放。

当然业务要实现这个守护进程的逻辑还是比较复杂的，可能还会出现一些未知的问题。

目前互联网公司在生产环境用的比较广泛的开源框架 Redisson 很好地解决了这个问题，非常的简便易用，且支持 Redis 单实例、Redis M-S、Redis Sentinel、Redis Cluster 等多种部署架构。

感兴趣的朋友可以查阅下官方文档或者源码：https://github.com/redisson/redisson/wiki

其实现原理如图所示（图中以 Redis 集群为例）：

4.2 基于 Redis 多机实现的分布式锁 Redlock

以上几种基于 Redis 单机实现的分布式锁其实都存在一个问题，就是加锁时只作用在一个 Redis 节点上，即使 Redis 通过 Sentinel 保证了高可用，但由于 Redis 的复制是异步的，Master 节点获取到锁后在未完成数据同步的情况下发生故障转移，此时其他客户端上的线程依然可以获取到锁，因此会丧失锁的安全性。

整个过程如下：

客户端 A 从 Master 节点获取锁。

Master 节点出现故障，主从复制过程中，锁对应的 key 没有同步到 Slave 节点。

Slave升 级为 Master 节点，但此时的 Master 中没有锁数据。

客户端 B 请求新的 Master 节点，并获取到了对应同一个资源的锁。

出现多个客户端同时持有同一个资源的锁，不满足锁的互斥性。

正因为如此，在 Redis 的分布式环境中，Redis 的作者 antirez 提供了 RedLock 的算法来实现一个分布式锁，该算法大概是这样的：

假设有 N（N>=5）个 Redis 节点，这些节点完全互相独立，不存在主从复制或者其他集群协调机制，确保在这 N 个节点上使用与在 Redis 单实例下相同的方法获取和释放锁。

获取锁的过程，客户端应执行如下操作：

获取当前 Unix 时间，以毫秒为单位。

按顺序依次尝试从5个实例使用相同的 key 和具有唯一性的 value（例如 UUID）获取锁。当向 Redis 请求获取锁时，客户端应该设置一个网络连接和响应超时时间，这个超时时间应该小于锁的失效时间。例如锁自动失效时间为10秒，则超时时间应该在5-50毫秒之间。这样可以避免服务器端 Redis 已经挂掉的情况下，客户端还在一直等待响应结果。如果服务器端没有在规定时间内响应，客户端应该尽快尝试去另外一个 Redis 实例请求获取锁。

客户端使用当前时间减去开始获取锁时间（步骤1记录的时间）就得到获取锁使用的时间。当且仅当从大多数（N/2+1，这里是3个节点）的 Redis 节点都取到锁，并且使用的时间小于锁失效时间时，锁才算获取成功。

如果取到了锁，key 的真正有效时间等于有效时间减去获取锁所使用的时间（步骤3计算的结果）。

如果因为某些原因，获取锁失败（没有在至少N/2+1个 Redis 实例取到锁或者取锁时间已经超过了有效时间），客户端应该在所有的 Redis 实例上进行解锁（使用 Redis Lua 脚本）。

释放锁的过程相对比较简单：客户端向所有 Redis 节点发起释放锁的操作，包括加锁失败的节点，也需要执行释放锁的操作，antirez 在算法描述中特别强调这一点，这是为什么呢？

原因是可能存在某个节点加锁成功后返回客户端的响应包丢失了，这种情况在异步通信模型中是有可能发生的：客户端向服务器通信是正常的，但反方向却是有问题的。虽然对客户端而言，由于响应超时导致加锁失败，但是对 Redis 节点而言，SET 指令执行成功，意味着加锁成功。因此，释放锁的时候，客户端也应该对当时获取锁失败的那些 Redis 节点同样发起请求。

除此之外，为了避免 Redis 节点发生崩溃重启后造成锁丢失，从而影响锁的安全性，antirez 还提出了延时重启的概念，即一个节点崩溃后不要立即重启，而是等待一段时间后再进行重启，这段时间应该大于锁的有效时间。

关于 Redlock 的更深层次的学习，感兴趣的朋友可以查阅下官方文档，https://redis.io/topics/distlock

5、总结

分布式系统设计是实现复杂性和收益的平衡，既要尽可能地安全可靠，也要避免过度设计。Redlock 确实能够提供更安全的分布式锁，但也是有代价的，需要更多的 Redis 节点。在实际业务中，一般使用基于单点的 Redis 实现分布式锁就可以满足绝大部分的需求，偶尔出现数据不一致的情况，可通过人工介入回补数据进行解决，正所谓“技术不够，人工来凑”！

大厂面试题详解：如何用Redis实现分布式锁？

参考技术A 说一道常见面试题：

一个很简单的答案就是去使用 Redission 客户端。Redission 中的锁方案就是 Redis 分布式锁得比较完美的详细方案。

那么，Redission 中的锁方案为什么会比较完美呢？

正好，我用 Redis 做分布式锁经验十分丰富，在实际工作中，也 探索 过许多种使用 Redis 做分布式锁的方案，经过了无数血泪教训。

所以，在谈及 Redission 锁为什么比较完美之前，先给大家看看我曾经使用 Redis 做分布式锁是遇到过的问题。

我曾经用 Redis 做分布式锁是想去解决一个用户抢优惠券的问题。这个业务需求是这样的：当用户领完一张优惠券后，优惠券的数量必须相应减一，如果优惠券抢光了，就不允许用户再抢了。

在实现时，先从数据库中先读出优惠券的数量进行判断，当优惠券大于 0，就进行允许领取优惠券，然后，再将优惠券数量减一后，写回数据库。

当时由于请求数量比较多，所以，我们使用了三台服务器去做分流。

这个时候会出现一个问题：

如果其中一台服务器上的 A 应用获取到了优惠券的数量之后，由于处理相关业务逻辑，未及时更新数据库的优惠券数量；在 A 应用处理业务逻辑的时候，另一台服务器上的 B 应用更新了优惠券数量。那么，等 A 应用去更新数据库中优惠券数量时，就会把 B 应用更新的优惠券数量覆盖掉。

看到这里，可能有人比较奇怪，为什么这里不直接使用 SQL：

原因是这样做，在没有分布式锁的协调下，优惠券数量可能直接会出现负数。因为当前优惠券数量为 1 的时候，如果两个用户通过两台服务器同时发起抢优惠券的请求，都满足优惠券大于 0 每个条件，然后都执行这条 SQL 说了句，结果优惠券数量直接变成 -1 了。

还有人说可以用乐观锁，比如使用如下 SQL:

这种方式就在一定几率下，很可能出现数据一直更新不上，导致长时间重试的情况。

所以，经过综合考虑，我们就采用了 Redis 分布式锁，通过互斥的方式，以防止多个客户端同时更新优惠券数量的方案。

当时，我们首先想到的就是使用 Redis 的 setnx 命令，setnx 命令其实就是 set if not exists 的简写。

当 key 设置值成功后，则返回 1，否则就返回 0。所以，这里 setnx 设置成功可以表示成获取到锁，如果失败，则说明已经有锁，可以被视作获取锁失败。

如果想要释放锁，执行任务 del 指令，把 key 删除即可。

利用这个特性，我们就可以让系统在执行优惠券逻辑之前，先去 Redis 中执行 setnx 指令。再根据指令执行结果，去判断是否获取到锁。如果获取到了，就继续执行业务，执行完再使用 del 指令去释放锁。如果没有获取到，就等待一定时间，重新再去获取锁。

乍一看，这一切没什么问题，使用 setnx 指令确实起到了想要的互斥效果。

但是，这是建立在所有运行环境都是正常的情况下的。一旦运行环境出现了异常，问题就出现了。

想一下，持有锁的应用突然崩溃了，或者所在的服务器宕机了，会出现什么情况？

这会造成死锁——持有锁的应用无法释放锁，其他应用根本也没有机会再去获取锁了。这会造成巨大的线上事故，我们要改进方案，解决这个问题。

怎么解决呢？咱们可以看到，造成死锁的根源是，一旦持有锁的应用出现问题，就不会去释放锁。从这个方向思考，可以在 Redis 上给 key 一个过期时间。

这样的话，即使出现问题，key 也会在一段时间后释放，是不是就解决了这个问题呢？实际上，大家也确实是这么做的。

不过，由于 setnx 这个指令本身无法设置超时时间，所以一般会采用两种办法来做这件事：

1、采用 lua 脚本，在使用 setnx 指令之后，再使用 expire 命令去给 key 设置过期时间。

2、直接使用 set(key,value,NX,EX,timeout) 指令，同时设置锁和超时时间。

以上两种方法，使用哪种方式都可以。

释放锁的脚本两种方式都一样，直接调用 Redis 的 del 指令即可。

到目前为止，我们的锁既起到了互斥效果，又不会因为某些持有锁的系统出现问题，导致死锁了。这样就完美了吗？

假设有这样一种情况，如果一个持有锁的应用，其持有的时间超过了我们设定的超时时间会怎样呢？会出现两种情况：

出现第一种情况比较正常。因为你毕竟执行任务超时了，key 被正常清除也是符合逻辑的。

但是最可怕的是第二种情况，发现设置的 key 还存在。这说明什么？说明当前存在的 key，是另外的应用设置的。

这时候如果持有锁超时的应用调用 del 指令去删除锁时，就会把别人设置的锁误删除，这会直接导致系统业务出现问题。

所以，为了解决这个问题，我们需要继续对 Redis 脚本进行改动……毁灭吧，累了……

首先，我们要让应用在获取锁的时候，去设置一个只有应用自己知道的独一无二的值。

通过这个唯一值，系统在释放锁的时候，就能识别出这锁是不是自己设置的。如果是自己设置的，就释放锁，也就是删除 key；如果不是，则什么都不做。

脚本如下：

或者

这里，ARGV[1] 是一个可传入的参数变量，可以传入唯一值。比如一个只有自己知道的 UUID 的值，或者通过雪球算法，生成只有自己持有的唯一 ID。

释放锁的脚本改成这样：

可以看到，从业务角度，无论如何，我们的分布式锁已经可以满足真正的业务需求了。能互斥，不死锁，不会误删除别人的锁，只有自己上的锁，自己可以释放。

一切都是那么美好！！！

可惜，还有个隐患，我们并未排除。这个隐患就是 Redis 自身。

要知道，lua 脚本都是用在 Redis 的单例上的。一旦 Redis 本身出现了问题，我们的分布式锁就没法用了，分布式锁没法用，对业务的正常运行会造成重大影响，这是我们无法接受的。

所以，我们需要把 Redis 搞成高可用的。一般来讲，解决 Redis 高可用的问题，都是使用主从集群。

但是搞主从集群，又会引入新的问题。主要问题在于，Redis 的主从数据同步有延迟。这种延迟会产生一个边界条件：当主机上的 Redis 已经被人建好了锁，但是锁数据还未同步到从机时，主机宕了。随后，从机提升为主机，此时从机上是没有以前主机设置好的锁数据的——锁丢了……丢了……了……

到这里，终于可以介绍 Redission（开源 Redis 客户端）了，我们来看看它怎么是实现 Redis 分布式锁的。

Redission 实现分布式锁的思想很简单，无论是主从集群还是 Redis Cluster 集群，它会对集群中的每个 Redis，挨个去执行设置 Redis 锁的脚本，也就是集群中的每个 Redis 都会包含设置好的锁数据。

我们通过一个例子来介绍一下。

假设 Redis 集群有 5 台机器，同时根据评估，锁的超时时间设置成 10 秒比较合适。

第 1 步，咱们先算出集群总的等待时间，集群总的等待时间是 5 秒（锁的超时时间 10 秒 / 2）。

第 2 步，用 5 秒除以 5 台机器数量，结果是 1 秒。这个 1 秒是连接每台 Redis 可接受的等待时间。

第 3 步，依次连接 5 台 Redis，并执行 lua 脚本设置锁，然后再做判断：

再额外多说一句，在很多业务逻辑里，其实对锁的超时时间是没有需求的。

比如，凌晨批量执行处理的任务，可能需要分布式锁保证任务不会被重复执行。此时，任务要执行多长时间是不明确的。如果设置分布式锁的超时时间在这里，并没有太大意义。但是，不设置超时时间，又会引发死锁问题。

所以，解决这种问题的通用办法是，每个持有锁的客户端都启动一个后台线程，通过执行特定的 lua 脚本，去不断地刷新 Redis 中的 key 超时时间，使得在任务执行完成前，key 不会被清除掉。

脚本如下：

其中，ARGV[1] 是可传入的参数变量，表示持有锁的系统的唯一值，也就是只有持有锁的客户端才能刷新 key 的超时时间。

到此为止，一个完整的分布式锁才算实现完毕。总结实现方案如下：

这个分布式锁满足如下四个条件：

当然，在 Redission 中的脚本，为了保证锁的可重入，又对 lua 脚本做了一定的修改，现在把完整的 lua 脚本贴在下面。

获取锁的 lua 脚本：

对应的刷新锁超时时间的脚本：

对应的释放锁的脚本：

到现在为止，使用 Redis 作为分布式锁的详细方案就写完了。

我既写了一步一坑的坎坷经历，也写明了各个问题和解决问题的细节，希望大家看完能有所收获。

最后再给大家提个醒，使用 Redis 集群做分布式锁，有一定的争议性，还需要大家在实际用的时候，根据现实情况，做出更好的选择和取舍。

原文 https://www.cnblogs.com/siyuanwai/p/16011836.html