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

Today, I will talk to you about how to understand ZK locks and Redis locks in distributed locks, which may not be understood by many people. In order to make you understand better, the editor has summarized the following for you. I hope you can get something from this article.

Distributed lock

There are two kinds of common distributed locks in distributed systems, one is based on Redis, the other is based on ZooKeeper. This article briefly introduces its principle and scheme.

Redis lock redis lock simple version lock

Let's start with the lock command. The lock command is set {lockName} {randomVal} nx px 30000.

Where the nx parameter means to set when there is no lock, and the px parameter represents the number of milliseconds. This command indicates that when the lockName key does not exist, set the value to randomVal and set the expiration time to 30000 milliseconds. Redis returns nil when the key exists in redis. When other threads (including other machines) acquire the lock, polling can be used to determine whether the lock is successful in order to block other threads.

Unlock

To unlock, the requirement we need to implement is that locks set by other threads cannot be deleted. Because in some cases, such as a lock timeout, other threads will still acquire the lock. Therefore, you must first determine whether the lock is set by yourself before deleting it. Since redis does not provide an atomic command to determine what the current value is, you must pass a lua script to redis to ensure the atomicity of the unlock operation. The principle of unlocking is to pass in a random value to unlock. The script will determine whether the current Key exists, and if so, determine whether the value is equal to the passed random value, and delete it if it is equal.

Shortcoming

This locking scheme has obvious disadvantages, such as:

First, this solution is not very reliable. Locked redis is easy to lose data after downtime. Even if a sentry is configured, data may be lost during master / slave switching.

Second, the fair lock can not be realized.

Third, polling blocking is a bit expensive.

Fourth, thread reentry can not be realized.

There is no renewal mechanism.

For the first point, redis officially recommends the use of a redisCluster-based redlock (red lock) scheme. The core point of this scheme is that the lock needs to be acquired successfully on most redis nodes to be successful. But that means it's more expensive, and some bigwigs on the Internet have questioned the red lock scheme.

Solution

This simple version of redis distributed locking scheme can not solve these problems. If we want to solve these problems, we can use redission framework. Redission uses queue, redis publish and subscribe mechanism, watchdog mechanism, and more complex locking and releasing lock scripts to solve these problems. Redission supports reentrant lock, fair lock, red lock and so on, and the redis lock is encapsulated according to the Lock interface of JDK, which is easy to operate.

ZK lock simple version of the unfair ZK lock lock

Marked by the successful creation of a temporary node in ZooKeeper, the lock is acquired successfully, and if the creation fails, the node is monitored until the node is deleted before attempting to create a temporary node. Why use temporary nodes? Avoid service downtime, resulting in deadlock problems.

Unlock

Delete the node and unlock it successfully.

Shortcomings of the scheme

The disadvantage of this scheme is that the lock is unfair, and the node deletes and wakes up more other listening threads, so it is not as efficient as the scheme of using temporary sequential nodes to wake up the next listener node.

Fair ZK locking based on temporary Sequential Node

Every time you try to acquire a lock, you try to create a temporary sequence node, and get all the temporary sequence nodes under the parent node. If there is a node ahead, the lock acquisition is not successful, and the main thread is blocked. Listen for the previous node to be deleted, and wake up the main thread if it is deleted. Conversely, if there is no node in front of the currently created temporary sequential node, the lock is acquired successfully.

Unlock

Delete the current temporary sequence node and unlock it successfully.

Problem solved

This scheme implements fair locking, and the previous concurrent competitive ZK temporary nodes are created instead of waking up in turn, reducing a certain amount of overhead.

A comparison between the two schemes

Personally, I think the design of redisCluster red lock is not very elegant for distributed systems, and the highly available zk lock based on zookeeper cluster is more elegant. Therefore, if you do technical selection, individuals tend to zk lock. However, if zookeeper is not built in the technical architecture, you may choose springcloud, or choose the redis lock encapsulated by redisssion.

After reading the above, do you have any further understanding of how to understand ZK locks and Redis locks in distributed locks? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

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.