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

This article mainly explains "what are the plans for the use of Java distributed locks". The content of the explanation in this article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "what is the use of Java distributed locks"?

Preface

With the continuous development of Internet technology and the increasing amount of data, the business logic is becoming more and more complex. in this context, the traditional centralized system can no longer meet our business needs, and distributed systems are used in more scenarios. Accessing shared resources in distributed systems requires a mutual exclusion mechanism to prevent mutual interference and ensure consistency. We need to use distributed locks.

Distributed consistency problem

First of all, let's look at a small example:

Suppose a mall has 10 items left in stock, user A wants to buy 6, and user B wants to buy 5. Ideally, user A buys 6, and inventory decreases 6 and leaves 4. At this time, user B should not be able to buy 5. Give a hint of insufficient quantity In the real situation, users An and B get 10 goods at the same time, and A buys 6. Before A updates the inventory, B buys 5 more. At this time, B updates the inventory, and there are 5 products left. This is a typical e-commerce "second kill" activity.

From the above examples, it is not difficult to see that in the case of high concurrency, there will be a variety of unpredictable consequences if you do not deal with it. Then in this case of high concurrency and multithreading, the most effective and common way to solve the problem is to add a lock to the shared resource or the operation of the shared resource to ensure the mutual exclusion of access to the resource. Java JDK has provided us with such locks, using ReentrantLcok or synchronized, we can achieve the purpose of mutually exclusive access to resources. But in the distributed system, because of the distribution of the distributed system, that is, multi-thread and multi-process and distributed in different machines, these two kinds of locks will lose the effect of the original lock, so we need to implement the distributed lock-distributed lock.

What conditions are required for distributed locks

The performance of acquiring and releasing locks is better

Determining whether or not to acquire a lock must be atomic, otherwise it may cause multiple requests to acquire the lock

When a network outage or downtime fails to release the lock, the lock must be clear, otherwise deadlock will occur

If you can reenter a thread and acquire the same lock multiple times, for example, if a thread is executing a locked method and another method that requires the same lock is called in the method, the thread can directly execute the called method without having to reacquire the lock.

5. For blocking lock and non-blocking lock, if the blocking lock does not acquire the lock, it continues to wait for the lock; after the non-blocking lock does not acquire the lock, it fails to return to the lock directly.

Distributed lock implementation

I. Database lock

Database locks are rarely used, have poor performance and are prone to deadlocks.

Locking table based on MySQL

This implementation relies entirely on the unique index of the database. When you want to acquire a lock, you insert a record into the database and delete it when you release the lock. There are several problems with this approach:

(1) there is no expiration time for the lock, and failure to unlock will lead to deadlock, and other threads can no longer acquire the lock, because the unique index insert will return a failure.

(2) it can only be a non-blocking lock. If insert fails, an error will be reported directly, and you cannot enter the queue for retry.

(3) cannot be reentered, and the same thread cannot acquire the lock until the lock is released.

Use optimistic locks to increase the version number

According to the version number to determine whether other threads have updated before the update, if it has been updated, the acquisition of the lock failed.

Second, cache lock

For specific examples, please refer to my series of articles on Redis, in which there is a complete implementation of Redis distributed locks.

Here we mainly introduce several distributed locks based on redis implementation:

Based on setnx and expire commands.

Based on the characteristics of setnx (set if not exist), when key does not exist in the cache, it will only go to set, otherwise false will be returned directly. If true is returned, the lock will be acquired, otherwise the lock will fail. To prevent deadlock, we use the expire command to set a timeout for this key to avoid it. But here seems to be perfect, in fact, there are defects, when our setnx is successful, the thread is interrupted abnormally, and the expire has not yet been set, then a deadlock will occur.

There are two ways to solve the above problems.

The first is set after the redis2.6.12 version, which provides a series of options

EX seconds-sets the expiration time of the key key (in hours and seconds)

PX milliseconds-sets the expiration time of the key key (in milliseconds)

NX-the value of key is set only if the key key does not exist

XX-the value of key is set only if the key key exists

