Redis 实现分布式锁-一一网

分布式锁的解决方案非常多，常用的如 ZooKeeper ，今天讲的是如何通过 Redis 去实现分布式锁，让我们从最简单的开始，然后一步一步去完善

通过 SETNX 命令实现

SETNX 命令表示 SET if Not eXists，即如果 key 不存在，才会设置它的值，否则什么也不做。

通过这个命令我们就可以实现一个简陋的分布式锁，流程如下

客户端 1 申请加锁(其实就是添加一条 String 类型的数据)，加锁成功：

127.0.0.1:6379> SETNX lock 1
(integer) 1     // 客户端1，加锁成功
复制代码

客户端 2 申请加锁，因为它后到达，加锁失败：

127.0.0.1:6379> SETNX lock 1
(integer) 0     // 客户端2，加锁失败
复制代码

此时，加锁成功的客户端，就可以去操作「共享资源」，例如，修改 MySQL 的某一行数据，或者调用一个 API 请求。

操作完成后，还要及时释放锁，给后来者让出操作共享资源的机会。如何释放锁呢？

也很简单，直接使用 DEL 命令删除这个 key 即可：

127.0.0.1:6379> DEL lock // 释放锁
(integer) 1
复制代码

整体逻辑就是所有想操作「共享资源」的地方都去 Redis 中 SETNX 同一条数据，谁先添加成功谁就拥有分布式锁，然后就可以操作「共享资源」，操作完后在删掉该数据，释放锁

流程如下

但是，这种方式存在一个很大的问题，当客户端 1 拿到锁后，如果发生下面的场景，就会造成「死锁」：

程序处理业务逻辑异常，没及时释放锁
进程挂了，没机会释放锁
…

避免死锁

如何避免死锁？很容易想到在申请锁时，给这把锁设置一个「租期」。

在 Redis 中实现时，就是给这个 key 设置一个「过期时间」。

设置多长好呢？肯定不能过短，否则「共享资源」还没操作完，就给我释放了，这个时间主要根据你的业务耗时来定！

假设操作「共享资源」的时间不会超过 10s，那么在加锁时，给这个 key 设置 10s 过期即可：

127.0.0.1:6379> SETNX lock 1    // 加锁
(integer) 1
127.0.0.1:6379> EXPIRE lock 10  // 10s后自动过期
(integer) 1
复制代码

这样就可以保证，持有锁的客户端即使发生异常，这个锁也可以在 10s 后被「自动释放」，其它客户端依旧可以拿到锁

这样就万无一失了吗？并不一定，注意上面是两条 redis 命令，也就是说可能出现执行完第一条命令后，redis 突然挂了导致第二条命令没有执行成功的情况，这种情况下还是会发生死锁。

总之，只要这两条命令不能保证是原子操作（一起成功），就存在发生「死锁」的风险

怎么办？

在 Redis 2.6.12 版本之前，我们需要想尽办法，保证 SETNX 和 EXPIRE 原子性执行，还要考虑各种异常情况如何处理。

但在 Redis 2.6.12 之后，Redis 扩展了 SET 命令的参数，用这一条命令就可以了：

// 一条命令保证原子性执行
127.0.0.1:6379> SET lock 1 EX 10 NX
OK
复制代码

评估锁租期

上一节 避免死锁 中说道，要根据业务合理评估操作「共享资源」的时间，防止操作没有完成锁被提前释放。

但是即使我们做出了合理评估，有些情况下操作「共享资源」的时间可能还是超过了共享锁的租期，比如

程序内部发生异常
网络请求超时
…

锁被提前释放后，其他客户端就获取到锁，然后开始操作「共享资源」，假设这时候，之前的客户端操作完成了，然后释放了锁，这时，它释放的其实是其他客户端的锁。

这里面有两个问题

怎么防止释放掉其他客户端的锁
怎么避免锁被提前释放

防止释放掉其他客户端的锁

解决这个问题的重点在于如何判断锁是不是自己的？

我们可以这样做

客户端在加锁时，设置一个只有自己知道的「唯一标识」进去。

例如，可以是自己的线程 ID，也可以是一个 UUID（随机且唯一），这里我们以 UUID 举例：

// 锁的VALUE设置为UUID
127.0.0.1:6379> SET lock $uuid EX 20 NX
OK
复制代码

这里假设 20s 操作共享时间完全足够，先不考虑锁自动过期的问题。

