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

This article mainly explains "how to apply Redis distributed lock". The content of the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn how to apply Redis distributed lock.

Distributed lock

In a single-process application, when a piece of code can only be executed by one thread at a time

Errors may occur in multithreading, for example, two threads accumulate a number at the same time, and two threads get the number at the same time, for example, 40, one thread adds 10, one thread adds 20, and the correct result should be 70

But since two threads calculate 50 and 60 in their own memory, both write their results to the original place of the number (save)

At this point, it is certain that the value of a thread will be overwritten, because reading-> calculating-- > saving is not an atomic operation. (an atomic operation is an operation that will not be interrupted by the thread scheduling mechanism. Once this operation starts, it will always run to an end. There will be no thread switching in the middle)

In other words, the end result is either 50 or 60, but not 70 (this is most likely to happen in the case of concurrency or parallelism)

When this happens to a single-process application, the lock semantics provided by the program can be directly locked (such as sychornized in java) to ensure that the code will only be executed by one thread, in order, and the result will be correct.

In distributed applications, because the same application process may be running on one machine, or running on different machines, the semantic locks originally included in the program can no longer work.

Because the same code may be executed on different machines and processes, one is needed to enable the same application code in different machines and processes to execute to the same piece of code. It can also be executed sequentially (or only one thread can execute at the same time)

This needs to be coordinated by middleware. There are many middleware that can realize distributed locking, and redis is one of them.

The principle of implementing distributed Lock with redis

The principle of distributed lock in redis is to set a value in redis (of course, make sure that all distributed applications are connected to the same redis, and use this redis as the intermediate point, otherwise it will be useless). This value can only be stored by one thread. When other threads (or processes on different machines) come to store it, it is found that the value already exists, which means that someone is already using the lock. At this point, either retry and wait, or give up.

The setting generally uses the SETNX (set if not exists) instruction. If the value does not exist, it will be set, and if it has, it will not be set. This is the key to holding the lock. When the person who has acquired the lock has finished processing, the DEL execution will be called to release the lock.

Deadlock problem

Distributed locks are implemented using SETNX and DEL, but in one case, if a thread succeeds in SETNX and gets the lock, suddenly the thread crashes for some reason, resulting in no DEL releasing the lock

Then, at this time, all other applications will no longer be able to get this lock, that is, a deadlock. The solution to this problem is to set the lock to a period of validity, after which the lock will be automatically released.

Using EXPIRE, you can set an expiration date for the lock, as follows

SETNX LOCK-KEY-NAME trueEXPIRE LOCK-KEY-NAME 5

However, there is another problem, because SETNX and EXPIRE are divided into two instructions, in which it is still possible that after the completion of SETNX execution, deadlocks may occur due to the failure of EXPIRE due to the failure of the machine or program.

Can affairs solve this problem?

NO, because EXPIRE depends on the execution result of SETNX, EXPIRE can be performed only after SETNX is successful, otherwise it cannot be executed. There is no branching logic of if else in the transaction, either all or none of them are executed.

In the version of redis2.8, the extension parameter of set instruction is introduced, which allows SETNX and EXPIRE to execute (atom) at the same time, which solves the problem of timeout.

SET LOCK-KEY-NAME true ex 5 nx timeout issu

Although it is mentioned above to solve the deadlock problem that may occur by setting the expiration time of the lock, what if the execution time of my program code exceeds the set expiration time, and the lock is automatically released at this time, but my code is not finished yet? what if someone else executes it again, resulting in an error in the result?

In general development scenarios, we will try to set the lock time as long as possible, such as 60s. Generally, applications can be executed within 60s, but I'm afraid of being serious. What if I can't finish the execution within 60s?

At this time, we can use a renewal scheme, that is, when the program is in the process of execution, constantly determine whether the lock is about to expire and whether the code is finished. If the lock is about to expire and is not finished, renew the lock to ensure that the lock will not be automatically released until our code is executed. This scheme is implemented by a framework called redisson in java and can be directly introduced into use.

Lock misplaced problem

In the process of using the lock, it is very possible that other applications do not get the lock, but the DEL instruction is also executed, releasing the lock of the program we are executing, causing other places to get the lock and enter the code snippet to begin execution.

The solution here is that in SETNX, value can be set to a randomly generated and globally unique string of numbers or characters. The thread holds the characters all the time. When releasing the lock, the characters are compared with the characters in the lock. If there is a match, the lock can be released. If it does not match, it means that someone else misplaced it and refused to release it at this time.

But judging whether the characters are the same and releasing the lock is not an atomic operation, and redis does not provide such a command, so we consider using a lua script to perform these steps (redisson also implements it)

The most important point is that the entry for releasing locks in the program must be uniform. In case some applications do not use the method described above and directly use DEL, then the above solution is useless (the author released it with DEL directly for testing).

Reentrancy

Reentrancy means that when a thread holds a lock, it requests to lock again. If a lock supports multiple locks of the same thread, then the lock is reentrant. ReentrantLock in Java means reentrant locks. The general principle is to add 1 to a number every time the lock is acquired,-1 each time it is released, and when the number is 0, the distributed lock is released.

Redis locks need to be supported in the above way if they want to support reentrancy, but this logic adds complexity. It is generally recommended to logically adjust the code snippets that require locks to avoid repeated acquisition of distributed locks. (of course, redisson also supports reentrant locks)

Redlock

The above approach does not seem to have many problems, but there may also be problems with redis itself. For example, in a Sentinel cluster, the master node hangs up and the slave node becomes the master node, but the client does not know it at this time.

If the client succeeds in SETNX on the master node that has just died, but the lock has not been synchronized to the slave node, the slave node becomes the master node, and there is no information about the lock in the new master node.

At this point, another client requests the lock, and the direct SETNX is successful, which leads to the two clients executing the same code at the same time, resulting in insecurity.

The industry provides a solution called Redlock, which roughly provides multiple redis instances that are independent of each other and have no master-slave relationship (without any relationship). Like other distributed algorithms, most mechanisms are used.

When locking, it will issue set (key, value, nx = True, ex = xxx) instructions to more than half of the nodes. As long as more than half of the nodes are set successfully, the lock will be acquired, and DEL instructions will be issued to all nodes when the lock is released.

Redlock algorithm (supported by Redisson) needs to consider details such as error retry, clock drift and so on. At the same time, Redlock needs to read and write to multiple nodes, so its performance will be lower than that of single redis.

If the business scenario has a low tolerance for errors and can accept a slight degradation in performance, you can consider using the Redlock algorithm.

Thank you for reading, the above is the content of "how to apply Redis distributed locks". After the study of this article, I believe you have a deeper understanding of how to apply Redis distributed locks, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

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.