The second one is implemented by setnx (), get () and getset (). The general implementation process is as follows:

(1) Thread Asetnx, whose value is the timeout timestamp (T1). If true is returned, the lock is obtained.

(2) Thread B acquires T1 with the get command, and compares it with the current timestamp to determine whether it times out and does not time out false. If it has timed out, execute step 3.

(3) calculate the new timeout T2, use the getset command to return T3 (this value may have been modified by other threads), if t1==t3, acquire the lock, if T1 timeout T3 indicates that the lock has been acquired by another thread

(4) after acquiring the lock, process the business logic, and then determine whether the lock has timed out. If the lock has not timed out, there is no need to handle it if it has timed out (to prevent the lock of other threads from being deleted)

RedLock algorithm

Redlock algorithm is a distributed lock implementation recommended by the authors of redis. The contents of the algorithm are as follows:

(1) get the current time

(2) attempt to acquire locks from 5 independent redis clients

(3) calculate the time it takes to acquire all locks if and only if the client acquires the lock from most nodes, and the time to acquire the lock is less than the effective time of the lock.

(4) recalculate the validity time, the original effective time minus the time consumed to acquire the lock

(5) remove locks for all instances

The reliability of redlock algorithm is higher than that of single-node redis lock, but the conditions for implementation are also harsh.

(1) 5 nodes must be deployed to make Redlock more reliable.

(2) you need to request 5 nodes to obtain the lock. In the way of Future, request to 5 nodes concurrently, and then get the response result together, which can shorten the response time, but it still takes more time than single-node redis lock.

Then, since more than three of the five nodes must be acquired, there may be acquisition lock conflicts, that is, everyone gets 1-2 locks, as a result, no one can get the lock. The redis author draws lessons from the essence of the raft algorithm. By starting at random time after the conflict, the conflict time can be greatly reduced, but this problem can not be well avoided, especially when the lock is acquired for the first time. So the time cost of acquiring the lock increases.

If two of the five nodes are down, the availability of the lock will be greatly reduced. First of all, you must wait for the result of the two down nodes to time out before returning, and there are only three nodes. The client must acquire the locks of all three nodes in order to have the lock, which makes it more difficult.

If there is a network partition, there may be a situation in which the client will never be able to acquire the lock, so let's take a look at a more reliable distributed lock zookeeper lock.

Zookeeper distributed lock

The distributed locking of zookeeper has been introduced before when I talked about zookeeper. I will not repeat it here.

First, let's take a look at the features of zookeeper and see why it is suitable for distributed locks.

Zookeeper is a software that provides consistent services for distributed applications. It has a hierarchical file system directory tree structure, which stipulates that there can be only one unique file name in a single directory.

Data model:

Permanent node: after a node is created, it does not disappear because of session failure

Temporary node: in contrast to a permanent node, if the client connection fails, the node is deleted immediately

Sequential nodes: similar to the characteristics of the above two nodes, if you specify that when you create such nodes, zk automatically adds a numeric suffix to the node name and is ordered.

Monitor (watcher):

When creating a node, you can register a monitor for that node. When the state of the node changes and watch is triggered, ZooKeeper will send only one notification to the client, because watch can only be triggered once.

Based on these features of zookeeper, let's take a look at how to leverage these features to implement distributed locks:

Create a lock directory lock

Thread A that wants to acquire the lock creates a temporary sequential node in the lock directory.

Get all the child nodes under the lock directory, and then get the sibling nodes smaller than yourself. if they do not exist, it means that the current thread has the lowest sequence number and obtains the lock.

Thread B acquires all the nodes, determines that it is not the smallest node, and sets the node whose listening (watcher) is smaller than itself (only focusing on the node that is smaller than itself is to prevent the "herding effect")

Thread A finishes processing, deletes its own node, and thread B listens to the change event, determines that it is the smallest node, and acquires the lock.

Thank you for reading, the above is the content of "what is the use of Java distributed lock". After the study of this article, I believe you have a deeper understanding of the use of Java distributed lock, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

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.