[jcampbell1]

> Step 2) It tries to acquire the lock in all the N instances sequentially, using the same key name and random value in all the instances.

> so ideally the client should try to send the SET commands to the N instances at the same time using multiplexing.

I am confused. Are the locks requested sequentially, or at the same time? It seem like if they are requested sequentially, the the random backoff time would need to be a large multiple of the combined latency.

[antirez]

> I am confused. Are the locks requested sequentially, or at the same time? It seem like if they are requested sequentially, the the random backoff time would need to be a large multiple of the combined latency.

As stated in the post, it is ideal if using multiplexing we send the SET to all the instances at the same time, but this does not change a lot the difference between the chosen lock validity and the latency to set the lock, since with 5 instances it is still requires something in the "a few" millisecond range in the average to set the lock, with not very optimized clients, so 1 second is already three order of magnitude more.

[jcampbell1]

Thanks, I understand. The sequential locking isn't a requirement per-se, and the assumption is that the N-masters are in the same region. It seems like with clever multiplexing, you could relax the requirement the N-masters are in the same region.

[antirez]

Definitely, even without proper multiplexing, if the connections are not blocking, it is possible to just lower the latency to MAX(latencies) sending the commands in a loop to all the instances, and later reading them.

Redis clients should be capable to do that, by allowing to separate (on demand) the command delivering from the reply reading moments.