This paper describes the use of distributed lock ZooKeeper implementation process, how to effectively avoid the "herding (herd effect)" is.
Distributed Lock general realization
How to achieve under normal distributed lock here simply speaking. Specific code implementation can be seen here: https://svn.apache.org/repos/asf/zookeeper/trunk/src/recipes/lock/
We mentioned in the previous "ZooKeepe data model," an article before, create the type of nodes zookeeper has four categories, here we focus on a temporary order of nodes. This type of node has a few several features:
Life cycle and the client node session binding, is to create a client node session once spent, then the node will be cleared.
Each parent will be responsible for maintaining order in its child nodes created, and if you create a sequence of nodes (SEQUENTIAL), then the parent node is automatically assigned an integer value for this node, in the form of the suffix is automatically appended to the node name, as the final node node name.
Using the above two features, the basic logic implementation of a distributed lock acquisition we look at:
Create a file named "client calls create () method locknode node / guid-lock-", you need to pay attention to is to create a type of node here needs to be set EPHEMERAL_SEQUENTIAL.
The client calls the getChildren ( " locknode ") method to get all the child nodes have been created, but registration on the child node change Watcher notice on this node.
After the client gets to all child nodes path, if you find yourself node created in step 1 is the smallest number of all nodes, then consider the client to get a lock.
If it is found that they are not in step 3 is the smallest of all the child nodes, indicating that he still did not get the lock, it waits until the next time the child node change notification, and then get the child node to determine whether to acquire the lock.
Lock release process is relatively simple, is to remove the child node can create yourself.
problem lies in
Distributed Lock implementation above this, the general can meet the needs of general cluster distributed lock contention. Here that means the general scene is small cluster size, generally less than 10 machines.
However, on reflection realize the above logic, we can easily find a problem, step 4, "that is to get all of the sub-points, to determine whether the node itself has created the smallest node number", this process throughout the distributed lock the competitive process, a large number of repeat run, and the vast majority of operating results are judged he was not the smallest node number, so the next time to continue to wait for notification - this apparently does not look very scientific. The client receives excessive and gratuitous own events not related to notice, that if a large-scale cluster when Server will significantly affect performance, and if there are multiple nodes at the same time once the client disconnects connection, this time, the server will send a large number of event notifications like the rest of the client - this is called herding. The root of the problem is that not identify the true client focus.
Let's look at the top of a distributed lock contention procedure, its core logic is: all nodes to determine if they are the smallest numbers. So, it is easy to think of is the creator of each node only need to focus on that node smaller than their number.
Distributed Lock achieve improved
Here is distributed lock improved realization, and before implementation only difference is that each lock designed here as a competitor, just need to focus on " locknode whether the next" node number smaller than its own existence to that node. To achieve the following:
Create a file named "client calls create () method locknode node / guid-lock-", you need to pay attention to is to create a type of node here needs to be set EPHEMERAL_SEQUENTIAL.
The client calls the getChildren ( " locknode ") method to get all the child nodes have been created, note that this does not register any Watcher.
After the client gets to all child nodes path, if we find the smallest node number that you have created in step 1, then that the client obtains a lock.
If you find yourself not the least of all the child nodes in Step 3, indicating that he still did not get the lock. At this time the client needs to find the node is smaller than its own, then it calls the exist () method, and register event listeners.
After When this node is of interest is removed, the client will receive a corresponding notification. This time the client needs to call again the getChildren ( " locknode ") method to get all the child nodes that have been created to ensure that you are indeed the smallest node, and then proceed to step 3.
in conclusion
Last two locks for distribution, are feasible. The specific choice of which depends on the size of your cluster.
Forwarding from: http://rdc.taobao.com/team/jm/archives/tag/zookeeper