Distribution lock that's something

Why you need to use distributed locks

To ensure that the same method can only be executed by one thread at a time when high is not the case, you can use Java Concurrency-processing APIs (such as Reentrantlock and synchronized) for mutually exclusive control in the case of a single-machine deployment of a traditional monomer application, but With the development of the business, the original single-machine system is evolved into a distributed system, because the distributed system multithreading, multi-process deployment on different machines, which will make the original single-machine deployment in the case of the concurrency control lock policy invalidation, in order to solve this problem requires a cross-JVM mutual exclusion mechanism to control the access of shared resources, This is the problem that the distributed lock solves.

Three ways to implement distributed locks:

Before distributing the lock three kinds of implementation way, first understand the distributed lock should have the condition

1, in a distributed environment, a method at the same time can only be executed by one thread of a machine,

2. High-availability lock and release lock

3, high-performance acquisition lock and release lock

4, with reentrant characteristics

5, with lock failure mechanism, to prevent deadlock

6, has the blocking lock characteristic, namely does not obtain to the lock will continue waits to acquire the lock

7, with non-blocking characteristics, that is, no acquisition to the lock will directly return to acquire the lock failed.

The implementation method based on database

Create a table in the database that contains fields such as the method name, create a unique index on the method name field, want to execute a method, insert data into the table using the method name, insert the lock successfully, and delete the corresponding row data release lock when the execution is complete.

This implementation is simple, but there are some problems that need to be solved and optimized for the conditions that the distributed lock should have.

1 "Because it is based on database implementation, database availability and performance will directly affect the availability and performance of distributed locks, so the database needs a dual-machine deployment, data synchronization, primary and standby switching.

2 "does not have reentrant characteristics, because the same thread before releasing the lock, the row data has been present, cannot successfully insert the data again, so you need to add a column in the table to record the current acquisition of the lock machine and thread information, when the lock is acquired again, The machine and thread information in the query table is the same as the current machine and thread, and the lock is acquired directly if the same.

3 "There is no lock failure mechanism, because it is possible to successfully insert the data after the server is down, the corresponding data is not deleted, when the service recovery has not been able to obtain the lock, so you need to add a column in the table, to record the failure time, and need to have a timed task to clear these failed data.

4 "does not have the blocking lock feature, get the lock directly return failure, so need to optimize the acquisition of logic, loop multiple to get.

Pros: With a database, the solution is simple

Disadvantage: In the actual implementation of the process will encounter a variety of problems, in order to solve these problems, the implementation of the way will be more and more complex, dependent on the database requires a certain amount of resource overhead, performance issues need to be considered.

The implementation method 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, use the DEL command to release the distributed lock, but this implementation has the following problems:

1 "setnx command after setting up Key-value, has not been able to use the expire command to set the expiration time, the current thread hangs, will cause the current thread set key has been valid, the subsequent thread can not normally get the lock through SETNX, resulting in a deadlock.

2 "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 can cause unpredictable problems.

3 "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 cause multiple machines of multiple threads to acquire the same lock,

For these problems, there are some solutions:

1, the first problem is because two commands are executed separately and do not have atomic characteristics, if the two commands can be combined to solve the problem, in the Redis2.6.12 version of this feature, Redis added a series of options for the set command, 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_time", which is a random value that must be unique across all machines for a secure release lock.

2, in order to solve the second problem, the use of "My_random_value", when releasing the lock, only the key exists and the stored "my_random_time" value is the same as the specified value to execute the DEL command, this process can be implemented by the following LUA script:

If Redis.call ("Get", keys[1]) = = Argv[1] then       return Redis.call ("Del", Keys[1])
else       return 0end

3, the third problem is due to the use of master-slave replication, the solution is not to use the master-slave replication, using the Redlock algorithm, here refers to a section of the online description of the Redlock algorithm.

In a REDIS distributed environment, assuming that there are 5 Redis master, these nodes are completely independent of each other, there is no master-slave replication or other cluster coordination mechanism, in order to take the lock, the client should do the following:

1 "Gets the current Unix time, in milliseconds,

2 "in turn, try to get the lock from N instances, using the same key and random values, in step 2, when the lock is set to Redis, the client should set a network connection and response time-out time, this time-out should be less than the lock expiration time, for example, your lock auto-expiration time is 10 seconds, The time-out should be between 5-50 milliseconds, so that the client is still waiting for the results of the response if the server-side Redis has been hung out. 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 acquired, and the lock was successful only if the lock was acquired from most redis nodes and the time used was less than the lock failure time.

4 "If a lock is taken, the true effective time of key is equal to the effective time minus the time used to acquire the lock (the result of step 3)

5 "If, for some reason, the acquisition lock fails (not having at least N/2 + 1 Redis instances take 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).

A high-efficiency, highly available distributed lock can be achieved through the above solution, where a mature, open-source distributed lock implementation, Redisson, is recommended.

Advantages: High performance, easy to achieve with Redis

Disadvantage: After a thread acquires a lock, it is not very reliable to pass the lock timeout mechanism if the processing time is too long to invalidate the lock timeout.

Implementation method based on zookeeper

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

1. Create a directory Mylock

2, thread A wants to get the lock in the Mylock directory to create a temporary order node

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, judging themselves is not the smallest node, set to listen to the node smaller than its own

5, thread A processing, delete their own nodes, thread B to hear the change event, determine whether they are the smallest node, if it is to obtain a lock,

It is recommended that an Apache open Source Library curator, it is a zookeeper client, curator provides the Interprocessmutex is the implementation of distributed locks, acquire method is used to obtain the lock, release method for releasing the lock,

Advantages: High availability, reentrant, blocking lock feature, can solve the failure deadlock problem,

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

The three implementations above are not perfect on all occasions, so you should choose the most appropriate implementation based on the different application scenarios.

Distributed locks that thing