Zookeeper Distributed lock implementation principle

This paper mainly describes how to effectively avoid the emergence of "herd effect (herd effect)" in the implementation of distributed locks using zookeeper.

Personal comments, non-reproduced: herd effect in the zookeeper document also has the description: Https://zookeeper.apache.org/doc/trunk/recipes.html#sc_recipes_GuidNote

One node changes, causing all other nodes to change, where a node changes, and all nodes may receive watcher notifications.

General implementation of distributed locks

Here's a simple way to tell how a generic distributed lock is implemented. The specific code implementation can be seen here: https://svn.apache.org/repos/asf/zookeeper/trunk/src/recipes/lock/

As mentioned in the previous article in the Zookeepe data model, there are 4 types of nodes created in zookeeper, where we focus on the temporary sequential nodes. This type of node has several features:

1. The node's lifecycle and client session bindings, that is, if the client session that created the node fails, the node is also purged.

2. Each parent node is responsible for maintaining the order in which the child nodes are created, and if a sequential node (sequential) is created, the parent node automatically assigns an integer value to the node, and the suffix is appended to the node name automatically as the end node of the nodes.

Using these two features, let's take a look at the basic logic for implementing a distributed lock:

1. The client calling the Create () method creates a node named "_locknode_/guid-lock-", and it is important to note that the creation type of the node here needs to be set to ephemeral_sequential.

2. The client invokes the GetChildren ("_locknode_") method to obtain all the child nodes that have been created, while registering the Watcher of the child node change notification on this node.

3. After the client obtains the path to all child nodes, if it finds that the node you created in step 1 is the smallest ordinal in all nodes, the client is considered to have acquired a lock.

4. If you find in step 3 that you are not the smallest of all child nodes, stating that you have not acquired the lock, start waiting until the next second son node change notification, then the child node acquisition, determine whether to acquire the lock.

The process of releasing a lock is relatively straightforward, which is to delete the child node that you created.

The problem lies

In the implementation of the above distributed lock, we can generally meet the demand of the general distributed cluster Competition lock. The general scenario here is that the cluster size is small, typically within 10 machines.

However, to think about the implementation logic above, we can easily find a problem, step 4, "Get all the sub-points, determine whether the node you created is already the smallest node", this process, in the entire distributed lock competition process, a large number of repeated operations, And the vast majority of the running result is to determine that they are not the smallest number of nodes, so continue to wait for the next notification-this obviously does not look very scientific. The client is unnecessarily accepting excessive and self-unrelated event notifications, which can have a significant performance impact on the server if the cluster is large, and if a client with multiple nodes at the same time disconnects, the server will send a large number of event notifications like the rest of the clients- This is called the herd effect. The root of the problem is that there is no real concern for the client.

Let's look back at the distributed lock competition process above, and its core logic is to determine whether it is the smallest number in all nodes. Therefore, it is easy to associate that the creator of each node only needs to focus on the node that is smaller than its own sequence number.

An improved distributed lock implementation

The following is the improved distributed lock implementation, and the previous implementation of the only difference is that this design as each lock competitor, only need to pay attention to the "_locknode_" node under the number of its own small node exists. The implementation is as follows:

1. The client calling the Create () method creates a node named "_locknode_/guid-lock-", and it is important to note that the creation type of the node here needs to be set to ephemeral_sequential.

2. The client calls the GetChildren ("_locknode_") method to get all the child nodes that have been created, note that no watcher is registered here.

3. After the client obtains the path to all child nodes, it is assumed that the client acquires a lock if it finds itself to be the smallest node ordinal created in step 1.

4. If you find that you are not the smallest of all child nodes in step 3, you have not acquired the lock. At this point the client needs to find the node that is smaller than itself and then call the exist () method, registering the event listener.

5. The client will then receive a notification when the node being followed is removed. This time the client needs to call the GetChildren ("_locknode_") method again to get all the child nodes that have been created, make sure that it is the smallest node, and then go to step 3.

Conclusion

The last two distributed lock implementations are feasible. The specific choice depends on the size of your cluster.

Reprint from @ni shopkeeper

This article is from the "NI shopkeeper's It column" blog, be sure to keep this source http://nileader.blog.51cto.com/1381108/961809