Java Summary--distributed lock

1. Concept

The reason of distributed lock: Single Application single-machine deployment environment, in order to solve multi-threaded concurrency problem, we will use REENTRANTLCOK or synchronized to solve mutual exclusion problem, but the business needs, single-machine deployment evolved into a distributed system, in a distributed deployment environment, The concurrency control lock policy used by the original single-machine deployment is invalid, in order to solve this problem, we need a mutual exclusion mechanism across the JVM to control the access of shared resources, which is the problem that distributed lock solves.

Distributed Lock Feature: A method can only be executed by one thread of a machine at the same time; blocking lock (no acquisition to lock, waiting), non-blocking lock (no acquisition to lock, return failure), lock failure, reentrant, high performance, high reliable acquisition and release lock;

2. Three implementations: database based, Redis based, zookeeper based

1) Database-based

A table is created in the database with multiple fields, including the method name, and the method name field creates a unique index;

Get and release: To execute a method, insert the method name into the datasheet, insert the lock successfully, and delete the corresponding row data release lock when the execution is complete.

Advantages:

• With the help of database, the realization method is simple;

Disadvantages:

• Based on database implementation, database availability and performance will directly affect the availability and performance of distributed locks, the database needs to synchronize the two-machine deployment data, master and standby switching;

• There is no reentrant feature, because row data persists until the same thread releases the lock and cannot successfully insert the data again, so you need to add a new column to the table to record the machine and thread information that is currently acquired to the lock and, when acquiring the lock again, query the table for machine and thread information that is the same as the current machine and thread. If the same, get the lock directly;

• There is no lock failure mechanism, because it is possible to successfully insert data after the server is down, the corresponding data is not deleted, when the service has been restored after the lock has been acquired, so you need to add a column in the table to record the failure time, and need to have a scheduled task to clear the failed data;

• Does not have the blocking lock characteristic, obtains the lock to return the failure directly, therefore needs to optimize obtains the logic, the loop obtains several times.

2) based on Redis

Before the Redis2.6.12 version, use the SETNX command to set the Key-value, use the expire command to set the expiration time of the key to obtain the distributed lock, using the DEL command to release the distributed lock;

If Setnx successfully returns 1, it indicates that a lock is obtained, when the program executes after the DELETE key reaches the purpose of releasing the lock, if the Setnx failure returns 0, the lock is not acquired and can be resumed by looping, if the program acquires a lock, disconnects from Redis and the lock is not released, the program has a deadlock. But because of the time-out period;

Multiple situation issues:

• After the SETNX command has been set Key-value, it has not been possible to set the expiration time with the expire command, the current thread has been hung, causing the key of the current thread setting to be valid, and subsequent threads failing to acquire the lock through SETNX, resulting in a deadlock The workaround is that because two commands are executed separately and do not have atomic characteristics, if the two commands can be combined to solve the problem, this feature is implemented in the Redis2.6.12 version, and Redis adds a series of options to the set command that can be set Resource_ Name My_random_value NX PX Max-lock-time to obtain a distributed lock, this command can only be executed if no key (Resource_name) exists (NX option), And this key has an auto-expiration time of max-lock-time seconds (px attribute). The value of this key is "My_random_value", which is a random value that must be unique across all machines for a secure release lock.
• In a distributed environment, thread A acquires a lock through this implementation, but after acquiring the lock, execution is blocked, causing the lock to fail, when thread B acquires the lock, then thread a resumes execution, the lock is released after execution completes, and the lock is released directly using the DEL command. When thread B is not finished, it will cause unpredictable problems; The workaround is to release the lock, only the key exists and the stored "My_random_value" value is the same as the specified value to execute the DEL command;
• In order to achieve high availability, will choose the master-slave replication mechanism, but the master-slave replication mechanism is asynchronous, there will be data synchronization problems, may lead to multiple machines multiple threads to obtain the same lock; the solution is to use the master-slave replication caused by the problem, the solution is not the master-slave replication, using the Redlock algorithm;

Redlock is described as follows: In a Redis distributed environment, assume that there are 5 Redis master, which are completely independent of each other, there is no master-slave replication or other cluster coordination mechanism. In order to fetch the lock, the client should do the following:

1. Gets the current Unix time, in milliseconds;

2. Try to get the lock from N instances, using the same key and random values. In step 2, when you set a lock to Redis, the client should set a network connection and response time-out, which should be less than the lock's expiration time. For example, if your lock has an automatic expiration time of 10 seconds, the time-out should be between 5-50 milliseconds. This avoids the case where the server-side Redis has been hung, and the client is still waiting for the result to be answered. If the server side does not respond within the specified time, the client should try another Redis instance as soon as possible;

3. The client uses the current time minus the start acquisition lock Time (the time recorded in step 1) to obtain the time the lock was used. The lock is successful only if and only if the Redis node from most (here is 3 nodes) is taken to the lock and the time used is less than the lock failure time.

4. If a lock is taken, the true effective time of the key is equal to the effective time minus the time used to acquire the lock (the result of the Step 3 calculation);

5. If, for some reason, the acquisition lock fails (without at least n/2+1 Redis instances taking the lock or the lock time has exceeded the effective time), the client should be unlocked on all Redis instances (even if some redis instances are not locked successfully at all).

Advantages:

• High performance, with the help of REDIS implementation is more convenient;

Disadvantages:

• After the thread acquires the lock, if the processing time is too long can cause the lock timeout to expire, so the lock timeout mechanism is not very reliable;

3) based on zookeeper

Zookeeper is an open source component that provides consistent services for distributed applications, which is a hierarchical file-system tree structure that requires only one unique file name in the same directory. The steps to implement a distributed lock based on zookeeper are as follows:

1. Create a directory mylock;

2. Thread A wants to acquire the lock and creates a temporary sequential node in the Mylock directory;

3. Get the Mylock directory under all the child nodes, and then get smaller than their brother node, if not present, the current thread sequence number is the smallest, to obtain a lock;

4. Thread B gets all the nodes, determines that it is not the smallest node, and sets the node to listen smaller than itself;

5. When thread a finishes, deletes its own node, thread B hears the change event, determines whether it is the smallest node, and if so, gets the lock.

Apache's Open Source Library curator, which is a zookeeper client, curator provides the implementation of a distributed lock, the acquire method is used to acquire the lock, and the release method is used to release the lock.

Advantages:

• High availability, reentrant, blocking lock feature to solve the failure deadlock problem.

Disadvantages:

• Because nodes need to be created and deleted frequently, the performance is not as good as the redis approach.

Java Summary--distributed lock