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

This article mainly introduces "the usage of Redis lock". In daily operation, I believe many people have doubts about the usage of Redis lock. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful to answer the doubts about "the usage of Redis lock". Next, please follow the editor to study!

For the implementation of distributed locks, in addition to redis locks, there are many, such as zookeeper,memcache, database, chubby and so on. Redis lock is widely used because it is easy to use.

This article mainly explains redis locks from the following aspects:

What are the problems when using 1.redis locks 2. What are the consequences of these problems? 3. How to solve these problems

1. The realization of redis lock

Lock command:

SETNX key value: when the key does not exist, set the key and return success 1, otherwise return failure 0. Key is the unique identification of the lock, which is generally named according to the business; Value is often used to compare which thread or message is locked, and it is generally generated using the UUID.randomUUID (). ToString () method. For example: setnx (key,1)

Unlock command:

DEL key releases the lock by deleting the key-value pair so that other threads can acquire the lock through the SETNX command. For example: del (key)

Lock timeout:

EXPIRE key timeout sets the timeout of key to ensure that even if the lock is not explicitly released, the lock can be released automatically after a certain period of time to prevent resources from being locked forever. For example: expire (key,30), which means that the lock is released after a 30s timeout.

Note:

Redis 2.6.12 and above add optional parameters to the set instruction, and the pseudo code is as follows: set (key,1,30,NX), which combines locking and timeout actions together and encapsulates them with atomicity.

2. Specific scenarios of redis lock solution

Scenario 1: why do redis locks need to time out?

Reason analysis: data locking is usually carried out between 1.redis and business processes by means of network communication, and there is packet loss in network communication. Coupled with the fact that locking and unlocking are two operations, there will be the problem that the lock can never be released. two。 In addition, after the business process is locked, the panic may be dropped, and there is no way to release the lock, resulting in the distributed lock being hung forever.

Based on the above two reasons: a distributed lock requires a timeout to actively release the lock to prevent the distributed lock from being hung all the time. The solution of redis distributed lock, 1. It can be solved by locking and timeout, but we'd better use atomic operations such as set (key,1,30,NX). two。 Using setnx and expire operations, because they are not atomic operations, there will be the above 1 and 2 problems, resulting in the lock is locked forever, but it is not impossible, we can use the lua script implemented on redis to ensure their atomicity.

Scenario 2: after the lock timeout is released, what if the locked business comes to release the lock?

In the specific scenario, after process 1 releases the lock during the timeout, process 2 acquires the lock, and then process 1 releases the lock, which may cause process 2 to be released by process 1 without completion. As follows:

The key to solving the above problem is that when we release the lock, we can tell whether the unlocking operation is initiated by the current locking process.

Generally, the process id is put into the setnx as a vlaue. Before unlocking, it is allowed to determine whether the lock is the same process. If not, unlocking is not allowed.

Note: this operation is actually a two-step operation, judging the lock, releasing the lock, they are not an atomic operation, so there is a situation where one step of the operation is completed and the other step is not operated. The solution is to use lua scripts to achieve the atomicity of locks.

Scenario 3: after the lock timeout is released, will there be two businesses processing locked code at the same time?

This scenario and scenario 2 are an extension of the problem, which happens if the timeout for setting the lock is too short.

After the lock is taken away by process 2, process 1 has not yet finished executing the code, so there will be a situation in which process 1 and process 2 operate that common code at the same time, which will go wrong and is obviously not the scenario we expected.

There are often two solutions to this scenario:

1. Adjust the timeout so that the business process can be executed within this time. two。 Start the daemon and actively adjust the timeout when the business process is not finished to make the timeout of the lock longer.

Scenario 4: after the lock is used, how can other businesses acquire the distributed lock?

This scenario is very basic. Once the lock is acquired by process 1, how does process 2 know when the lock will be acquired before releasing the lock?

This solution is a bit like operating system polling and semaphores.

1. Polling requires process 2 to time out and lock until a successful location can be locked, but this implementation consumes server resources. two。 In a semaphore-like method, business process 2 subscribes locked messages, while the subscription module maintains a message queue, and after the lock is released, process 2 is removed from the queue to notify that the lock has been released. After process 2 receives the notification, the locking operation can be carried out.

If the scenario 5:redis is clustered, will it be a problem to use redis distributed locks?

In order to ensure the availability of redis, the redis server will often set up a master-slave server. After the slave server in the master-slave server detects that the master server is dead, it will re-elect one as the master server, and the redis lock is operated on the master server.

Once, the following phenomena occur:

1. The master server has just been locked by process 1 and died before it could synchronize the data to the slave server. two。 The slave server is elected and a new master server is selected. 3. Process 2 successfully locked the new primary server. 4. In this way, both process 1 and process 2 will operate the common code at the same time, so there will be a problem, which can be regarded as a lock failure.

In fact, we do not have a good way to solve this problem, but fortunately the probability of this kind of data is relatively low.

Redis distributed lock can only be used as a means to alleviate concurrency. In order to solve the concurrency problem completely, it still needs the cooperation of database anti-concurrency means.

At this point, the study of "the use of Redis locks" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

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.