How to renew Redis distributed Lock

This article will explain in detail how to renew the Redis distributed lock. The content of the article is of high quality, so the editor will share it with you for reference. I hope you will have some understanding of the relevant knowledge after reading this article.

How to renew the correct posture of Redis distributed Lock Redis distributed Lock

As far as Fei Chao knows, when many students use distributed locks, they directly use Baidu search to find a Redis distributed lock tool class. The key is that the tool class is also full of System.out.println (); and other statements. In fact, the correct posture of Redis distributed lock is to use redisson as a client tool. Specific introduction can search the largest same-sex dating site github.

How to answer

First of all, if you used the Redis distributed lock posture correctly, and read the corresponding official documentation, this problem So easy. Let's take a look.

Frankly speaking, if your English is very good, it may be easier to understand by reading English documents.

By default lock watchdog timeout is 30 seconds and can be changed through Config.lockWatchdogTimeout setting.

But if you are looking at Chinese documents,

The timeout for watchdog check lock is 30 seconds by default.

This sentence is an ambiguous sentence from the perspective of Chinese, and it has two meanings.

1. The watchdog defaults to 30 seconds to check the timeout of a lock.

two。 Look, the dog will check the timeout of the lock. The lock time is 30 seconds by default.

Seeing this, I hope everyone will not hack my primary school PE teacher, although he and the Chinese teacher are the same person. Chinese is not good, we can source code to come together!

Source code analysis

Based on the example given in the official documentation, we wrote the simplest demo, which is based on a wave of Ctr+C and Ctr+V operations in the screenshot above, as follows

Public class DemoMain {public static void main (String [] args) throws Exception {Config config = new Config (); config.useSingleServer (). SetAddress ("redis://127.0.0.1:6379"); RedissonClient redisson = Redisson.create (config); RLock lock = redisson.getLock ("anyLock"); lock.lock (); / / lock.unlock ();}}

Create

From this we know that the two parameters internalLockLeaseTime and lockWatchdogTimeout are equal.

The default values for lockWatchdogTimeout are as follows

Public class Config {private long lockWatchdogTimeout = 30 * 1000; public long getLockWatchdogTimeout () {return lockWatchdogTimeout;} / / omit extraneous code}

As you can see from the word internalLockLeaseTime, the timeout for this added distributed lock is 30 seconds by default. But there is another question, that is, how often does the watchdog extend the validity period? Let's look down.

Lock

< TIME_SECONDS_FIVE) { //线程池异步续约 ThreadPool.submit(() ->

{boolean renew = redisDistributionLock.renew (lockKey, lockContent); if (renew) {long expireTimeNew = lockContent.getStartTime () + (expireTime-lockContent.getStartTime ()) * 2-TIME_SECONDS_FIVE * 1000; lockContent.setExpireTime (expireTimeNew) } else {/ / failed to renew the contract, indicating that there is a problem with lockContentMap.remove (lockKey);}}) after the execution of OR redis;}} V. Redis master-slave replication pit

The most common solution for redis high availability is master-slave replication (master-slave), which also dug a hole for redis distributed locks.

In the redis cluster cluster environment, if client A wants to lock now, it will select a master node to write to the key mylock according to the routing rules. After the locking is successful, the master node will copy the key asynchronously to the corresponding slave node.

If the redis master node is down at this time, the master / slave switch will be carried out to ensure the availability of the cluster, and the slave will become redis master. Client B successfully locked the new master node, while client A thought it had successfully locked it.

This will cause multiple clients to lock a distributed lock at the same time, resulting in the generation of all kinds of dirty data.

As for the solution, at present, there is no radical cure, we can only try our best to ensure the stability of the machine and reduce the probability of this event.

Summary: the above are some of the pits I encountered when using Redis distributed locks. I often fill this pit with one method, but it doesn't take long to find that another pit has come out. In fact, there is no perfect solution at all, there is no silver bullet, but after weighing the pros and cons, I choose a compromise within the scope of acceptance.

About Redis distributed lock how to achieve renewal to share here, I hope the above content can be helpful to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.