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

This article mainly introduces how to use Redis locking resources related knowledge, the content is detailed and easy to understand, the operation is simple and fast, has a certain reference value, I believe you will gain something after reading this article on how to use Redis locking resources, let's take a look at it.

I. Overview

In the case that this technology is constantly updated and iterated, the concept of distribution is becoming more and more important in the enterprise! When talking about distributed locks, it is inevitable to mention distributed locks. At present, there are three mainstream ways to implement distributed locks: Zookeeper, DB, and Redis. We take Redis as an example in this article!

From our point of view, these three attributes are the minimum guarantees required for the effective use of distributed locks.

Security features: mutual exclusion. At any given moment, only one client can hold the lock. Vitality attribute: no deadlock. In the end, even if the client that locks the resource crashes or partitions, the lock can always be acquired. Activity: fault tolerance. As long as most Redis nodes are running, the client can acquire and release locks. Second, the challenges brought by redis multi-node distributed locking.

The easiest way to lock a resource using Redis is:

Create a lock in the instance. Locks usually exist for a limited time using the Redis expiration feature, so they will eventually be released and eventually removed after a given period of time. When the client needs to release resources, it removes the lock.

At first glance, there seems to be no problem. But we might as well take a closer look, this implementation scheme does not seem to have any problem in the stand-alone environment of redis! But what if the node goes down? Okay, so let's add a slave node! If the primary server goes down, use this node! But we might as well see if she can really guarantee its availability.

When talking about this fatal flaw, we need to know that Redis replication is asynchronous.

Client An acquires the lock in the primary server. The host crashes before transferring lock replication to the slave. Slave was promoted to master. Client B acquires the lock because the slave does not have an object for the lock, so it is successful!

Obviously, this is wrong. The master node is down because the master node has no time to synchronize the data, so the slave node does not have the data, resulting in the failure of the distributed lock, so how does the author antirez solve this problem?

3. Redlock algorithm

The author believes that we should use multiple Redis, these nodes are completely independent, do not need to use replication or any system to coordinate data, the process of multiple redis systems to acquire locks becomes the following steps:

To obtain the current server time in milliseconds, try to use the same key and random values to acquire locks. There should be a timeout time for each machine to acquire locks. For example, if the expiration time of the lock is 10s, then the timeout time for acquiring a single node lock should be about 5 to 50 milliseconds. The purpose of this is to ensure that the client connects with the faulty machine, consuming extra time! Give up the node without getting data within the timeout time, thus go to the next node to get it, until all the nodes are obtained once! After the acquisition is completed, the current time minus the time acquired in step 1 is obtained. If and only if more than half of the client acquires the lock successfully and the acquisition time is less than the lock amount timeout time, the lock is proved to be effective! After the lock is acquired, the timeout time of the lock is equal to the set effective time-the time it takes to acquire the lock is equal to more than half of the machine that acquired the lock, or if the timeout time of the lock is calculated to be negative, the system will try to unlock all instances. Even if some instances do not acquire the lock successfully, they will still try to unlock it. To release the lock, simply release the lock in all instances, regardless of whether the client thinks it can successfully lock the given instance. 4. But can Redlock really solve the problem?

Martin Kleppmann post task, Redlock can not guarantee the security of the lock!

He thinks there are no more than two uses for locks.

To improve efficiency, use locks to ensure that a task does not need to be performed twice. For example, (expensive calculation) to ensure that the correct, the use of locks to ensure that the task is carried out in accordance with the normal steps, to prevent two nodes at the same time to operate a piece of data, resulting in file conflicts, data loss.

For the first reason, we have a certain tolerance for the lock, even if two nodes work at the same time, the impact on the system is only a little more computational cost, no additional impact. At this time, using a single point of Redis can solve the problem very well, there is no need to use RedLock, maintain so many Redis instances, and increase the maintenance cost of the system.

1. The disadvantages caused by the timeout of distributed locks

