This is the 17th day of my participation in the August Text Challenge.More challenges in August

preface

If you take a look at Zookeeper, there are many services that rely on Zookeeper for their functionality. Dubbo uses Zookeeper as its registry, Kafka uses Zookeeper as its implementation, Zookeeper can also be used to implement distributed locks

Therefore, systematic learning of Zookeeper is an essential part and a necessary basic skill


Introduction to the

ZooKeeper is an open source distributed coordination service. Its design goal is to encapsulate the complex and error-prone distributed consistency services into an efficient and reliable set of primitives, and provide users with a series of easy-to-use interfaces

ZooKeeper provides us with a high availability, high performance and stable distributed data consistency solution. Meanwhile, because Zookeeper stores data in memory, performance is very good, especially if the data is read more than write, because the write causes the service cluster to enter the synchronization state

Zookeeper has the following features:

  • Sequential consistency: Transaction requests from the same client are eventually applied to ZooKeeper in a strict order.
  • Atomicity: The processing results of all transaction requests are applied consistently across all machines in the cluster, that is, a transaction is either successfully applied across all machines in the cluster or not applied at all
  • Single system image: The client sees the same server-side data model no matter which ZooKeeper server it is connected to
  • Reliability: Once a change request is applied, the result of the change is persisted until overwritten by the next change

Common Zookeeper applications:

  1. Distributed lock: A distributed lock is obtained by creating a unique node, which is released when the party that acquired the lock finishes executing the code or hangs
  2. Naming service: Generates globally unique ids from ZooKeeper’s sequential nodes
  3. Publish/subscribe data: The Watcher mechanism makes it easy to publish/subscribe data. When you publish data to a monitored ZooKeeper node, other machines can dynamically update the configuration by listening for changes in ZooKeeper nodes


1. Zookeeper data model

Let’s start with the next model:

Look at this model, isn’t it familiar? It smells like Linux!

Zookeeper uses a multi-fork tree structure similar to Linux file system paths:

  1. The uppermost node root node is used/Represents that each node in Zookeeper is calledZNode, its path is unique and the smallest data unit in Zookeeper
  2. All nodes can hold data, which can be arrays, strings, or binary sequences
  3. Zookeeper is mainly used to coordinate services rather than store data. Therefore, the storage limit of ZNode is set to 1 MB


2. Four types of ZNodes

  1. Persistent node: Once created, it persists until it is manually removed
  2. Temporary node: the temporary node is bound to the session of the client. It can be understood that whoever gets it out, pulls up his pants and walks away, then the node will commit suicide. Temporary nodes can only be leaf nodes and cannot create child nodes
  3. Persistent order node: In addition to having the properties of persistent nodes, children also have sequential properties, such as/node1/001,/node2/002
  4. Temporary order nodes: In addition to having the features of temporary nodes, temporary order nodes with the same name are automatically numbered


3. Main components of a ZNode

  1. stat: Node status, which can be passed on the clientstatCommand to obtain node status information
  2. data: Data stored on a node can be passed by the clientgetCommand to retrieve the data stored in the node

Ex. :

[zk: localhost:2181(CONNECTED) 5] create /abc
Created /abc
[zk: localhost:2181(CONNECTED) 6] get /abc
null
[zk: localhost:2181(CONNECTED) 7] stat/abc cZxid = 0x21b ctime = Wed Aug 18 15:00:19 CST 2021 mZxid = 0x21b mtime = Wed Aug 18 15:00:19 CST 2021 pZxid = 0x21b  cversion = 0 dataVersion = 0 aclVersion = 0 ephemeralOwner = 0x0 dataLength = 0 numChildren = 0Copy the code

Node status meaning:


4. The Zookeeper cluster

To ensure high availability, it is best to deploy ZooKeeper in a cluster with an odd number of machines (usually three to form a cluster), so that ZooKeeper itself is still available as long as most of the machines in the cluster are available

In the cluster architecture diagram of Zookeeper, each Server represents a Zookeeper instance. Data consistency is maintained between clusters through the Zookeeper Atomic Broadcast (ZAB) protocol


4.1 Roles between Clusters

role instructions
Leader Provide clients with read and write services, responsible for the initiation and resolution of voting, update system status.
Follower The read service is provided for the client, and if it is a write service, it is forwarded to the Leader. To vote in the election process.
Observer The read service is provided for the client, and if it is a write service, it is forwarded to the Leader. Do not vote in the election process and do not participate in the “write half success” strategy. Improves the read performance of the cluster without affecting the write performance. This role is a new role in ZooKeeper3.3 series.

4.2 Cluster Leader Election Process

When Leader problems occur in the cluster, such as network interruption, server downtime, etc., the Leader election will be triggered:

  1. Election stage: All nodes are in the election stage at the beginning, and the condition for a quasi-leader is that a node obtains more than half of the votes of nodes, but he is not a real Leader at this time
  2. Discovery phase: During this phase, the Followers communicate with the quasi-leader to synchronize the transaction proposals that the Followers have recently received
  3. Synchronization phase: The synchronization phase mainly uses the latest proposal history obtained by the leader in the previous phase to synchronize all copies in the cluster. The would-be Leader becomes a real Leader only after synchronization is complete
  4. At this stage, the ZooKeeper cluster can officially provide transaction services and the Leader can broadcast messages


4.3 Why Is the Number of Cluster Instances An Odd Number

The Zookeeper cluster provides external services as long as the number of surviving instances is greater than N /2, which is also called the half-way mechanism

Suppose there are three instances in a cluster, and their tolerance is one failure, but four instances have the same tolerance as three, so why add an unnecessary Zookeeper?

And the half mechanism can prevent the occurrence of split brain

What is split brain?

For a cluster, multiple machines are usually deployed in different rooms to improve the availability of the cluster. At the same time of ensuring availability, a kind of network line failure occurs between rooms, resulting in the network failure between rooms, and the cluster is split into several small clusters. In this case, the subsets individually choose the principal leading to the “split brain” situation

The half mechanism of ZooKeeper makes it impossible to produce two leaders, because it is impossible to produce leaders less than half, which makes brain split impossible no matter how machines are allocated in the machine room


5. To summarize

  1. Zookeeper is a distributed service. As long as more than half of the nodes survive, external services can be guaranteed
  2. Zookeeper stores data in memory and performs very well, especially when more data is read than written, because writes cause service clusters to be synchronized
  3. ZooKeeper actually only provides two functions at the bottom: one is to manage (store and read) the data submitted by user programs; The other is to provide data node monitoring service for user programs
  4. Zookeeper provides the concept of temporary nodes, which can only be leaf nodes and do not allow child nodes