Implementation of distributed locks based on Redis and zookeeper

First of all, to say what is a distributed lock, simply speaking, distributed lock is in the distributed concurrency scenario, the ability to implement multi-node code synchronization mechanism. From the implementation point of view, there are two main ways: based on the Redis approach and based on the zookeeper approach, the following are briefly described below the following two ways:

A, Redis-based distributed lock implementation

1. Get the Lock

Redis is a key-value form of NoSQL database that is often used as a server cache. Starting with Redis v2.6.12, the SET command begins to become the following format:

SET key value [EX seconds] [PX milliseconds] [nx| XX]

In addition to key and value, ex is the timeout period, and NX indicates that the value of key is set only when key does not exist, and XX indicates that the value of key is set at the time the key exists. The NX mechanism is based on the core of the Redis distributed lock. Can solve the following problems:

1) Node 1 gets the key and sets the time-out to hang up before it can be released-the ex timeout takes effect and the lock is automatically released after timeout.

2) Just get to the lock, not yet set the timeout time to hang up-here set the key and set the timeout time is atomic operation, if this happens, will return 0, that is, the lock is not acquired.

2. Release the lock

Lua scripting is often used to solve problems caused by non-atomic operations. The operation of the Lua script is considered to be atomic, similar to a transaction. The pseudo code is as follows:

Second, the implementation of distributed lock based on zookeeper

Zookeeper is a distributed coordination service in which each node is called Znode and has its own independent path. There are four types of Znode:

Persistent node: The default node type. The node still exists after the client that created the node disconnects from zookeeper.

Persistent node Order node: the so-called sequential node, that is, when the node is created, zookeeper the node name according to the time order created:

Temporary nodes: In contrast to persistent nodes, temporary nodes are deleted when the client that created the node disconnects from zookeeper:

Temporary order nodes: the characteristics of union and temporal nodes and sequential nodes: When creating a node, zookeeper the node name according to the time order created, and when the client that created the node disconnects from zookeeper, the temporary node is deleted.

Here's how to implement a distributed lock based on the above four class of nodes.

1. Get the Lock

1) Create a persistence section in zookeeper, and when the first client Client1 wants to acquire a lock, it needs to create a temporary order node below the node.

2) Client1 Find all the temporary order nodes below the persistent node and sort them, and determine if the node you created is the most forward one in the order. If it is the first node, a lock is successfully obtained.

3) If there is another client Client2 to get the lock, then create a temporary order node Lock2 under the persistent node.

4) Client2 Find all the temporary order nodes below the persistent node and sort them, judging if the node Lock2 is the first one in the order, the result is that the node Lock2 is not the smallest.

Thus, Client2 only registers watcher with the LOCK1 node, which is used to monitor the presence of LOCK1 nodes. This means that the Client2 lock failed and entered the waiting state.

5) If there is another client Client3 to get the lock, then create a temporary order node Lock3 on the persistent node download.

Client3 finds all the temporary order nodes under the persistent node and sorts them, judging if the node Lock3 is the first one in the order, and the result also finds that the node Lock3 is not the smallest.

Thus, CLIENT3 only registers watcher with the Lock2 node, which is used to monitor the presence of LOCK2 nodes. This means that the CLIENT3 also steals the lock and goes into a wait state.

2. Release the lock

Releasing the lock is easier because the temporary order node created earlier will automatically release the lock when the following two cases occur:

1) When the task is completed, the client releases the lock.

2) When the task is not completed, the client crashes and the lock is automatically released.

Like small make up a little bit of attention!

Implementation of distributed locks based on Redis and zookeeper