【求锤得锤的故事】Redis锁从面试连环炮聊到神仙打架

背景铺垫
面试的时候，不管你的简历写没写 Redis，它基本上是一个绕不过的话题。
为了引出本文要讨论的关于 Redlock 的神仙打架的问题，我们就得先通过一个面试连环炮：

Redis 做分布式锁的时候有需要注意的问题？

如果是 Redis 是单点部署的，会带来什么问题？

那你准备怎么解决单点问题呢？

集群模式下，比如主从模式，有没有什么问题呢？

你知道 Redis 是怎么解决集群模式也不靠谱的问题的吗？

那你简单的介绍一下 Redlock 吧？

你觉得 Redlock 有什么问题呢？

很明显，上面是一个常规的面试连环套路题。中间还可以插入很多其他的 Redis 的考察点，我这里就不做扩展了。

单点的 Redis 做分布式锁不靠谱，导致了基于 Redis 集群模式的分布式锁解决方案的出现。

基于 Redis 集群模式的分布式锁解决方案还是不靠谱，Redis 的作者提出了 Redlock 的解决方案。

Redis 作者提出的 Redlock 的解决方案，另一位分布式系统的大神觉得它不靠谱，于是他们之间开始了 battle。

基于这场 battle，又引发了更多的讨论。

这场 battle 难分伯仲，没有最后的赢家。如果一定要选出谁是最大的赢家的话，那一定是吃瓜网友。因为对于吃瓜网友来说（比如我），可以从两位大神的交锋中学习到很多东西。

让你深刻的体会到：看起来那么无懈可击的想法，细细推敲之下，并不是那么天衣无缝。

所以本文就按照下面的五个模块展开讲述。

单点Redis
按照我的经验，当面试聊到 Redis 的时候，百分之 90 的朋友都会说：Redis在我们的项目中是用来做热点数据缓存的。

然后百分之百的面试官都会问：

Redis除了拿来做缓存，你还见过基于Redis的什么用法？

接下来百分之 80 的朋友都会说到：我们还用 Redis 做过分布式锁。

（当然， Redis 除了缓存、分布式锁之外还有非常非常多的奇技淫巧，不是本文重点，大家有兴趣的可以自己去了解一下。）

那么面试官就会接着说：

那你给我描述（或者写一下伪代码）基于Redis的加锁和释放锁的细节吧。
注意面试官这里说的是加锁和释放锁的细节，魔鬼都在细节里。

问这个问题面试官无非是想要听到下面几个关键点：

关键点一：原子命令加锁。因为有的“年久失修”的文章中对于 Redis 的加锁操作是先set key，再设置 key 的过期时间。这样写的根本原因是在早期的 Redis 版本中并不支持原子命令加锁的操作。不是原子操作会带来什么问题，就不用我说了吧？如果你不知道，你先回去等通知吧。

而在 2.6.12 版本后，可以通过向 Redis 发送下面的命令，实现原子性的加锁操作：

SET key random_value NX PX 30000

关键点二：设置值的时候，放的是random_value。而不是你随便扔个“OK”进去。

先解释一下上面的命令中的几个参数的含义：

random_value：是由客户端生成的一个随机字符串，它要保证在足够长的一段时间内在所有客户端的所有获取锁的请求中都是唯一的。

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

PX 30000：表示这个锁有一个 30 秒的自动过期时间。当然，这里 30 秒只是一个例子，客户端可以选择合适的过期时间。

再解释一下为什么 value 需要设置为一个随机字符串。这也是第三个关键点。

关键点三：value 的值设置为随机数主要是为了更安全的释放锁，释放锁的时候需要检查 key 是否存在，且 key 对应的值是否和我指定的值一样，是一样的才能释放锁。所以可以看到这里有获取、判断、删除三个操作，为了保障原子性，我们需要用 lua 脚本。

集群模式
面试官就会接着问了：

经过刚刚的讨论，我们已经有较好的方法获取锁和释放锁。基于Redis单实例，假设这个单实例总是可用，这种方法已经足够安全。如果这个Redis节点挂掉了呢？
为了避免节点挂掉导致的问题，我们可以采用Redis集群的方法来实现Redis的高可用。

Redis集群方式共有三种：主从模式，哨兵模式，cluster(集群)模式

其中主从模式会保证数据在从节点还有一份，但是主节点挂了之后，需要手动把从节点切换为主节点。它非常简单，但是在实际的生产环境中是很少使用的。

哨兵模式就是主从模式的升级版，该模式下会对响应异常的主节点进行主观下线或者客观下线的操作，并进行主从切换。它可以保证高可用。

cluster (集群)模式保证的是高并发，整个集群分担所有数据，不同的 key 会放到不同的 Redis 中。每个 Redis 对应一部分的槽。

（上面三种模式也是面试重点，可以说很多道道出来，由于不是本文重点就不详细描述了。主要表达的意思是你得在面试的时候遇到相关问题，需要展示自己是知道这些东西的，都是面试的套路。）

在上面描述的集群模式下还是会出现一个问题，由于节点之间是采用异步通信的方式。如果刚刚在 Master 节点上加了锁，但是数据还没被同步到 Salve。这时 Master 节点挂了，它上面的锁就没了，等新的 Master 出来后（主从模式的手动切换或者哨兵模式的一次 failover 的过程），就可以再次获取同样的锁，出现一把锁被拿到了两次的场景。

