如何做可靠的分布式锁,Redlock真的可行么( 二 )
使用时间来解决一致性Redlock 无法产生 fencing token 早该成为在需求正确性的场景下弃用它的理由,但还有一些值得讨论的地方 。
学术界有个说法,算法对时间不做假设:因为进程可能pause一段时间、数据包可能因为网络延迟延后到达、时钟可能根本就是错的 。而可靠的算法依旧要在上述假设下做正确的事情 。
对于 failure detector 来说,timeout 只能作为猜测某个节点 fail 的依据,因为网络延迟、本地时钟不正确等其他原因的限制 。考虑到 Redis 使用 gettimeofday,而不是单调的时钟,会受到系统时间的影响,可能会突然前进或者后退一段时间,这会导致一个 key 更快或更慢地过期 。
可见,Redlock 依赖于许多时间假设,它假设所有 Redis 节点都能对同一个 Key 在其过期前持有差不多的时间、跟过期时间相比网络延迟很小、跟过期时间相比进程 pause 很短 。
用不可靠的时间打破 Redlock这节 Martin 举了个因为时间问题,Redlock 不可靠的例子 。
- client1 从 ABC 三个节点处申请到锁,DE由于网络原因请求没有到达
- C节点的时钟往前推了,导致 lock 过期
- client2 在CDE处获得了锁,AB由于网络原因请求未到达
- 此时 client1 和 client2 都获得了锁
接下来 Martin 又列举了进程 Pause 时而不是时钟不可靠时会发生的问题:
- client1 从 ABCDE 处获得了锁
- 当获得锁的 response 还没到达 client1 时 client1 进入 GC 停顿
- 停顿期间锁已经过期了
- client2 在 ABCDE 处获得了锁
- client1 GC 完成收到了获得锁的 response,此时两个 client 又拿到了同一把锁
Redlock 的同步性假设这些例子说明了,仅有在你假设了一个同步性系统模型的基础上,Redlock 才能正常工作,也就是系统能满足以下属性:
- 网络延时边界,即假设数据包一定能在某个最大延时之内到达
- 进程停顿边界,即进程停顿一定在某个最大时间之内
- 时钟错误边界,即不会从一个坏的 NTP 服务器处取得时间
推荐阅读
- 一文读懂客户端请求是如何到达服务器的
- 如何通过MD5反查身份证号?
- 茶叶如何保存才能够有效延长保质期
- 如何做一个windows原版系统U盘启动盘?
- 如何在Windows 10上获取文件或文件夹的所有权
- Win10局域网两台电脑如何共享文件?
- |职场上,领导为了提拔你,背后是如何运作的?别再犯傻,要懂配合
- 如何保存碧螺春 要注意什么
- 蓝花鼠尾草如何养殖
- 为什么降权不能接单 淘宝刷了10单被降权了,如何补救