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

In this article, the editor introduces in detail "how to use Redis to achieve distributed locks", the content is detailed, the steps are clear, and the details are handled properly. I hope this article "how to use Redis to achieve distributed locks" can help you solve your doubts.

The relation and difference between Lock and distributed Lock on single computer

Let's take a look at the locks on the stand-alone first.

For multithreaded programs running on a single machine, the lock itself can be represented by a variable.

When the value of the variable is 0, there is no thread to acquire the lock

When the value of the variable is 1, a thread has acquired the lock.

We usually call the operation of locking and releasing the lock. In fact, a thread invokes the locking operation to check whether the value of the lock variable is 0. If it is 0, the variable value of the lock is set to 1, which means that the lock has been acquired. if it is not 0, an error message is returned, indicating that locking failed, and another thread has acquired the lock. When a thread calls the release lock operation, it actually sets the value of the lock variable to 0 so that other threads can acquire the lock.

I use a piece of code to show the operation of locking and releasing locks, where lock is the lock variable.

Acquire_lock () {if lock = = 0 lock = 1 return 1 else return 0} release_lock () {lock = 0 return 1}

Like locks on a single machine, distributed locks can also be implemented with a variable. The operation logic of locking and releasing locks on the client is also consistent with the operation logic of locking and releasing locks on a single machine: when adding a lock, it is also necessary to judge the value of the lock variable and judge whether the lock is successful according to the value of the lock variable; when releasing the lock, the value of the lock variable needs to be set to 0, indicating that the client no longer holds the lock.

However, unlike threads operating locks on a single machine, in a distributed scenario, lock variables need to be maintained by a shared storage system, so that multiple clients can access lock variables by accessing the shared storage system. Accordingly, the operation of locking and releasing locks becomes reading, judging, and setting the value of lock variables in the shared storage system.

In this way, we can arrive at two requirements for implementing distributed locks.

Requirement 1: the process of locking and releasing a distributed lock, which involves multiple operations. Therefore, when implementing distributed locks, we need to ensure the atomicity of these lock operations.

Requirement 2: the shared storage system stores lock variables, and if the shared storage system fails or goes down, then the client will not be able to lock. When implementing the distributed lock, we need to consider to ensure the reliability of the shared storage system, and then ensure the reliability of the lock.

OK, now that we know the specific requirements, let's learn how Redis implements distributed locks.

In fact, we can implement it either based on a single Redis node or using multiple Redis nodes. In these two cases, the reliability of the lock is different. Let's first look at the implementation based on a single Redis node.

Implementation of distributed locking based on single Redis Node

As a shared storage system in the process of distributed lock implementation, Redis can use key-value pairs to save lock variables, and then receive and process lock and release operation requests sent by different clients. So, how exactly are the keys and values of the key-value pair determined?

We need to give the lock variable a variable name, which is used as the key of the key-value pair, and the value of the lock variable is the value of the key-value pair. In this way, Redis can save the lock variable, and the client can realize the lock operation through the command operation of Redis.

To help you understand, I drew a picture showing Redis using key-value pairs to hold lock variables and two clients requesting locks at the same time.

As you can see, Redis can hold the lock variable using a key-value pair lock_key:0, where the key is lock_key, which is also the name of the lock variable, and the initial value of the lock variable is 0.

Let's analyze the locking operation again.

In the figure, client An and C both request a lock. Because Redis uses a single thread to process requests, clients An and C process their requests serially, even if they send lock requests to Redis,Redis at the same time.

We assume that Redis first processes the request from client A, reads the value of lock_key, and finds that lock_key is 0, so Redis sets the value of lock_key to 1, indicating that it is locked. Then, Redis processes the request from client C, and at this point, Redis finds that the value of lock_key is already 1, so it returns the message of lock failure.

What I just said is the operation of locking, so how to release the lock? In fact, to release the lock is to directly set the value of the lock variable to 0.

Let me explain with the help of a picture. This picture shows the process of client A requesting to release the lock. When client A holds the lock, the value of the lock variable lock_key is 1. After client A performs the lock release operation, Redis sets the value of lock_key to 0, indicating that no client holds the lock.