But for the second scenario, it is more cautious, because some money transactions are likely to be involved. if locking fails and two nodes process the same data at the same time, the result will be file corruption, data loss, permanent inconsistency, or loss of money!

Let's assume a scenario where we have two clients, and each client has to get the lock before it can save the data to the database. What's wrong with our implementation using the RedLock algorithm? In RedLock, locks have expiration times to prevent deadlocks, but Martin thinks this is unsafe! The flowchart looks something like this!

After the client 1 acquires the lock successfully, it starts to execute, and Full GC occurs in half of the system, the system service is suspended, and the lock times out after a period of time.

After waiting for the lock timeout of client 1, client 2 successfully acquires the lock and starts to perform the storage operation. After completion, client 1 completes the Full GC and does another storage operation! It's not safe! How to solve the problem?

Martin proposes an implementation mechanism similar to optimistic locking, as shown in the following example:

After client 1 has been suspended for a long time, client 2 acquires the lock and starts to write to the library, and carries token 34 at the same time. After writing to the library, client 1 wakes up and begins to enter the library, but because the token carried is 33 less than the latest token, the submission was rejected!

This idea sounds like a complete idea, so that even if the system is suspended for some reason, the data can be processed correctly. But think about it:

If the datastore can always accept writes only if your tokens are larger than all past tokens, then it is a linearizable storage area, equivalent to using a database to implement a distributed locking system, then the role of RedLock becomes minimal! You don't even need to use redis to guarantee distributed locks! 2.RedLock is strongly dependent on the system clock.

Recall that the Redlock algorithm takes several steps to acquire the lock, and you will find that the effectiveness of the lock is strongly dependent on the current system clock. Let's assume:

We have five redis nodes for A B C D E:

Client 1 acquires the lock of node A _ Magi B ~ C. Unable to access D and E due to network problems. The clock on node C jumps forward, causing the lock to expire. Client 2 acquires the lock of node C _ MagneD _ E. Unable to access An and B due to network problems. Now, customers 1 and 2 think they hold the lock.

A similar problem may occur if C crashes and restarts immediately before persisting the lock to disk.

Martin believes that the time step of the system mainly comes from two aspects (and the solution given by the author):

Artificial modification. What can be said about artificial modification? There is no way to avoid sabotage. A hopping clock update was received from the NTP service. NTP is updated by a step clock, which needs to be guaranteed by operation and maintenance. When you need to update the step time to the server, you should take a small step and run fast. Modify it many times and keep the time of each update as small as possible. 3. Make up for the shortcomings caused by the timeout of distributed locks based on program language

We review 1 point of view, the root cause of this defect in abstraction is to solve the lock failure caused by system downtime and add a failure time to the lock strength. In abnormal cases, a series of problems caused by the execution time of the program (business) is longer than the lock failure time. Can we consider this aspect and use the program to solve this deadlock?

Since the failure time of the lock is less than the business time, we find a way to ensure that the execution time of the business program is definitely less than the lock timeout time.

Redisson in java language implements a mechanism that ensures that the lock failure time is absolutely longer than the execution time of business programs. Officially called the watchdog mechanism (Watchdog), its main principle is that after the program successfully acquires the lock, it will fork a sub-thread to renew the lock until the lock is released! His schematic diagram is roughly as follows:

Redisson uses the daemon thread to renew the lock. (the role of the daemon thread: when the main thread is destroyed, it will be destroyed with the main thread. After preventing the program from downtime, the thread still continues to live, resulting in a deadlock!

In addition, Redisson also implements and optimizes the RedLock algorithm, fair lock, reentrant lock, interlocking and other operations, which makes the implementation of Redis distributed lock more simple and efficient!

This is the end of the article on "how to use Redis to lock resources". Thank you for reading! I believe that everyone has a certain understanding of the knowledge of "how to use Redis lock resources". If you want to learn more, you are welcome to 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.