Shulou(Shulou.com)06/02 Report--

This article mainly introduces the example analysis of distributed lock Redlock in Redis, which has a certain reference value. Interested friends can refer to it. I hope you will gain a lot after reading this article.

Redlock implementation library

Java Redisson Star 9458

C# RedLock.net Star 259

Go redsync.go Star 249

Although the latter algorithm is the same, but this praise is really convincing.

Single point Redis lock

Let's briefly review how a single point of Redis lock is implemented.

Acquire lock

SET resource_name my_random_value NX PX 30000

Client A sets a specific key-value pair on the Redis and gives a timeout (to avoid deadlock). Other clients visit to see if the key already exists, and the value is equal to my_random_value. If it already exists, wait, otherwise it will succeed and execute the business code. Resource_name and my_random_value are known and shared by all clients.

Release lock

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

Compare whether the corresponding value obtained by key is equal, and if so, delete (release), otherwise, a failure is returned.

Defects of single point Redis lock

This defect is actually obvious, if there is only one Redis instance, this one is dead, and all the services that rely on it are dead. Obviously not suitable for large-scale applications.

Problems encountered in the simple Redis master-slave architecture

In order to avoid a single point of failure, we give Redis a Master/Slave master-slave architecture, a Master, a Slave. There will be such a problem next. The following is the usage scenario.

Client An acquires a lock on Master.

Master failed when synchronizing this data to Slave (because synchronization between Master and Slave is asynchronous).

Slave becomes Master.

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

Redlock algorithm

Suppose we have N (suppose 5) Redis master instances, all nodes are independent of each other, and the business system is simply called, and there are no other auxiliary systems such as message resending. Let's simulate the algorithm:

1. The client gets the server's current time t0, milliseconds.

two。 Use the same key and value to acquire locks from five instances in turn. When the client acquires the lock, it sets a timeout that is much less than the duration required by the business lock. For example, suppose the lock takes 10 seconds, and the timeout can be set to, say, 5-50 milliseconds. This avoids a situation in which a Redis itself is dead, but the client has been trying to acquire the lock. After the timeout, jump directly to the next node.

3. The client subtracts t 0 from the current time (T1) and calculates the time it takes to acquire the lock T2 (= t1-t0). We consider the lock acquisition successful only if T2 is less than the service validity time of the lock (that is, 10 seconds of the second step), and if the client acquires the lock on at least 3 (5pm 2pm 1).

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, either it does not acquire the lock on an instance greater than or equal to Nmax 2pm, or the 10s-t2 is negative, we try to release the lock, even if it is not acquired on that node.

Release of lock

It is easy to release. Just delete the corresponding key on all instances.

Thank you for reading this article carefully. I hope the article "sample Analysis of distributed Lock Redlock in Redis" shared by the editor will be helpful to you. At the same time, I also hope you will support us and pay attention to the industry information channel. More related knowledge is waiting for you to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.