Shulou(Shulou.com)05/31 Report--

This article introduces the relevant knowledge of "what is the method of Redis to achieve distributed locks". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

In a distributed system, we will encounter some situations that need to lock resources shared by multiple nodes, so distributed locks are needed. Distributed locks are usually stored in a shared storage system and can be shared and accessed by multiple nodes.

The essence of the lock

Simply put, the lock can be represented by a variable. For example, in a stand-alone multithreaded program, the lock of a resource can be represented by a bit data. That is, 0 means that there is no resource to access, and 1 means that the lock of the resource has been acquired by another thread and cannot be accessed.

To acquire and release locks for a particular resource is essentially to obtain and modify the value of this variable. If the value is 0, modify it to 1, and complete the acquisition process. If the value accessed is not 0, the acquisition of the lock fails; if the lock was previously acquired, the operation of changing the value of the variable representing the lock to 0 is actually the operation of releasing the lock.

In a distributed scenario, locks are implemented in the same way, except that the variable that represents the resource lock needs to be stored in a shared storage system. This shared storage system can be Redis or any other system that can provide data storage.

The first step in the implementation of distributed locks based on Redis: preliminary implementation of functions

In the case of Redis as the shared storage system, the variable representing the lock of a resource is a key-value pair in Redis. If the resource that needs to add a distributed lock is called resource_a, we can call the key of the lock variable of resource_a in Redis lock_a.

For example, as soon as a node needs to acquire a lock, it will access the value of lock_a in Redis. Assuming that the acquired value is 0, the node completes the locking operation as soon as it sets this value to 1. At this point, node 2 also needs to acquire the lock of resource_a. It accesses the value of lock_a in Redis and finds that the value is 1, which means that the lock has been acquired by other nodes and has not been released. Therefore, node 2 failed to lock the resource resource_a.

When a node needs to release the lock, it only needs to set the value of lock_a in Redis to 0 to complete the lock release, and then other nodes can acquire the lock of the resource again.

Step 2: atomization of locking operation

In the above description, locking is not a single operation, but includes several steps: reading the lock variable, judging the value of the variable, and modifying the lock variable. These three operations need to be atomized.

In Redis, there is a SETNX command that sets the value of the key-value pair. Unlike the SET command, it first determines whether the key-value pair exists. Only when the specified KEY does not exist will the value be set, otherwise nothing will be performed. SETNX means "SET if Not eXist". It is used the same as SET:

SETNX lock_a 1

In this way, when you need to acquire a lock, use the SETNX command to set a value for lock_a. If the setting is successful, you will get the lock, and if it fails, you will not get the lock. When you need to release the lock, you can use the DEL operation to delete the key-value pair.

This implements the atomization operation of acquiring and releasing locks.

Step 3: prevent non-release after locking

Next, consider a problem early: if the lock has not been released due to program exceptions and other reasons, the lock will always be held by it and cannot be released, and other nodes will not be able to access resources.

In order to avoid this situation, we must set the expiration time of the lock variable, and when the lock variable expires, we can re-request the lock, so that this problem can be avoided.

The SETNX command does not set the expiration time option. Fortunately, Redis provides the NX option to simulate SETNX for the SET command, and we can set the expiration time like this:

SET lock_a 1 NX PX 10000

The above command means that if lock_a does not exist, its value is set to 1 and expires after 10 seconds.

Step 4: who locks and releases.

The final problem is that if a node acquires a lock and for some reason node 2 performs a DEL operation, then other nodes can acquire the lock again.

To solve this problem, we can modify what is saved by the lock variable. In the previous logic, when we apply for a lock, we determine whether the lock variable exists, which has little to do with the value stored in it, so we can take advantage of this value.

When adding a lock, if the value is saved as the unique identity of each node, then the value is judged before releasing the lock to execute DEL, then you can first determine whether the lock is added by the current node, and then release it, so as to realize "who locks and who is released".

In this part, there is no single instruction that can read lock variables, judge, and delete, so it can be implemented using Lua script. Get the value of the current lock variable in the script, compare it with the given node identity, and delete it only if it matches, otherwise it will not operate.

When the lock is released, the Lua script is executed.

Step 5: achieve high availability

After improving the functionality, we will finally achieve high availability. If we use a single Redis as a shared storage system for distributed locks, then if the Redis is not available, the parts involved in distributed locks are not available, which is very fragile, which is why high availability is necessary.

At this point, it is necessary to bring out the distributed locking algorithm Redlock proposed by Antirez, the author of Redis. In short, it is for the lock applicant to request locking from multiple independent Redis instances. If the lock operation can be completed in more than half of the Redis, then the lock will be successfully acquired, otherwise the lock will fail.

When releasing a lock, it is also considered successful as long as the Lua script that successfully removes the lock variable is executed on more than half the instances.

This is the end of the content of "what is the method of Redis to implement distributed locks". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

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.