Detailed explanation of distributed lock implementation in Redis

The scheduled tasks we used before were only deployed on a single machine. In order to solve the single-point problem and ensure that a task is only executed by one machine, we need to consider the lock issue, so we spend time studied this issue. How to implement a distributed lock? This article mainly introduces examples of the method of implementing distributed locks in Redis. The editor thinks it is quite good. Now I will share it with you and give you a reference. I hope it can help you.

The essence of a lock is mutual exclusion, which ensures that a client can hold the same lock at any time. If you consider using redis to implement a distributed lock, the simplest solution is to create a key value in the instance. , when the lock is released, the key value is deleted. However, a reliable and complete distributed lock requires many details to be considered. Let’s take a look at how to write a correct distributed lock.

Stand-alone version of distributed lock SETNX

So we implement a simple lock directly based on the setNX (SET if Not eXists) command of redis. Directly upload the pseudo code

Lock acquisition:

SET resource_name my_random_value NX PX 30000

Lock release:

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

A few details need to be noted:

First of all, we need to set the timeout when acquiring the lock. The timeout is set to prevent the client from crashing or the lock being held after a network problem occurs. The whole system is deadlocked.

Use the setNX command to ensure that the query and write steps are atomic

When the lock is released, we judge that KEYS[1]) == ARGV[1], here KEYS [1] is the value taken from redis, and ARGV[1] is the my_random_value generated above. The reason for the above judgment is to ensure that the lock is released by the locked holder. We assume that this step of verification is not performed:

1. Client A acquires the lock and the subsequent thread hangs. The time is greater than the expiration time of the lock.

2. After the lock expires, client B acquires the lock.

3. After client A recovers, after processing related events, it initiates the del command to redis. The lock is released

4. Client C acquires the lock. At this time, two clients in a system hold locks at the same time.

The key to this problem is that the lock held by client B is released by client A.

The lock must be released using a Lua script to ensure the atomicity of the operation. The release of the lock includes three steps: get, judgment, and del. If the atomicity of the three steps cannot be guaranteed, distributed locks will have concurrency problems.

After paying attention to the above details, a distributed lock of a single redis node is achieved.

There is still a single point of redis in this distributed lock. Maybe you will say that Redis has a master-slave architecture. When a failure occurs, just switch to the slave, but Redis replication is asynchronous.

1. If client A gets the lock on the master.

2. Before the master synchronizes the data to the slave, the master goes down.

3. Client B got the lock from the slave again.

In this way, due to the downtime of the Master, multiple people hold the lock at the same time. If your system can accept multiple people holding the lock for a short period of time. This simple solution will solve the problem.

But if this problem is solved. Redis officially provides a Redlock solution.

Implementation of RedLock

In order to solve the problem of Redis single point. The author of Redis proposed the solution of RedLock. The plan is very clever and concise.
The core idea of ​​RedLock is to use multiple Redis Masters at the same time for redundancy, and these nodes are completely independent, and there is no need to synchronize data between these nodes.

Suppose we have N Redis nodes, N should be an odd number greater than 2. RedLock implementation steps:

1. Get the current time

2. Use the method mentioned above to obtain the Redis locks of N nodes in sequence.

3. If the number of acquired locks is greater than (N/2+1) and the acquisition time is less than the lock validity time (lock validity time), it is considered that a valid lock has been acquired. Lock. The lock automatic release time is the initial lock release time minus the time spent previously acquiring the lock.

4. If the number of locks acquired is less than (N/2+1), or not enough locks are acquired within the lock validity time (lock validity time), it is considered that the lock acquisition failed. . At this time, lock release messages need to be sent to all nodes.

The implementation of releasing the lock is very simple. Initiate a release operation on all Redis nodes, regardless of whether the lock was acquired successfully before.

At the same time, you need to pay attention to several details:

The interval between retries to acquire the lock should be a random range rather than a fixed time. This can prevent multiple clients from sending lock acquisition operations to the Redis cluster at the same time and avoid simultaneous competition. The situation of acquiring the same number of locks at the same time. (Although the probability is very low)

If a master node fails, the recovery time interval should be greater than the lock validity time.

1. Suppose there are three Redis nodes A, B, and C.

2. Client foo acquired two locks A and B.

3. At this time, B is down and all the data in the memory is lost.

4. Node B replies.

5. At this time, client bar reacquires the lock and acquires two nodes, B and C.

6. At this time, two more clients have obtained the lock.

So if the recovery time will be greater than the effective time of the lock, the above situation can be avoided. At the same time, if the performance requirements are not high, you can even turn on the persistence option of Redis.

Summary

After understanding the distributed implementation of Redis, I actually feel that most distributed systems are actually very simple in principle, but in order to ensure the reliability of the distributed system There are a lot of details to pay attention to, trivial and unusual.

The distributed lock implemented by the RedLock algorithm is simple and efficient, and the idea is quite clever.

But is RedLock necessarily safe? I will also write an article discussing this issue. Please look forward to it.

Related recommendations:

Detailed explanation of the principle of redisson's method of implementing distributed locks

##Detailed explanation of php redis distributed lock and task queue code examples

Multiple implementation methods of distributed locks

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