Change lock acquisition method to parallel execution (#2385)

* Change lock acquisition method to parallel execution

I think this is a mistake, because I've found a contradiction within the same article, in the section titled "Retry on Failure", author mentioned: "ideally the client should try to send the SET commands to the N instances at the same time using multiplexing."

* Update content/develop/clients/patterns/distributed-locks.md

---------

Co-authored-by: David Dougherty <[email protected]>

Author: yaosongding

content/develop/clients/patterns/distributed-locks.md

@@ -124,7 +124,7 @@ In the distributed version of the algorithm we assume we have N Redis masters. T
 In order to acquire the lock, the client performs the following operations:
 
 1. It gets the current time in milliseconds.
-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. 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.
+2. It tries to acquire the lock in all the N instances in parallel, 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 staying blocked too long when communicating with an unavailable Redis node, ensuring the connection attempt times out quickly.
 3. The client computes how much time elapsed in order to acquire the lock, by subtracting from the current time the timestamp obtained in step 1. If and only if the client was able to acquire the lock in the majority of the instances (at least 3), and the total time elapsed to acquire the lock is less than lock validity time, the lock is considered to be acquired.
 4. If the lock was acquired, its validity time is considered to be the initial validity time minus the time elapsed, as computed in step 3.
 5. If the client failed to acquire the lock for some reason (either it was not able to lock N/2+1 instances or the validity time is negative), it will try to unlock all the instances (even the instances it believed it was not able to lock).