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

This article mainly explains "how to use distributed locks". Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let Xiaobian take you to learn "how to use distributed locks"!

What is Distributed Lock? What problems can distributed locks solve?

When our system has not used distributed architecture, we can use synchronous locks or Lock locks to ensure that when multiple threads are concurrent, only one thread modifies shared variables or executes code blocks at the same time, but when most of our systems are now distributed cluster deployment, pure synchronous locks and Lock locks can only ensure data consistency on a single instance, and multiple instances lose their effect.

At this time, it is necessary to use distributed locks to ensure the atomicity of shared resources. For example, the deduction inventory in our e-commerce system is not a problem when the single quantity is small. If the single quantity is large and multiple instances are concurrently processing the deduction inventory business at the same time, there may be an oversold problem.

Implementation of distributed locks?

Common distributed locks include database distributed locks, Zookeeper distributed locks, Redis distributed locks, and Redisson distributed locks. Among them, database implementation of distributed locks is relatively simple and easy to understand. It can be implemented directly based on database. It is also often used in some distributed businesses, but this method is also the least efficient and generally not used. We will focus on the implementation of the other three methods.

Zookeeper implements distributed locks

It is common to use Zookeeper to implement distributed locks. For example, many projects use Zookeeper as a distributed registry, and they like to use Zookeeper to implement distributed locks. This is mainly due to the two characteristics of Zookeeper: sequential temporary nodes and Watch mechanism.

Sequential temporary nodes: As anyone familiar with Zookeeper knows, Zookeeper provides a multi-level namespace of nodes, each node represented by a slash separated path, similar to our folders. Nodes are divided into persistent nodes and temporary nodes. Nodes can also be marked as ordered. When nodes are marked as ordered, this node has the characteristic of increasing order. We can use this characteristic to create the nodes we need.

Watch mechanism: Watch mechanism is another important feature of Zookeeper. We can register some Watchers on specified nodes and notify users when certain events are triggered.

Zookeeper Implementation of Distributed Locks

We first create a persistent node as the parent node. Whenever we need to access and create a distributed lock, we create a corresponding temporary sequential child node under this parent node. The temporary node name, parent node name and sequence number form the name of the feature. After establishing child nodes, sorting child nodes starting with the child node name under the parent node, judging whether the sequence number of the newly established node is the smallest, obtaining a lock if the sequence number is the smallest, blocking and waiting for a lock if the sequence number is not the smallest node, and registering Watcher at the node in the sequence above obtaining the node, and waiting for an operation corresponding to the node to obtain the lock.

After the service is processed, delete the node, close zk, and trigger Watcher to release the lock.

The above figure is the implementation of distributed locks in strict order of access. More often, we introduce some frameworks to help us implement them, such as the most commonly used Curator framework. The code is as follows:

InterProcessMutex lock = new InterProcessMutex(client, lockPath); if ( lock.acquire(maxWait, waitUnit) ) { try { //Business Processing } finally{ lock.release(); } }

The natural advantage of Zookeeper to implement distributed locks is that Zookeeper is implemented in clusters, and our production environment is generally deployed in clusters, which can avoid single-point problems, has good stability, and can ensure that locks can be released every time.

The disadvantage is that frequent creation and deletion of nodes, coupled with the registration of watch events, the pressure on zookeeper clusters is relatively large, and the performance is not as good as the distributed locks implemented by Redis.

Redis implements distributed locks

Redis implementation of distributed locks, the most complex, but the performance is indeed the best, so in the higher performance requirements of the system, we have chosen to use Redis to implement distributed locks. Using Redis to implement distributed locks is generally implemented using SETNX, for a simple example:

public static boolean getDistributedLock(Jedis jedis, String lockKey, String requestId, int expireTime) { String result = jedis.set(lockKey, requestId, SET_IF_NOT_EXIST, SET_WITH_EXPIRE_TIME, expireTime); if ("OK".equals(result)) { return true; } return false; }

The SETNX method guarantees atomicity in setting locks and lock expiration times, but for lock expiration time settings we should note that if you perform business

If the time is long and the expiration time we set is short, it will cause the problem that the lock has been released before the business is completed. Therefore, we need to evaluate the expiration time of the lock according to the actual business processing to ensure that the business can be processed normally.

Redisson implements distributed locks

Redisson is a Java in-memory data grid based on Redis. Redisson makes full use of a series of advantages provided by Redis key database on Netty framework based on NIO, and provides a series of common tool classes with distributed characteristics for users on the basis of common interfaces in Java utility kit. The performance is also better than our usual jedis.

Redisson, regardless of whether it is single-node mode or cluster mode, implements distributed locks very well. Generally, it uses cluster mode. In cluster mode, Redisson uses RedLock algorithm to handle the process of switching to another Master node when the Master node is down. Multiple applications obtain locks.

The implementation of Redisson cluster mode to acquire locks is to acquire locks on different nodes. There is a timeout time for acquiring locks on each node. If the lock acquisition timeout occurs, the node is considered unavailable. When the number of locks successfully acquired exceeds half of Redis nodes, and the time consumed for acquiring locks does not exceed the lock expiration time, the lock acquisition is considered successful. After obtaining the lock successfully, recalculate the lock release time, subtracting the time consumed to obtain the lock from the original lock release time. If the lock acquisition fails, the node that has successfully obtained the lock will also release the lock.

Specific code implementation:

introducing dependency

org.redisson redisson 3.13.1

Redisson Profile:

@Bean public RedissonClient redissonClient() { Config config = new Config(); config.useClusterServers() .setScanInterval(3000) //Cluster status scan interval in milliseconds .addNodeAddress("redis://192.168.0.1:6379).setPassword("666") .addNodeAddress("redis://192.168.0.2:6379").setPassword("666") .addNodeAddress("redis://192.168.0.3:6379") .setPassword("666"); return Redisson.create(config); }

Acquire lock operation:

long waitTimeout = 10; long leaseTime = 1; RLock lock1 = redissonClient1.getLock("lock1"); RLock lock2 = redissonClient2.getLock("lock2"); RLock lock3 = redissonClient3.getLock("lock3"); RedissonRedLock redLock = new RedissonRedLock(lock1, lock2, lock3); redLock.trylock(waitTimeout,leaseTime,TimeUnit.SECONDS); try{ //... }finally{ redLock.unlock(); }

summary

There are more than three ways to implement distributed locks. The simplest is database implementation. Zookeeper implementation is relatively simple, but the best performance is Redis implementation. However, in terms of reliability, Zookeeper is based on distributed clusters and has natural advantages. Reliability is relatively high. If the business scenario does not require high performance, Zookeeper is preferred to implement distributed locks.

At this point, I believe everyone has a deeper understanding of "how to use distributed locks," so let's actually operate it! Here is the website, more related content can enter the relevant channels for inquiry, pay attention to us, continue to learn!

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.