From cae1e93e0db1c17f9ed22036c7acdf7f9de460b5 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E6=8A=B1=E7=B4=A7=E6=88=91=E7=9A=84=E5=B0=8F=E9=B2=A4?= =?UTF-8?q?=E9=B1=BC?= Date: Thu, 9 May 2019 15:44:34 +0800 Subject: [PATCH] =?UTF-8?q?Update=20Redlock=E5=88=86=E5=B8=83=E5=BC=8F?= =?UTF-8?q?=E9=94=81.md?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/database/Redis/Redlock分布式锁.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/database/Redis/Redlock分布式锁.md b/docs/database/Redis/Redlock分布式锁.md index b1742f2f..86a15ff6 100644 --- a/docs/database/Redis/Redlock分布式锁.md +++ b/docs/database/Redis/Redlock分布式锁.md @@ -28,7 +28,7 @@ end 算法很易懂，起 5 个 master 节点，分布在不同的机房尽量保证可用性。为了获得锁，client 会进行如下操作： -1. 得到当前的时间，微妙单位 +1. 得到当前的时间，微秒单位 2. 尝试顺序地在 5 个实例上申请锁，当然需要使用相同的 key 和 random value，这里一个 client 需要合理设置与 master 节点沟通的 timeout 大小，避免长时间和一个 fail 了的节点浪费时间 3. 当 client 在大于等于 3 个 master 上成功申请到锁的时候，且它会计算申请锁消耗了多少时间，这部分消耗的时间采用获得锁的当下时间减去第一步获得的时间戳得到，如果锁的持续时长（lock validity time）比流逝的时间多的话，那么锁就真正获取到了。 4. 如果锁申请到了，那么锁真正的 lock validity time 应该是 origin（lock validity time） - 申请锁期间流逝的时间