Example analysis of distributed lock Redlock in Redis

Redlock implementation library

• ##Java Redisson Star 9458

• C# RedLock.net Star 259

• Go redsync.go Star 249

Although the algorithm behind is the same, the number of likes is really impressive.

Single-point Redis lock

Let’s briefly review how the single-point Redis lock is implemented.

Get the lock

SET resource_name my_random_value NX PX 30000

Client A uses Redis to set a key-value pair and specify a timeout to avoid deadlock. When other clients access, they first check whether the key already exists and whether its value is "my_random_value". If it exists, wait, otherwise it will succeed and execute the business code. Objects shared and known to all clients include resource_name and my_random_value.

Release lock

if redis.call("get",KEYS[1]) == ARGV[1] then return redis.call("del",KEYS[1])else return 0end

Compare the corresponding values ​​obtained by key to see if they are equal. If they are equal, delete (release), otherwise it will return failure.

Defects of single-point Redis lock

When there is only one Redis instance, a failure will cause all services that rely on it to collapse. This flaw is extremely obvious. Obviously not suitable for large applications.

Problems encountered by the simple Redis master-slave architecture

In order to avoid single points of failure, we build a Master/Slave master-slave architecture for Redis, one Master, A Slave. You will encounter such a problem below. The following are usage scenarios.

1. Client A acquires a lock on the Master.

2. Master hung up when synchronizing this data to Slave (because the synchronization between Master and Slave is asynchronous).

3. Slave becomes Master.

4. Client B obtains the lock through the same key and value. Distributed lock failure

Redlock algorithm

Suppose we have N (assuming 5) Redis master instances, all nodes are independent of each other, and the business The system is also a simple call, and there are no other auxiliary systems such as message resending. Let’s simulate the algorithm below:

1. The client obtains the current time t0 of the server, in milliseconds.

Use the same key and value to acquire locks in 5 instances. When acquiring a business lock, the client will set a timeout that lasts far less than the time required for the business lock. For example, assuming the lock takes 10 seconds, you can set the timeout between 5-50 milliseconds. Rewritten sentence: In order to avoid the situation where Redis has failed when the client tries to acquire the lock, measures need to be taken. After timeout, jump directly to the next node.

3. The client subtracts t0 from the current time (t1) to calculate the time t2 (=t1-t0) taken to acquire the lock. Only when t2 is less than the business validity time of the lock (that is, 10 seconds in the second step), and the client acquires the lock on at least 3 (5/2 1) platforms, we will consider the lock acquisition successful.

4. If the lock has been acquired, the business validity time of the lock is 10s-t2.

5. If the client does not acquire the lock, it may be that the lock is not acquired on more than or equal to N/2 1 instances, or the effective time (10s-t2) is a negative number, we will try to release it The lock is not acquired on that node.

Lock release

Release is relatively simple, just delete the corresponding keys on all instances.

The above is the detailed content of Example analysis of distributed lock Redlock in Redis. For more information, please follow other related articles on the PHP Chinese website!