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

This article mainly explains "how redisson solves the deadlock problem". The content in 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 redisson solves the deadlock problem".

Regarding Redisson as the realization of distributed lock, it is divided into three modules.

1. `1. Redisson to implement distributed lock principle` 2. `2. Redisson to implement source code parsing of distributed locks`3.`3. Project code for Redisson to implement distributed locks (which can be used in practical projects) 1. Efficient distributed locks

When designing distributed locks, we should consider at least some conditions that distributed locks should meet, as well as how to design distributed locks efficiently. Here, I think the following points must be considered.

1. Mutual exclusion

Under the condition of distributed high concurrency, we most need to ensure that only one thread can acquire the lock at a time, which is the most basic point.

2. Prevent deadlock

Under the condition of distributed high concurrency, for example, when a thread acquires the lock, it cannot execute the command to release the lock because of system failure or other reasons, so that no other thread can acquire the lock and cause a deadlock.

Therefore, it is very necessary to set the effective time of the lock to ensure that after the system failure, the lock can be released actively within a certain period of time to avoid deadlock.

3. Performance

For shared resources with a large number of visits, we need to consider reducing the lock waiting time to avoid causing a large number of thread blocking.

Therefore, there are two points to consider when designing the lock.

1. The granularity of the lock should be as small as possible. For example, if you want to reduce inventory through a lock, you can set the name of the lock to the ID of the product instead of any name. In this way, the lock is only valid for the current commodity, and the granularity of the lock is small.

2. The scope of the lock should be as small as possible. For example, if you can solve the problem by locking 2 lines of code, don't lock 10 lines of code.

4. Re-entry

We know that ReentrantLock is a reentrant lock, so its characteristic is that the same thread can get the lock of the same resource repeatedly. Reentrant locks are very conducive to the efficient use of resources. A demonstration will be made later on this point.

In view of the above Redisson can be well satisfied, let's analyze it below.

II. Analysis of Redisson principle

In order to better understand the principle of distributed lock, I draw a picture by myself to analyze it.

1. Locking mechanism

Thread to get the lock, get success: execute the lua script, save the data to the redis database.

The thread goes to acquire the lock and fails: it has been trying to acquire the lock through the while loop, and after the acquisition is successful, the lua script is executed to save the data to the redis database.

2. Watch dog automatic extension mechanism

This is difficult to understand, and after finding some information, I feel that it has not been explained very clearly. My own understanding here is:

In a distributed environment, if a thread acquires a lock and suddenly the server goes down, the lock will be released automatically after a certain period of time, and you can also set the effective time of the lock (without setting the default of 30 seconds). The main purpose is to prevent deadlocks.

However, in the actual development, there will be the following situation:

1. `/ / set lock 1 second past `2.` redissonLock.lock ("redisson", 1); `3.` / * * 4. `* Business logic needs to consult 2 seconds `5.` * / `6. `redissonLock.release ("redisson") `7. `/ * `8.` * Thread 1 comes in to acquire the lock, and everything is normal without downtime, but its business logic needs to be executed for 2 seconds. This will be a problem. After Thread 1 executes for 1 second, the lock automatically expires. `9. * Thread 2 comes in at this time. Then there are threads 1 and 2 executing code in this business logic at the same time, which is of course unreasonable. `10. `* and if this is the case, the system will throw an exception when unlocking, because unlocking and locking are no longer the same thread, as demonstrated in the following code. `11. `* /`

So at this time, the watchdog appeared, its role is that thread 1 business has not finished execution, time has passed, thread 1 still wants to hold the lock, it will start a watch dog background thread, constantly extend the survival time of the lock key.

Note that the normal watchdog thread does not start, and that the watchdog startup will have a certain impact on the overall performance, so it is not recommended to turn on the watchdog.

3. Why use lua scripts?

Needless to say, the main reason is that if your business logic is complex, send it to redis in a lua script, and the redis is single-threaded, which ensures the atomicity of this complex business logic.

4. Reentrant locking mechanism

I think the reason why Redisson can implement reentrant locking mechanism has something to do with two points:

1. `1. The data type of Redis storage lock is Hash type`2. `2. The key value of Hash data type contains the current thread information. `

Here is the data stored by redis

The above figure means the mechanism of reentrant locks, and its biggest advantage is that the same thread does not need to wait for the lock, but can operate directly.

5. Shortcomings of Redis distributed lock

The drawback of Redis distributed locks is that in Redis Sentinel mode:

Client 1 writes an redisson lock to a master node, which is replicated asynchronously to the corresponding slave node. But in this process, once the master node goes down and the active / standby switch occurs, the slave node changes from a master node to a master node.

At this time, when client 2 tries to lock, it can also be locked on the new master node, which will cause multiple clients to lock the same distributed lock.

At this time, there will be problems in the business semantics of the system, which will lead to the generation of all kinds of dirty data.

The defect is in Sentinel mode or master-slave mode. If the master instance goes down, it may cause multiple clients to lock at the same time.

Thank you for your reading, the above is the content of "how redisson solves the deadlock problem". After the study of this article, I believe you have a deeper understanding of how redisson solves the deadlock problem, 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.