基于Redis构建分布式锁进阶-RedLock(真分布)

前言

在之前的《基于redis的分布式锁设计实现》文章中，介绍并实现了两种常见的redis分布式锁。但这种方式仅能保证在一个单节点的、保证永不宕机的环境下没有任何问题。在redis集群中，若遇到极端特殊场景会出现一些问题。

为什么说之前的分布式锁设计有问题？

用Redis来实现分布式锁最简单的方式就是在实例里创建一个键值，创建出来的键值一般都是有一个超时时间的，所以每个锁最终都会释放。而当一个客户端想要释放锁时，它只需要删除这个键值即可。

表面来看，这个方法似乎很管用，但是这里存在一个问题：在真实业务场景，为了保证缓存系统的高可用，redis往往并非是单点的，而是集群部署的。由于redis主从节点的数据同步是异步的，如果Redis的master节点在锁未同步到Slave节点的时候宕机了怎么办？举例来说：

1. 客户端A在master节点获得了锁。
2. 在锁同步到slave之前，master宕机，还未来得及将锁同步到slave
3. slave变成了master节点
4. 客户端B也得到了和A持有的相同的锁

在这种情况下，如果你可以容忍在宕机期间，多个客户端允许同时都持有锁，那用这个基于复制的方案就完全没有问题，否则上一篇文章实现的分布式锁明显是不可行的，因为这种方案无法保证分布式锁的安全和可靠性保证的第1个安全互斥属性

分布式锁的安全和可靠性保证需要满足以下三个属性：

1. 一致性：互斥，不管任何时候，只有一个客户端能持有同一个锁。
2. 分区可容忍性：不会死锁，最终一定会得到锁，就算一个持有锁的客户端宕掉或者发生网络分区。
3. 可用性：只要大多数Redis节点正常工作，客户端应该都能获取和释放锁。

此外，之前的设计的另一个问题是，当占有锁的线程执行时间大于过期时间，此时另一个线程也获取了锁，导致两个线程可同时访问共享资源。

RedLock 算法介绍

假设我们有N个Redis master节点，这些节点完全独立，不使用任何复制或者其他隐含的分布式协调算法。因此我们用之前在单节点环境下安全地获取和释放锁的方法在每个单节点里来获取和释放锁。

注意！！！：redLock会直接连接多个redis节点，不是通过集群机制连接的，RedLock的写与主从集群无关，直接操作的是所有主节点，所以才能避开主从故障切换时锁丢失的问题。

我们把N假设成5，这个数字是一个相对比较合理的数值，因此我们需要在不同的计算机或者虚拟机上运行5个master节点来保证他们大多数情况下都不会同时宕机。一个客户端需要做如下操作来获取锁：

1. 获取当前时间（单位是毫秒）
2. 按顺序用相同的key和随机值依次向N个Redis请求锁。在这一步里，客户端在每个master上请求锁时，有一个远小于锁释放时间的超时时间。比如如果锁自动释放时间是10秒钟，那每个节点锁请求的超时时间可能是5-50毫秒的范围，防止一个客户端在某个宕掉的master节点上阻塞过长时间，如果一个master节点不可用了，则应该尽快尝试下一个master节点。
3. 客户端计算获取锁总共花了多少时间，只有当客户端在大多数master节点上成功获取了锁（在这里是3个），而且总共消耗的时间不超过锁释放时间，这个锁就认为是获取成功了。
4. 如果锁获取成功了，锁的有效时间就是最初的锁释放时间减去获取锁所消耗的时间。
5. 如果锁获取失败了，不管是因为获取成功的锁不超过一半（N/2+1)还是因为总消耗时间超过了锁释放时间，客户端都会到每个master节点上释放锁，即便是那些他认为没有获取成功的锁。

失败的重试

当一个客户端获取锁失败时，这个客户端应该在一个随机延时后进行重试。采用随机延时是为了避免不同客户端同时重试导致谁都无法拿到锁的情况出现，同样的道理客户端越快尝试在大多数Redis节点获取锁，出现多个客户端同时竞争锁和重试的时间窗口越小，可能性就越低，所以最完美的情况下，客户端应该用多路传输的方式同时向所有Redis节点发送SET命令。 这里非常有必要强调一下客户端如果没有在多数节点获取到锁，一定要尽快在获取锁成功的节点上释放锁，这样就没必要等到key超时后才能重新获取这个锁（但是如果网络分区的情况发生而且客户端无法连接到Redis节点时，会损失等待key超时这段时间的系统可用性）

释放锁

释放锁比较简单，因为只需要在所有节点都释放锁就行，不管之前有没有在该节点获取锁成功。

RedLock算法缺点

Redlock算法对时钟依赖性太强，若Ｎ个节点中的某个节点发生时间跳跃，也可能会引此而引发锁安全性问题。

可参阅文章怎样做可靠的分布式锁，Redlock 真的可行么？，Redis RedLock 完美的分布式锁么？

文章里例举了个因为时间问题，Redlock 不可靠的例子。

1. client1 从 ABC 三个节点处申请到锁，DE由于网络原因请求没有到达
2. C节点的时钟往前推了，导致 lock 过期
3. client2 在CDE处获得了锁，AB由于网络原因请求未到达
4. 此时 client1 和 client2 都获得了锁

在 Redlock 官方文档中也提到了这个情况，不过是C崩溃的时候，Redlock 官方本身也是知道 Redlock 算法不是完全可靠的，官方为了解决这种问题建议使用延时启动，相关内容可以看之前的这篇文章。但是 Martin 这里分析得更加全面，指出延时启动不也是依赖于时钟的正确性的么？

仅有在你假设了一个同步性系统模型的基础上，Redlock 才能正常工作，也就是系统能满足以下属性：

1. 网络延时边界，即假设数据包一定能在某个最大延时之内到达
2. 进程停顿边界，即进程停顿一定在某个最大时间之内
3. 时钟错误边界，即不会从一个坏的 NTP 服务器处取得时间

Martin 认为 Redlock 实在不是一个好的选择，对于需求性能的分布式锁应用它太重了且成本高；对于需求正确性的应用来说它不够安全。因为它对高危的时钟或者说其他上述列举的情况进行了不可靠的假设，如果你的应用只需要高性能的分布式锁不要求多高的正确性，那么单节点 Redis 够了；如果你的应用想要保住正确性，那么不建议 Redlock，建议使用一个合适的一致性协调系统，例如 Zookeeper，且保证存在 fencing token。

不过笔者认为，应用场景也不是那么绝对，对于性能与正确性，有时候只需要一个折中的方案，保证较高的正确性的同时保证较高的性能，所以是否使用RedLock还取决于适不适合应用场景