[Zookeekper distributed lock]

Ordered nodes: If the current node has a parent / lock, we can create a child node in the parent node below; zookeeper provides an optional order characteristic, for example, we can create a child node "/ lock / node-" and specified order, then the child nodes zookeeper when generating the integer number is automatically added based on the current number of sub-nodes, that is to say if a child node created first, then the child nodes is generated / lock / node-0000000000, the a node was / lock / node-0000000001, and so on.
Temporary nodes: the client can establish a temporary node, at the end of the session or the session times out, zookeeper will automatically delete the node.
Event listeners: When reading the data, we can set the node while an event listener, when the node data or structural changes, zookeeper will notify the client. Current zookeeper following four events: 1) create a node; deleted 2) node; 3) the node data modification; 4) the child nodes changes.

The following description uses a distributed algorithm steps zookeeper lock, the lock space is assumed root / lock:

ZooKeeper client connections, and creating in / lock temporary and orderly child node, the first child node of a corresponding client / lock / lock-0000000000, the second is / lock / lock-0000000001, thereby analogy.
Client gets list of child nodes under / lock, judging sub-node that you create is the current list of child nodes with the minimum number of child nodes, if it is considered to obtain a lock, or monitor the child node / lock change message, get the child nodes after repeating this step until a change notification to acquire the lock;
Business code execution;
After the completion of business processes, delete the corresponding child node releases the lock.

Temporary node created in step 1 to ensure that the lock can be released in case of a failure, consider such a scenario: If the client after a child node created for the current node with the smallest number, obtaining a lock down the client machine where the client did not initiate the child is removed; if you create a permanent node, the lock will never be released, resulting in a deadlock; because the creation of a temporary node client after downtime, and after a certain period of time has not received zookeeper the client heartbeat packet judging session expires, will be removed in order to release the lock temporary node.

Further careful people may think of, obtaining a list of the child node issue atoms provided this two-step operation monitor in step 2, considering such a scenario: the client corresponding to a child node / lock / lock-0000000000, the client b corresponding sub-node / lock / lock-0000000001, the client b found minimal that they are not the serial number is acquired list of child nodes, but before setting listener client a complete business process removed child node / lock / lock-0000000000, the client b set the end listener would not be lost forever waiting for this event leading up? This problem does not exist. Because the API zookeeper provided set listener operation and a read operation is atomic execution , that set the listener at the same time when reading list of child nodes, guaranteed not to lose the event.

Finally, for the optimization algorithm has a great point: If the current node in 1000 while waiting for a lock, the lock is released if the client to acquire a lock, the 1000 client will be awakened, a condition called "herd effect "; in this herding in, zookeeper need to be notified 1,000 clients, which can block other operations, the best case should only wake up the new minimum node corresponding client. What should I do? When you set up event listeners, each client should be set up for the child nodes event just prior to its listeners, such as child nodes list is / lock / lock-0000000000, / lock / lock-0000000001, / lock / lock-0000000002, serial number listening to the client child node number 0 1 deletion message, serial number of the listener 2 is a child node of the deletion message.

So Distributed Lock algorithm flow adjusted as follows:

ZooKeeper client connections, and creating in / lock temporary and orderly child node, the first child node of a corresponding client / lock / lock-0000000000, the second is / lock / lock-0000000001, thereby analogy.
Client obtains a list of child nodes under / lock, determine whether the child nodes that you create for the current list of child nodes smallest number of child nodes, if it is considered to obtain a lock, or monitor the child node just before one of their own deleted messages after obtaining sub-node change notification repeat this step until a lock is obtained;
Business code execution;
After the completion of business processes, delete the corresponding child node releases the lock.

Curator achieve

<dependency>
    <groupId>org.apache.curator</groupId>
    <artifactId>curator-recipes</artifactId>
    <version>4.0.0</version>
</dependency>

static void main public (String [] args) throws Exception { 
    // create a client zookeeper 
    RetryPolicy retryPolicy new new ExponentialBackoffRetry = (1000,. 3); 
    CuratorFramework Client CuratorFrameworkFactory.newClient = ( "10.21.41.181:2181,10.21.42.47:2181 , 10.21.49.252: 2181 ", retryPolicy); 
    client.start (); 

    // create a distributed lock, lock space for the root path / Curator / lock 
    InterProcessMutex mutex = new new InterProcessMutex (Client," / Curator / lock ") ; 
    mutex.acquire (); 
    // get the lock, business process 
    System.out.println ( "the Enter mutex"); 
    // complete business processes, release the lock 
    mutex.release (); 
    
    // close the client 
    client.close (); 
}

Excerpt from: http://www.dengshenyu.com/java/%E5%88%86%E5%B8%83%E5%BC%8F%E7%B3%BB%E7%BB%9F/2017/10/ 23 / zookeeper-distributed-lock.html

[Zookeekper distributed lock]

Curator achieve

Guess you like