在Distributed locks with Redis – Redis - The Redlock algorithm中,它说
It tries to acquire the lock in all the N instances sequentially, using the same key name and random value in all the instances. During step 2, when setting the lock in each instance, the client uses a timeout which is small compared to the total lock auto-release time in order to acquire it. For example if the auto-release time is 10 seconds, the timeout could be in the ~ 5-50 milliseconds range. This prevents the client from remaining blocked for a long time trying to talk with a Redis node which is down: if an instance is not available, we should try to talk with the next instance ASAP.
sequentially 是什么含义?为什么要 sequentially 呢?
然后在Distributed locks with Redis – Redis - Retry on failure中,它又说
When a client is unable to acquire the lock, it should try again after a random delay in order to try to desynchronize multiple clients trying to acquire the lock for the same resource at the same time (this may result in a split brain condition where nobody wins). Also the faster a client tries to acquire the lock in the majority of Redis instances, the smaller the window for a split brain condition (and the need for a retry), so ideally the client should try to send the SET commands to the N instances at the same time using multiplexing.
这不是互相矛盾吗?还是我哪里理解错了?
1
lance6716 2021-10-22 18:08:25 +08:00 via iPhone
一上来并发请求锁,在并发高的时候冲突会很大吧。重试的时候由于随机 delay 冲突就变小了
|
2
yibo2018 2022-03-23 17:39:32 +08:00
最近也在看,也不知道是不是英文,所以争议才会这么大。我也提供一个佐证楼主的证据
https://redis.io/topics/distlock#:~:text=In%20order%20to%20meet,each%20instance%20is%20similar). In order to meet this requirement, the strategy to talk with the N Redis servers to reduce latency is definitely multiplexing (or poor man's multiplexing, which is, putting the socket in non-blocking mode, send all the commands, and read all the commands later, assuming that the RTT between the client and each instance is similar). 这里的 multiplexing 是不是也是同时发送的意思?而不是依次 |