Zookeeper is now a very mature distributed coordination framework. As a framework to ensure CP, ZK meets many business scenarios and has quite good reliability. So how does ZK accomplish these tasks?
First, ZK was born to coordinate distributed services, in the official definition
A Distributed Coordination Service for Distributed Applications
A distributed coordination framework for distributed applications.
In fact, the function of ZK is very simple, ZK itself maintains a similar directory structure of the node system, providing the ability to listen to these nodes.
Okay, that’s it. Doesn’t it look easy?
Speaking of nodes alone, ZK provides four different types of nodes for callers to use.
- Persistent node
- Temporary node
- Persist sequential nodes
- Persist temporary nodes
Monitoring ability is also divided into monitoring the change of a node, monitoring the change of a node’s child nodes, etc.
With the combination of these two basic capabilities, we can play a lot of tricks. For example, if we need a distributed ID, we can simply have different servers register temporary nodes on ZK, and the sequence of registered nodes can be used as a distributed unique ID.
Again, for example, we will implement a distributed lock, also can let resources through competition to register temporary node on the zk, registration of the caller, it got the lock, and other caller to monitor the change of the temporary node, if temporary node disappear, then to preempt the registered temporary node, completes the implementation of a distributed lock.
Other distributed scenarios, such as master election, service registration, shared lock, etc., can be well solved by the form of node plus listening. Therefore, from today, we will open a new pit to sort out and summarize the related knowledge of ZK.