Because locking consists of three operations (reading the lock variable, judging the lock variable value, and setting the lock variable value to 1), and these three operations need to be atomic when performed. So how do you guarantee atomicity?

There are two general ways to ensure the atomicity of operations, using Redis's single-command operation and using Lua scripts. So, how do you apply these two methods in a distributed locking scenario?

Let's first take a look at what single command operations Redis can use to achieve locking operations.

The first is the SETNX command, which sets the value of the key-value pair. Specifically, when this command is executed, it determines whether the key-value pair exists, if not, sets the value of the key-value pair, and if so, does not make any settings.

For example, if key does not exist when executing the following command, key will be created and the value will be set to value; if key already exists, SETNX will not do any assignment.

SETNX key value

For the release lock operation, we can use the DEL command to delete the lock variable after the business logic has been executed. However, you don't have to worry that after the lock variable is deleted, other clients will not be able to request a lock. Because when the SETNX command is executed, if the key-value pair (that is, the lock variable) that you want to set does not exist, the SETNX command first creates the key-value pair and then sets its value. Therefore, after the lock is released, when a client requests to add a lock, the SETNX command creates a key-value pair that holds the lock variable, sets the value of the lock variable, and finishes locking.

To sum up, we can use a combination of SETNX and DEL commands to lock and release locks. The following pseudo-code example shows the process of lock operation, which you can take a look at.

/ / Lock SETNX lock_key 1ram / Business Logic DO THINGS// release Lock DEL lock_key

However, there are two potential risks in implementing distributed locks using a combination of SETNX and DEL commands.

The first risk is that if a client executes a SETNX command and locks it, and then an exception occurs while manipulating the shared data, the final DEL command is never executed to release the lock. Therefore, the lock has been held by this client, other clients can not get the lock, nor can they access the shared data and perform subsequent operations, which will have an impact on business applications.

An effective solution to this problem is to set an expiration time for the lock variable. In this way, even if the client holding the lock has an exception and cannot release the lock actively, Redis will delete the lock variable after it expires according to its expiration time. After the lock variable expires, other clients can re-request to add the lock, which will not cause the problem of not being locked.

Let's look at the second risk. If client An executes the SETNX command to lock, and client B executes the DEL command to release the lock, client A's lock is mistakenly released. If client C happens to be applying for a lock, it can successfully acquire the lock and begin to operate on the shared data. In this way, client An and C are operating on the shared data at the same time, and the data will be modified, which is unacceptable to the business layer.

In order to deal with this problem, we need to be able to distinguish lock operations from different clients. What should we do? In fact, we can do something about the value of the lock variable.

In the method of locking using the SETNX command, we indicate whether the locking is successful by setting the value of the lock variable to 1 or 0. There are only two states for 1 and 0, and it is impossible to indicate which client performed the locking operation. Therefore, when we add a lock operation, we can have each client set a unique value for the lock variable, and the unique value here can be used to identify the client of the current operation. When releasing the lock operation, the client needs to judge whether the value of the current lock variable is equal to its unique identity, and the lock can be released only if it is equal. In this way, there will be no problem of mistakenly releasing the lock.

Now that you know the solution, how exactly is it implemented in Redis? Let's find out again.

Before I look at the specific code, I want to take you to learn the SET command of Redis.

We just mentioned when talking about the SETNX command, for the key-value pair that does not exist, it will first create and then set the value (that is, "set if it does not exist"). In order to achieve the same effect as the SETNX command, Redis provides the SET command with a similar option, NX, to achieve "set without existence". If the NX option is used, the SET command is set only if the key-value pair does not exist, otherwise no assignment is made. In addition, the SET command can be executed with the EX or PX option, which is used to set the expiration time of the key-value pair.

For example, when you execute the following command, SET creates a key and assigns a value to the key only if key does not exist. In addition, the survival time of key is determined by the value of seconds or milliseconds option.

SET key value [EX seconds | PX milliseconds] [NX]

With the NX and EX/PX options of the SET command, we can use the following command to implement the locking operation.

/ / Lock, and unique_value is used as the identity of client uniqueness

SET lock_key unique_value NX PX 10000

Unique_value is the unique identity of the client, which can be represented by a randomly generated string, while PX 10000 indicates that the lock_key expires after 10 seconds, so that the client cannot release the lock due to an exception during this period.