锁都被拿了两次了，也就不满足安全性了。一个安全的锁，不管是不是分布式的，在任意一个时刻，都只有一个客户端持有。

Redlock简介
为了解决上面的问题，Redis 的作者提出了名为 Redlock 的算法。

在 Redis 的分布式环境中，我们假设有 N 个 Redis Master。这些节点完全互相独立，不存在主从复制或者其他集群协调机制。

前面已经描述了在单点 Redis 下，怎么安全地获取和释放锁，我们确保将在 N 个实例上使用此方法获取和释放锁。

在下面的示例中，我们假设有 5 个完全独立的 Redis Master 节点，他们分别运行在 5 台服务器中，可以保证他们不会同时宕机。

从官网上我们可以知道，一个客户端如果要获得锁，必须经过下面的五个步骤：

步骤描述来源：

http://redis.cn/topics/distlock.html
获取当前 Unix 时间，以毫秒为单位。

依次尝试从 N 个实例，使用相同的 key 和随机值获取锁。在步骤 2，当向 Redis 设置锁时，客户端应该设置一个网络连接和响应超时时间，这个超时时间应该小于锁的失效时间。例如你的锁自动失效时间为 10 秒，则超时时间应该在 5-50 毫秒之间。这样可以避免服务器端 Redis 已经挂掉的情况下，客户端还在死死地等待响应结果。如果服务器端没有在规定时间内响应，客户端应该尽快尝试另外一个 Redis 实例。

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

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

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

通过上面的步骤我们可以知道，只要大多数的节点可以正常工作，就可以保证 Redlock 的正常工作。这样就可以解决前面单点 Redis 的情况下我们讨论的节点挂掉，由于异步通信，导致锁失效的问题。

但是，还是不能解决故障重启后带来的锁的安全性的问题。你想一下下面这个场景：

我们一共有 A、B、C 这三个节点。

客户端 1 在 A，B 上加锁成功。C 上加锁失败。

这时节点 B 崩溃重启了，但是由于持久化策略导致客户端 1 在 B 上的锁没有持久化下来。

客户端 2 发起申请同一把锁的操作，在 B，C 上加锁成功。

这个时候就又出现同一把锁，同时被客户端 1 和客户端 2 所持有了。

比如，Redis 的 AOF 持久化方式默认情况下是每秒写一次磁盘，即 fsync 操作，因此最坏的情况下可能丢失 1 秒的数据。

当然，你也可以设置成每次修改数据都进行 fsync 操作（fsync=always），但这会严重降低 Redis 的性能，违反了它的设计理念。（我也没见过这样用的，可能还是见的太少了吧。）

而且，你以为执行了 fsync 就不会丢失数据了？天真，真实的系统环境是复杂的，这都已经脱离 Redis 的范畴了。上升到服务器、系统问题了。
所以，根据墨菲定律，上面举的例子：由于节点重启引发的锁失效问题，总是有可能出现的。

为了解决这一问题，Redis 的作者又提出了延迟重启（delayed restarts）的概念。

意思就是说，一个节点崩溃后，不要立即重启它，而是等待一定的时间后再重启。等待的时间应该大于锁的过期时间（TTL）。这样做的目的是保证这个节点在重启前所参与的锁都过期。相当于把以前的帐勾销之后才能参与后面的加锁操作。

但是有个问题就是：在等待的时间内，这个节点是不对外工作的。那么如果大多数节点都挂了，进入了等待。就会导致系统的不可用，因为系统在TTL时间内任何锁都将无法加锁成功。

Redlock 算法还有一个需要注意的点是它的释放锁操作。
释放锁的时候是要向所有节点发起释放锁的操作的。这样做的目的是为了解决有可能在加锁阶段，这个节点收到加锁请求了，也set成功了，但是由于返回给客户端的响应包丢了，导致客户端以为没有加锁成功。所有，释放锁的时候要向所有节点发起释放锁的操作。

你可以觉得这不是常规操作吗？

有的细节就是这样，说出来后觉得不过如此，但是有可能自己就是想不到这个点，导致问题的出现，所以我们才会说：细节，魔鬼都在细节里。

好了，简介大概就说到这里，有兴趣的朋友可以再去看看官网，补充一下。

我在Redis网站上 看到了一种称为Redlock的算法。该算法声称在Redis实现容错的分布式锁（或更确切地说， 租约），并且该页面要求来自分布式系统人员的反馈。这个算法让我产生了一些思考，因此我花了一些时间写了我的这篇文章。

由于Redlock已经有10多个独立的实现，而且我们不知道谁已经在依赖此算法，因此我认为值得公开分享我的笔记。我不会讨论Redis的其他方面，其中一些已经在其他地方受到了批评 。
你看这个文章，开头就是火药味十足：你说要反馈，那我就给你反馈。而且你这个东西有其他问题，我也就不说了。（其实作者在这篇文章中也说了，他很喜欢并且也在使用 Redis，只是他觉得这个 Redlock 算法是不严谨的）
要是一眼没看明白，我再给你一个中文版的，来自长发哥于2017年出版的书《数据密集型应用系统设计》：

可以看到上面的图片中提到了申请租约、租约到期的关键词，租约其实就是可以理解为带超时时间的锁。

而在书中，这张图片的下面写的描述这样的，你咂摸咂摸：