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

What this article shares with you is about how to solve the lock timeout problem of distributed locks in Redis. The editor thinks it is very practical, so I share it with you. I hope you can get something after reading this article.

I. Preface

With regard to the redis distributed lock, I checked a lot of information and found that many of them only implemented the most basic functions, but it did not solve the problem that when the lock timed out and the business logic had not yet been executed, which would lead to: a thread timeout was set to 10s (to solve the deadlock problem), but the code execution time might take 30s, and then the redis server deleted the lock after 10s. At this time, thread B just applied for the lock. The lock does not exist on the redis server, and the code can be applied and executed. Then the problem is that both An and B threads acquire the lock and execute the business logic at the same time, which runs counter to the most basic nature of the distributed lock: at any one time, only one client holds the lock, that is, exclusive.

II. Preparatory work

Pressure testing tool jmeter

Https://pan.baidu.com/share/init?surl=NN0c0tDYQjBTTPA-WTT3yg extraction code: 8f2a

Redis-desktop-manager client

Https://pan.baidu.com/share/init?surl=NoJtZZZOXsk45aQYtveWbQ extraction code: 9bhf

Postman

Https://pan.baidu.com/share/init?surl=28sGJk4zxoOknAd-47hE7w extraction code: vfu7

You can also download it directly on the official website. I've sorted it out to the net disk.

I need postman because I haven't found a way for jmeter to open more windows. Haha.

III. Explanation

1. Springmvc project

2. Maven dependence

3. Core class

Distributed Lock tool Class: DistributedLock

Test interface class: PcInformationServiceImpl

Lock delay daemon thread class: PostponeTask

Fourth, the realization train of thought

First, if the lock delay thread is not enabled, the A thread timeout time is set to 10s, and the business logic execution time is set to 30s. After 10s, the API is called to see if the lock can be acquired. If so, it indicates that there is a thread safety problem.

As above, while adding the lock, open the lock delay thread and call the API to see if the lock can be acquired. If not, the delay is successful and the security problem is solved.

5. Implementation 1, version 01 Code 1), DistributedLock

Description: two methods, add lock unlock, add lock use jedis setnx method, unlock execute lua script, all are atomic operations

2), PcInformationServiceImpl

Description: the test class is very simple. Value is randomly generated to ensure that it is unique and will not unlock locks held by other clients in the case of timeout.

3) Open the redis-desktop-manager client and refresh the cache. You can see that there is no add_information_lock key at this time.

4) start jmeter and call the API for testing

Set five threads to access at the same time, check the existence of redis and add_information_lock within a timeout of 10 seconds, and adjust the interface multiple times. Only one thread can acquire the lock.

Review of 100 previous issues: a summary of 100 interview questions

Redis

1-4 requests, none of which got the lock

The fifth request to get the lock

OK, so far, everything is fine. After 10 seconds of testing, An is still executing the business logic to see if other threads can acquire the lock.

As you can see, the success of the operation means that An and B have executed this code that should be exclusive at the same time and need to be optimized.

Review of 100 previous issues: a summary of 100 interview questions

2. Version 02 Code 1), DistributedLock

Description: added lock delay method, lua script, self-compensation related syntax

2), PcInformationServiceImpl does not need to change 3), PostponeTask

Description: when calling lock, immediately open the PostponeTask thread, and the thread starts to execute the lock delay code after waiting for the timeout time of 2gam3. If the delay is successful, the add_information_lock key will always exist on the redis server until the business logic is executed, so in this process, other threads cannot obtain the lock, that is, thread safety is guaranteed.

Here are the test results

After 10 seconds, check the redis server, and add_information_lock still exists, indicating that the delay is successful.

At this time, request again with postman, and found that the lock could not be obtained.

Take a look at the console print

Thread An acquires the lock at 19:09:11 and delays it after 10 * 2 / 3 = 6s, which ensures that the lock will not be released before the business logic has been executed.

A thread finishes execution, the lock is released, and other threads can compete for the lock.

OK, so far, has solved the lock conflict problem of lock timeout while the business logic is still executing, but the most rigorous way is to use the official Redlock algorithm, in which the Java package recommends the use of redisson. In fact, the idea is to continue when the business logic is about to time out, so as to ensure that no other client will hold the lock before the business logic is executed.

The above is how to solve the lock timeout problem of distributed locks in Redis. The editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please 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.