Because each client uses a unique identity in the locking operation, when releasing the lock operation, we need to determine whether the value of the lock variable is equal to the unique identity of the client performing the lock release operation, as shown below:

/ / release lock to compare whether unique_value is equal to avoid misrelease

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

This is the pseudo code for releasing the lock using the Lua script (unlock.script), where KEYS [1] indicates that lock_key,ARGV [1] is the unique identity of the current client, and both values are passed as parameters when we execute the Lua script.

Finally, we execute the following command to complete the lock release operation.

Redis-cli-- eval unlock.script lock_key, unique_value

You may also have noticed that in the lock release operation, we used the Lua script, because the logic of the lock release operation also includes multiple operations to read the lock variable, determine the value, and delete the lock variable, while Redis can execute the Lua script in an atomic way, thus ensuring the atomicity of the lock release operation.

Well, at this point, you've learned how to use SET commands and Lua scripts to implement distributed locks on a single Redis node. However, we now use only one Redis instance to hold the lock variable, and if the Redis instance goes down, then the lock variable is gone. At this point, the client can not lock the operation, which will affect the normal execution of the business. Therefore, when we implement the distributed lock, we also need to ensure the reliability of the lock. Then how to improve it? This brings us to the implementation of distributed locks based on multiple Redis nodes.

Implementation of highly reliable distributed locking based on multiple Redis nodes

When we want to achieve highly reliable distributed locks, we can not only rely on a single command operation, we need to follow certain steps and rules to add and unlock operations, otherwise, the lock may not work. What do you mean by "certain steps and rules"? It's actually a distributed locking algorithm.

In order to avoid the lock failure caused by Redis instance failure, Antirez, a developer of Redis, proposed a distributed locking algorithm Redlock.

The basic idea of the Redlock algorithm is to let the client and multiple independent Redis instances request locking in turn. If the client and more than half of the instances can successfully complete the locking operation, then we think that the client has successfully acquired the distributed lock, otherwise locking failed. In this way, even if a single Redis instance fails, because the lock variable is saved on other instances, the client can still lock normally and the lock variable is not lost.

Let's take a specific look at the implementation steps of the Redlock algorithm. The implementation of Redlock algorithm requires N independent Redis instances. Next, we can complete the locking operation in three steps.

The first step is for the client to get the current time.

The second step is that the client performs the locking operation on N Redis instances sequentially.

The locking operation here is the same as the locking operation performed on a single instance, using the SET command, with the NX,EX/PX option, and with the unique identity of the client. Of course, if a Redis instance fails, in order to ensure that the Redlock algorithm can continue to run in this case, we need to set a timeout for the locking operation.

If the client does not succeed in requesting a lock with one Redis instance until the timeout, then the client and the next Redis instance will continue to request the lock. The timeout of the lock operation needs to be much less than the effective time of the lock, which is generally set to tens of milliseconds.

The third step is that once the client completes the locking operation with all Redis instances, the client calculates the total time spent in the entire locking process.

The client can be considered locked successfully only if the following two conditions are met.

Condition 1: the client has successfully acquired the lock from more than half of the Redis instances (greater than or equal to Nmax 2pg 1)

Condition 2: the total time taken by the client to acquire the lock does not exceed the valid time of the lock.

After meeting these two conditions, we need to recalculate the effective time of the lock, and the result is that the initial effective time of the lock minus the total time taken by the client to acquire the lock. If the lock's validity time is too late to complete the shared data operation, we can release the lock so that the lock will not expire before the data operation is completed.

Of course, if the client fails to meet both conditions after performing the locking operation with all instances, the client initiates a lock release operation to all Redis nodes.

In the Redlock algorithm, the operation of releasing the lock is the same as releasing the lock on a single instance, as long as the Lua script that releases the lock is executed. In this way, as long as more than half of the N Redis instances work properly, the distributed lock can be guaranteed to work properly.

Therefore, in practical business applications, if you want to improve the reliability of distributed locks, you can achieve it through the Redlock algorithm.

After reading this, the article "how to use Redis to achieve distributed locks" has been introduced. If you want to master the knowledge points of this article, you still need to practice and use it yourself. If you want to know more about related articles, welcome to follow the industry information channel.

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.