之后，在释放锁时，要先判断这把锁是否还归自己持有，伪代码可以这么写：

// 锁是自己的，才释放
if redis.get("lock") == $uuid:
    redis.del("lock")
复制代码

这里释放锁使用的是 GET + DEL 两条命令，这时，又会遇到我们前面讲的原子性问题了。怎么办，这次 Redis 可没提供复合命令，但我们将两个命令写在 Lua 脚本里，Redis 执行 Lua 脚本的过程是原子性的

安全释放锁的 Lua 脚本如下：

// 判断锁是自己的，才释放
if redis.call("GET",KEYS[1]) == ARGV[1]
then
    return redis.call("DEL",KEYS[1])
else
    return 0
end
复制代码

我们先来小结一下，回顾一个整个过程。基于 Redis 实现的分布式锁，一个严谨的的流程如下：

加锁：SET lock_key $unique_id EX $expire_time NX
操作共享资源
释放锁：Lua 脚本，先 GET 判断锁是否归属自己，再 DEL 释放锁

现在我们还剩一个问题没解决

避免锁被提前释放

上面提到即使合理评估租期，也有概率会出现锁被提前释放的情况，怎么解决呢？

延长租期也只能减小事件发生的概率，不能彻底杜绝，而且还会导致其他客户端等待锁的时间变长

我们可以设计这样一个方案：加锁时，先设置一个过期时间，然后开启一个「守护线程」，定时去检测这个锁的失效时间，如果锁快要过期了，操作共享资源还未完成，那么就自动对锁进行「续期」，重新设置过期时间。

如果你是 Java 技术栈，幸运的是，已经有一个 Redisson 库把这些工作都封装好了

Redisson

Redisson 是一个 Java 语言实现的 Redis SDK 客户端，在使用分布式锁时，它就采用了「自动续期」的方案来避免锁过期，而这个守护线程在 Redisson 中被称作「看门狗」线程。

除此之外，这个 SDK 还封装了很多易用的功能：

可重入锁
乐观锁
公平锁
读写锁
Redlock（红锁，下面会详细讲）

这个 SDK 提供的 API 非常友好，它可以像操作本地锁的方式，操作分布式锁。

小结

基于 Redis 实现的分布式锁，可能遇到的问题，以及对应的解决方案：

死锁：设置过期时间
锁被别人释放：锁写入唯一标识，释放锁先检查标识，再释放
锁提前过期：使用守护线程，自动续期

主从集群 + 哨兵的模式下的分布式锁

上面分析的场景都是锁在「单个」Redis 实例中可能产生的问题，并没有涉及到 Redis 的部署架构细节。

哪在主从集群 + 哨兵的模式下，上面的 Redis 分布式锁会不会有问题呢？

来看下面这个场景

客户端 1 在主库上执行 SET 命令，加锁成功
此时，主库异常宕机，SET 命令还未同步到从库上（主从复制是异步的）
从库被哨兵提升为新主库，这个锁在新的主库上，丢失了！

为了解决主从切换时，锁丢失的问题，Redis 的作者提出一种叫 Redlock（红锁） 的解决方案

Redlock（红锁）

Redis 作者提出的 Redlock（红锁） 的解决方案基于 2 个前提：

只部署主库，不再需要部署从库和哨兵实例
主库要部署多个，官方推荐至少 5 个实例

也就是说，想用使用 Redlock，你至少要部署 5 个 Redis 实例，而且都是主库，它们之间没有任何关系，都是一个个互不相关的实例。

注意：不是部署 Redis Cluster，就是部署 5 个简单的 Redis 实例。

在看具体如何实现 Redlock, 整个流程如下

客户端先获取「当前时间戳 T1」
客户端依次向这 5 个 Redis 实例发起加锁请求（用前面讲到的 SET 命令），且每个请求会设置超时时间（毫秒级），如果某一个实例加锁失败（包括网络超时、锁被其它人持有等各种异常情况），就立即向下一个 Redis 实例申请加锁
如果客户端从 >=3 个（大多数）以上 Redis 实例加锁成功，则再次获取「当前时间戳 T2」，如果 T2 – T1 < 锁的过期时间，此时，认为客户端加锁成功，否则认为加锁失败
加锁成功，去操作共享资源
加锁失败，向「全部节点」发起释放锁请求（前面讲到的 Lua 脚本释放锁）

说白了就是大家都去抢注锁，谁抢注的多谁就拥有锁

这里面有几个重点