RedLock 时间问题
来源：4-20 观摩一下大神们对高可用分布式锁的争论
慕容6205926
2022-05-21
老师您好:
这边有两个问题想不明白
Q1:
- RedLock 我是一个个节点去要锁，那一个一个要本身就有网路传输的消耗时间，这样每个节点的过期时间，不就不同步了吗? ex: 假设锁过期时间为 5，共有 a,b,c 三个节点
- 我去跟 A 请求锁假设耗费了 0.1s
- 我接下来去跟 B 请求锁，并在服务器 B 设定过期时间为 5 s，但是这时因为请求的耗时关系，A 的锁只剩 4.9s 就过期了，这样不是 4.9s 后 A 已经过期了，但 B 还存在 0.1s
Q2:
- 时钟跳跃的问题能不能麻烦老师您再提点一下我哪边想错了，我的疑问是以老师的 ppt 来讲，C 节点快了 2s，所以在 A, B 都还是第 4 秒的状况下，C 已经到第 6 秒了释放掉锁，但是 C 如果比 A, B 都快 2秒，不是只代表 C 上锁时是在第 2 秒的瞬间，也就是 C 的锁过期时间是在第 2 ~ 7 秒，所以在 A, B 第 4 秒的瞬间，C 还是持有锁的
上面两个问题应该是我有哪边有盲点，再拜托老师了，谢谢
1回答
-
大能老师
2022-05-22
A1:结论：实际上RedLock会最终计算一个有效的锁的时间。
首先，关于RedLock锁有效时间有两个概念需要先了解：
1. TTL：Time To Live; 指的是 redis key 的过期时间或有效生存时间
2. clock drift：时钟漂移；指两个电脑间时间流速基本相同的情况下，两个电脑（或两个进程间）时间的差值；如果电脑距离过远会造成时钟漂移值过大
假设你设置的有效时间是10s，也就是TTL=10，我们假设获取锁时间消耗为1s，时钟漂移clock drift=2s
如果成功获取锁，则锁的真正有效时间是 TTL减去第三步的时间差 的时间；比如：TTL 是10s,获取所有锁用了耗时2s,则真正锁有效时间为8s，但是还应该再减去时钟漂移2s，实际有效锁时间就是6s，也就是锁有效过期时间为6s;
锁最小有效时间计算公式：
因此实际设置的TTL时长 要大于正常业务执行的时间+获取所有redis服务消耗时间+时钟漂移
A2:RedLock的时间跳跃指的是持有锁的节点机器上时序的跳跃。
假设系统有五个 Redis 节点（A、B、C、D 、 E）和两个客户端（1 和 2）。如果其中一个 Redis 节点上的**时钟向前跳跃**会发生什么？
1. 客户端 1 获取节点 A、B、C 上的锁。由于网络问题，无法访问 D 和 E。
2. 节点 C 上的时钟向前跳跃，导致锁到期。
3. 客户端 2 获取节点 C、D、E 上的锁。由于网络问题，无法访问 A 和 B。
4. 客户端 1 和 2 现在都相信他们持有锁。
Martin 认为 Redlock 必须「强依赖」多个节点的时钟是保持同步的，一旦有节点时钟发生错误，那这个算法模型就失效了。而机器的时钟发生错误，是很有可能发生的，比如：
系统管理员「手动修改」了机器时钟
机器时钟在同步 NTP 时间时，发生了大的「跳跃」
举个例子：你生产有个数据，设置持有锁的时间为30分钟，但是管理员运维不规范，把某个节点系统时间调后了1小时，这样这个节点的锁就失效了。
40
相似问题