Zookeeper Typical application scenario analysis

Zookeeper realizes the function of active notification node change, atom creation node, temporary node, and order creation node. Through the combination of the above functions,
Zookeeper can combine many of the upper-level functions in a distributed system. Here are a few of the commonly used scenarios, and how to use and precautions.

Name Service (Nameservice)

As the name implies, to the resources in the distributed system, users can easily understand the name, to find the resources needed. For example: A unified interface system that receives the service and then transfers it to the backend service's specific server. When the interface is added, the requester can simply pass the name of the new interface, the system will be able to find the corresponding server by name, discover the service and forward the request.

In zookeeper, according to the naming rules, set up the corresponding directory level, for example,/company/team/service can find a company, a team under the delivery of a service path. When a new business is launched, the service finds its own name in the ZK node, establishes a temporary node, and writes configuration information. When used by the caller, the unified interface queries the node under the corresponding directory and selects the appropriate read configuration. When the business down, directly delete the service, temporary node automatically deleted, the service automatically off.

Configuration management (config Management)

Distributed systems are located in different host services, sometimes using a unified configuration. Configuration data can be stored in the Znode node in the zookeeper, each client monitors (watch) Znode changes, and when the configuration changes, the push is notified, and then the individual clients pull the new configuration.

Note: ZK's watch is a one-time, and the client will re-watch after reading and check if it is the latest version.

Member Management (Group membership)

In master, slave mode, master needs to know what slave are available, and how to synchronize. Also need to know in time which slave died, and then to do the corresponding treatment. The practice is that master first set up a/slave node, each slave on-line when the/slave to establish a temporary node, write configuration, the server monitors the/slave node, the increase or disappearance of the node corresponding processing.

The above three kinds of usage belong to the Configuration class service, configure according to certain rules, need to read the configuration of local monitoring configuration changes.

Simple lock

Each process creates a lock znode under/lock and Watch/lock, only one is created successfully, when a successful process releases the lock or the stop timeout notifies other processes to re-enter the mechanism of the competitive lock.

Mutex lock (Simple lock without herd Effect)

In order not to trigger the surprise group effect, as long as the competition process can be ordered, each process in the/lock node to create a znode with serial number, and each znode only listen to the node smaller than his second, when the small node release lock, than his second-largest node will be notified, get lock permissions.

Note: Prevent processes that have not yet been executed to die, to update the listening sequence. For example: 2 monitoring 1,3 monitoring 2, if the 2 process to die prematurely, 3 to monitor this state, determine whether it is 2 off, or 2 release lock, if not normal shutdown, to monitor the 1 update monitoring.

Read/write Lock (Read/write lock)

Read-Write Locks: Multiple reads can be executed concurrently, but write and read, write and write cannot be performed concurrently.
Change the mutex scheme, if it is a write lock, listen to his minor node, the second bar to release the lock, write lock detection if there is a smaller node, if there is continued monitoring, if there is no write lock execution , if it is read lock, listen to the left largest write lock, when the write lock is released after the read lock.
Also pay attention to the middle node dead early release of the problem, to re-listen to the node.

Barrier (Barrier)

In a distributed system, a barrier is a semantic: The client waits for multiple processes to complete its task before proceeding to the next step.
For example, the early morning backup, waiting for each process to put the data dump end, then package compression pass away.

The client sets the Znode of the/mybarrier and then starts each process, and after each process execution finishes successfully, the Znode node is created under/mybarrier, and the client discovers that the node number under/mybarrier is reached before continuing with the following tasks.

Dual barrier (double Barrier)

A double barrier is a semantic: it can be used to synchronize the beginning and end of a task, and when enough of the processes have entered the barrier, the task is started, and the barrier is withdrawn when all the processes have completed their respective tasks.

Ingress barriers: Create/ready and/process nodes, each process is registered in ready, and when the number of registrations reaches the required level, all processes are notified to start execution.
Leave the Barrier: The process of registering ready is established under/process, and the corresponding node under/process is deleted after each process execution is completed. When the/process is empty, the task is all over.

Locks, barriers, essentially sorts, sorts the nodes to be used, executes the policy according to the order, and guarantees that execution does not conflict.

Summarize

The above application scenario, not only ZK can achieve, and the way of implementation is also common, in exchange for other components, as long as the notification and atomic creation, self-increment ID, can achieve the use of these scenarios. And the method of implementation is universal, not only in ZK.
In essence, the unified configuration notification mechanism, and the atomic resume self-increment ID node sorting mechanism, to achieve the configuration class and lock class coordination function.

Reference

"Zookeeper Principle and use" http://www.wuzesheng.com/?p=2609

Zookeeper Typical application scenario analysis