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

How does redisson's WatchDog take care of the home? aiming at this problem, this article introduces the corresponding analysis and answer in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible way.

In the previous article, we analyzed the process of locking in redisson. To sum up, the process is not complex and the code is intuitive. The logic of locking is executed asynchronously through lua scripts. Among them, we noticed some details, such as the variable internalLockLeaseTime in RedissonLock, the default value is 30000 milliseconds, and the call tryLockInnerAsync () passed in a getLockWatchdogTimeout () obtained from the connection manager, and its default value is also 30000 milliseconds, all of which are related to the watchdog mechanism mentioned in the official redisson documentation. Watchdog, or a very vivid description of this mechanism, so what did the watchdog do and why? Next, let's analyze and discuss.

Let's first consider a question. Suppose that in a distributed environment, multiple service instances request to acquire a lock, and service instance 1 successfully acquires the lock. In the process of executing business logic, the service instance suddenly dies or hang resides. Will the lock be released and when? To answer this question, I naturally remember the lua script we analyzed earlier, in which pexpire was used to set the expiration time of the lock key for the first time, with a default of 30000 milliseconds. From this point of view, if the service instance goes down, the lock will eventually be released, and other service instances can continue to acquire the lock execution business. But if 30000 milliseconds later, if service instance 1 is not down but the business execution is not finished, it will cause thread problems if it is released. How is this redisson solved? This must realize the mechanism of automatically extending the validity period of the lock.

Previously, we analyzed that after the asynchronous execution of the lua script is complete, we set up a listener to handle some of the work after the asynchronous execution ends. As shown in the figure, after the operation is completed, the

To execute the operationComplete method, first determine whether the asynchronous operation is executed successfully. If it is not successful, return directly. If the execution is successful, the result will be obtained synchronously. If ttlRemaining is null, a timed scheduling method scheduleExpirationRenewal will be executed. Recall the previous lua script, when the locking logic

When the processing is over, a nil; is returned, so you are sure to go to the timing task. Let's take a look at what the logic of a scheduled task looks like.

First of all, it will first determine whether entryName exists in expirationRenewalMap, which is a map structure, mainly to determine whether the lock key of the locked client in this service instance exists, and if it already exists, return it directly. The first lock certainly does not exist. The next step is to create a TimeTask and delay the execution of the internalLockLeaseTime/3. Here we use the wonderful variables mentioned at the beginning of the article, which are executed once in about 10 seconds, and a method of asynchronous execution is called.

The renewExpirationAsync method, which is also called asynchronously to execute a lua script, first determines

Break whether there is a corresponding key8a9649f5-f5b5-48b4-beaa-d0c24855f9ab:anyLock:1 in the map structure of the lock key. If so, call the pexpire command to set the expiration time of the lock key. The default is 30000 milliseconds.

OK, now the idea is clear. In the above task scheduling method, it is also executed asynchronously and a listener is set. After the operation is executed successfully, this method will be called back. If the call fails, an error log will be made and returned, and the update lock expiration time will fail. Then get the result of asynchronous execution. If it is true, it will call itself. In this way, the execution of this logic will be delayed by another 10 seconds, so this logic will be executed every 10 seconds after you have successfully acquired the lock. Moreover, if the lock key has not expired, it will extend the expiration time of the lock to 30000 milliseconds, that is, as long as the service instance does not hang up. And without taking the initiative to release the lock, the watchdog will renew your contract every ten seconds to ensure that the lock is always in your hand. Perfect operation.

Up to now, adding locks and locks automatically extend the expiration time are all OK, and then what happens when other service instances try to add locks during the period when you execute the business and hold the lock? Or another thread on the current client to acquire the lock? Obviously, it's going to be blocked, so let's see how it's done through the code. Or focus on the locked lua code analyzed earlier, when the locked key exists and

When the only key of the current client in the map structure corresponding to the lock key also exists, the hincrby command will be called to increase the value of the unique key by one, and the pexpire will set the expiration time of the key to 30000 milliseconds, and then return nil. It is conceivable that the lock is successfully locked here, and it will continue to execute scheduled scheduling tasks to complete the renewal of the expiration time of the lock key. Here, the reentrant of the lock is realized.

Well, when this does not happen, the remaining validity period of the current lock will be returned directly, and the renewal logic will not be executed accordingly. Return to the above method at this time, as shown in the following figure, and return directly if the lock is successful.

Otherwise, it will enter an endless loop to try to lock, and after waiting for a period of time, the loop will try to lock and block until the first service instance releases the lock. Attempts to acquire a lock for different service instances are similar to the above logic, which implements the mutual exclusion of locks.

Then, let's take a look at the logic of lock release, which is actually very simple. We call the lock.unlock () method and follow the code to find that a lua script is also called asynchronously.

Now if you look at the lua script, it should be clearer, that is, by judging whether the lock key exists, if it does not exist, it will return directly; otherwise, it will judge whether the value of the unique key corresponding to the current client exists, and if it does not exist, it will return nil;. Otherwise, the value will increase by-1 to determine whether the value of the unique key is greater than zero, and if it is greater than zero, it will return 0; otherwise, delete the current lock key and return 1. Return to the previous method, which is also operated on the return value. If the return value is 1, it will cancel the previous

Renew the task regularly, and if it fails, you will do something similar to setting the status. This unlocking logic has nothing to do with it, so you don't have to see him.

To sum up, we have finished the locking and unlocking process of redisson. Now, redis distributed locking, redisson de-locking, that is, selecting a master instance in the redis cluster to implement the locking mechanism, and can mount multiple slave instances because of one master, thus achieving high availability. However, we have to think that if master goes down during the synchronization of master and salve, but a service instance has just written a lock, it will be embarrassing at this time. Before salve synchronizes to this lock, it will be switched to master. Then it can be said that there is a problem. Another service instance acquires a new lock on the new master. At this time, both service instances will hold the lock. There is a problem with the scenario of executing business logic. It is also a problem that we need to consider in the production environment.

This is the answer to the question about how redisson WatchDog takes care of the home. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel to learn more about it.

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.