Shulou(Shulou.com)05/31 Report--

This article focuses on "how to understand the encapsulation of distributed locks". Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn how to understand the encapsulation of distributed locks.

There are usually many options for distributed locks, such as Redis-based, Zookeeper-based, database-based, and so on.

Redis is used for caching data and is used in projects, so it is slightly more likely to use Redis as a distributed lock.

If you use Redis to make locks, you can directly use open source solutions, such as redisson.

The most common uses are as follows:

RLock lock = redisson.getLock ("anyLock"); lock.lock (); run (); lock.unlock ()

Get the lock object, call lock () to lock, execute the business logic, and call unlock () to release the lock.

Although the framework provides a concise way to use it, it is still necessary to wrap the lock. The purpose of packaging is to improve scalability and ease of use.

Abstract interface

If we directly use redisson's native API for locking, then RLock-related code will appear in many places, and suddenly one day, for some reason, the lock needs to be replaced, and the scope of the change is larger. Every place that uses RLock has to be changed.

Like the following figure: many Service use the RLock.lock () method. When we need to replace the lock, all the classes and methods involved have to be modified, as shown in the red section.

So we need to do a layer of abstraction, we can define a DistributedLock interface to provide lock-related capabilities, provide a variety of implementations, so as to facilitate replacement and extension.

As shown in the following figure: each Service uses the DistributedLock interface to add locks. When we need to replace the implementation of the lock, we do not need to change the place to use, just replace the implementation of DistributedLock.

Automatic release

Automatic release means that after locking, the lock needs to be automatically closed after the execution of the business logic. In the way Redisson did earlier, we need to manually call unlock () to release the held lock.

Of course, Redisson also provides a timeout release feature. Normally, the lock must be released after the business is executed, and the next request for the same lock can continue to be processed.

The most common problem with manually releasing resources is forgetting to release them, so we are all familiar with the introduction of try-with-resources to automatically release resources in JDK7.

So when we encapsulate, try not to let the user release it manually, so as to reduce the probability of error. For those who have results, we can use Supplier to pass your logic, and for those who do not return results, we can use Runnable to pass your logic.

/ * * locking * @ param key lock Key * @ param waitTime attempted locking, waiting time (ms) * @ param leaseTime failure time after locking (ms) * @ param success lock successfully executed logic * @ param fail lock failed execution logic * @ return * / T lock (String key, int waitTime, int leaseTime, Supplier success, Supplier fail)

Use:

String result = distributedLock.lock ("1001", 1000, ()-> {System.out.println ("in...") ; try {Thread.sleep (1000);} catch (InterruptedException e) {e.printStackTrace ();} return "success";}, ()-> {System.out.println ("locking failed.") ; return "fail";})

Disaster recovery treatment

Another issue that needs to be noted is the availability of locks. If there is a problem with the corresponding Redis, locking will certainly fail at this time. If nothing is done, the normal business operation will be affected and the business will be unavailable.

In addition to implementing Redis locks, we can also implement other locks, such as database locks. When a Redis lock is not available, it is degraded to a database lock, which affects performance, but does not affect the business.

Locking process

If the database lock is also unavailable (beside the point: it is highly unlikely that all will be unavailable), it is better to let the business operation fail. Because we use locking scenarios to prevent problems caused by concurrency scenarios. If you consume abnormally when locks are not available and allow business operations to continue, there may be business problems without locking.

Of course, monitoring is also very necessary, such as Redis, database and so on. When something goes wrong, someone will intervene in time.

Monitoring system

Monitoring of middleware such as Redis, database and Zookeeper, which carry distributed implementation, is definitely necessary. Another monitoring is the finer-grained monitoring of the action of the lock.

For example, the time to add the lock, the time to release the lock, the time to execute the business in the lock, the amount of concurrency of the lock, the number of execution, the number of lock failures.

These data indicators are very important and can help you find problems in a timely manner. For example, hundreds of lock failures in 10 seconds have been downgraded to database locks. When you receive an alarm, you will know that there is a problem with Redis and solve it in time.

The monitoring method is whatever. Each company is different. You can expose the data to Prometheus, or you can integrate Cat to do a good job, as long as you can monitor and give an alarm.

At this point, I believe you have a deeper understanding of "how to understand the encapsulation of distributed locks". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow 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.