关于Redis RedLock算法的争论

内容简介：Martin上来就问，咱们要锁来干啥呢？2个缘由：对于第1种缘由，咱们对锁是有必定宽容度的，就算发生了两个节点同时工做，对系统的影响也仅仅是多付出了一些计算的成本，没什么额外的影响。这个时候 使用对于第2种缘由，对正确性严格要求的场景（好比订单，或者消费），就算使用了 RedLock 算法仍然

 

Martin上来就问，咱们要锁来干啥呢？2个缘由：

1. 提高效率，用锁来保证一个任务没有必要被执行两次。好比（很昂贵的计算）
2. 保证正确，使用锁来保证任务按照正常的步骤执行，防止两个节点同时操做一份数据，形成文件冲突，数据丢失。

对于第1种缘由，咱们对锁是有必定宽容度的，就算发生了两个节点同时工做，对系统的影响也仅仅是多付出了一些计算的成本，没什么额外的影响。这个时候 使用 单点的 Redis 就能很好的解决问题，没有必要使用RedLock，维护那么多的 Redis 实例，提高系统的维护成本。

对于第2种缘由，对正确性严格要求的场景（好比订单，或者消费），就算使用了 RedLock 算法仍然 不能保证锁的正确性 。

咱们分析一下 RedLock 的有啥缺陷吧：

做者 Martin 给出这张图，首先咱们上一讲说过，RedLock中，为了防止死锁，锁是具备过时时间的。这个过时时间被 Martin 抓住了小辫子。

• 若是 Client 1 在持有锁的时候，发生了一次很长时间的 FGC 超过了锁的过时时间。锁就被释放了。
• 这个时候 Client 2 又得到了一把锁，提交数据。
• 这个时候 Client 1 从 FGC 中苏醒过来了，又一次提交数据。

这还了得，数据就发生了错误。RedLock 只是保证了锁的高可用性，并无保证锁的正确性。

这个时候也许你会说，若是 Client 1 在提交任务以前去查询一下锁的持有者是不本身就能解决这个问题？

答案是否认的，FGC 会发生在任什么时候候，若是 FGC 发生在查询以后，同样会有如上讨论的问题。

那换一个没有 GC 的编程语言？

答案仍是否认的， FGC 只是形成系统停顿的缘由之一，IO或者网络的堵塞或波动均可能形成系统停顿。

Martin给出了一个解决的方案：

为锁增长一个 token-fencing。

• 获取锁的时候，还须要获取一个递增的token，在上图中 Client 1 还得到了一个 token=33的 fencing。
• 发生了上文的 FGC 问题后，Client 获取了 token=34 的锁。
• 在提交数据的时候，须要判断token的大小，若是token 小于 上一次提交的 token 数据就会被拒绝。

咱们其实能够理解这个 token-fencing 就是一个乐观锁，或者一个 CAS。

Martin 还指出了，RedLock 是一个 严重依赖系统时钟 的分布式系统。

仍是这个过时时间的小辫子。若是某个 Redis Master的系统时间发生了错误，形成了它持有的锁提早过时被释放。

• Client 1 从 A、B、D、E五个节点中，获取了 A、B、C三个节点获取到锁，咱们认为他持有了锁
• 这个时候，因为 B 的系统时间比别的系统走得快，B就会先于其余两个节点优先释放锁。
• Clinet 2 能够从 B、D、E三个节点获取到锁。在整个分布式系统就形成 两个 Client 同时持有锁了。

这个时候 Martin 又提出了一个至关重要的关于分布式系统的设计要点：

好的分布式系统应当是异步的，且不能时间做为安全保障的。由于在分布式系统中有会程序暂停，网络延迟，系统时间错误，这些因数都不能影响分布式系统的安全性，只能影响系统的活性（liveness property）。换句话说，就是在极端状况下， 分布式系统顶多在有限的时间内不能给出结果，可是不能给出错误的结果 。

因此总结一下 Martin 对 RedLock 的批评：

• 对于提高效率的场景下，RedLock 过重。
• 对于对正确性要求极高的场景下，RedLock 并不能保证正确性。

这个时候感受醍醐灌顶，简直写的太好了。

RedLock 的做者，同时也Redis 的做者对 Martin的文章也作了回应，条理也是至关的清楚。

antirez 的回应

antirez 看到了 Martin 的文章之后，就写了一篇文章回应。剧情会不会反转呢？

antirez 总结了 Martin 对 RedLock的指控：

1. 分布式的锁具备一个自动释放的功能。锁的互斥性，只在过时时间以内有效，锁过时释放之后就会形成多个Client 持有锁。
2. RedLock 整个系统是创建在，一个在实际系统没法保证的系统模型上的。在这个例子中就是系统假设时间是同步且可信的。

对于第一个问题：

antirez 洋洋洒洒的写了不少，仔细看半天，也没有解决我心中的疑问。回顾一下RedLock 获取锁的步骤：

1. 获取开始时间
2. 去各个节点获取锁
3. 再次获取时间。
4. 计算获取锁的时间，检查获取锁的时间是否小于获取锁的时间。
5. 持有锁，该干啥干啥去

若是，程序在1-3步之间发生了阻塞，RedLock能够感知到锁已通过期，没有问题。

若是，程序在第 4 步以后发生了阻塞？怎么办？？？

答案是，其余 具备自动释放锁的分布式锁都没办解决这个问题 。

对于第二个质疑：

antirez 认为，首先在实际的系统中，从两个方面来看：

1. 系统暂停，网络延迟。
2. 系统的时间发生阶跃。

对于第1个问题。上文已经提到了，RedLock作了一些微小的工做，可是没办法彻底避免。其余带有自动释放的分布式锁也没有办法。

第2个问题，Martin认为系统时间的阶跃主要来自两个方面：

• 人为修改。
• 从NTP服务收到了一个跳跃时时钟更新。

对于人为修改，能说啥呢？人要搞破坏没办法避免。

NTP受到一个阶跃时钟更新，对于这个问题，须要经过运维来保证。须要将阶跃的时间更新到 服务器 的时候，应当采起小步快跑的方式。屡次修改，每次更新时间尽可能小。

 

 

因此严格来讲确实， RedLock创建在了 Time 是可信的模型上，理论上 Time 也是发生错误，可是在现实中，良好的运维和工程一些机制是能够最大限度的保证 Time 可信。

最后， antirez 还打出了一个暴击，既然 Martin 提出的系统使用 fecting token 保证数据的顺序处理。还须要 RedLock，或者别的分布式锁干啥？？

回顾

每个系统设计都有本身的侧重或者局限。工程也不是完美的。在现实中工程中不存在完美的解决方案。咱们应当深刻了解其中的原理，了解解决方案的优缺点。明白选用方案的局限性。是否能够接受方案的局限带来的后果。

架构原本就是一门平衡的艺术。

简单来讲，单实例Redis能解决大部分的分布式锁需求。Redlock的引入意义不大，若是对可用性要求更高的话，使用其余方案也许是更好的选择。