This is the back-end small class of the monastery. Each article is shared from

[background introduction] [knowledge analysis] [common problems] [solutions] [coding practice] [extended thinking] [more discussion] [References]

Eight aspects of in-depth analysis of back-end knowledge / skills. This article shares:

[simple use of zookeeper]

[Java class of Xiuzhen academy] simple use of zookeeper

Hello, I'm the 11th java student of Zhengzhou branch of it Academy. I'm an honest, pure and kind java programmer.

Today, I'd like to share with you the simple use of zookeeper.

1. Background introduction

Zookeeper is a distributed, open-source distributed application coordination service, which is composed of client and server. Server provides consistent replication and storage services. Client contains a simple primitive set. Distributed applications can realize synchronization services, configuration maintenance and naming services based on it. It is the manager of the cluster. It uses the tree data structure to monitor the status of each node in the cluster and carry out the next reasonable operation according to the feedback submitted by the node. Finally, the simple and easy-to-use interface and the system with efficient performance and stable function are provided to users.

2. Knowledge analysis

Server role

1) Leader: the leader can accept client requests and write requests forwarded by other servers, and is responsible for updating the system status. 2) Follower: it can receive client requests. If it is a write request, it will be forwarded to the leader to update the system status. 3) Observer: the only difference between observer and follower is that it does not participate in the main selection process.

Broadcasting mechanism

The core of zookeeper is atomic broadcasting, which ensures the synchronization between servers. The protocol that implements this mechanism is called the Zab protocol. Zab protocol has two modes: recovery mode and broadcast mode. When the service starts or the leader crashes, Zab enters the recovery mode. When the leader is elected and most servers are synchronized with the leader's state, the recovery mode ends. State synchronization ensures that the leader and server have the same system state.

Session mechanism

After the client successfully connects to the server, the server gives the client a sessionid. The client needs to continuously send heartbeat to keep the session valid. During the session validity period, it can operate using the API provided by zookeeper. If the client cannot send heartbeat normally for some reason, after the timeout, the server will judge that the client's session is invalid. At this time, any operation sent by the client will be rejected and an expiredexception exception will be triggered. At this time, the keeperstate is in the expired state However, the client has the mechanism of automatically reconnecting to the server. If the client's heartbeat cannot connect to the server normally, it will try to connect to other servers before the session timeout. After the connection is successful, it can continue to operate.

uniformity

1) Suppose there are 2n + 1 servers. In the synchronization process, the leader synchronizes data to the followers. When the number of followers completed synchronization is greater than N + 1, the synchronization process ends and the system can accept the connection request of the client. If the client is not connected to a synchronized follower, the latest data is not obtained, but monotonicity can be guaranteed. 2) After receiving the write request, the follower forwards it to the leader for processing; The leader completes the mechanism of two-stage submission. Initiate a proposal to all servers. When the proposal is approved by more than half (n + 1) of the servers, the whole cluster will be synchronized. After more than half (n + 1) of the servers are synchronized, the write request will be completed. If the client is connected to a follower that is not synchronized, the latest data will not be obtained, but monotonicity can be guaranteed.

Watch mechanism

1) Zookeeper supports a watch operation. The client can set a watch on a znode to watch the changes on the znode. If there is a corresponding change on the znode, the Watcher will be triggered and the corresponding event will be notified to the client setting the watcher. 2) The watcher in zookeeper is one-time, that is, the trigger will be cancelled once. If you want to continue the watch, you need to reset the watcher on the client.

3. Frequently asked questions

1) Implementation principle of zookeeper load balancing 2) specific configuration and implementation of zookeeper pseudo cluster

4. Coding practice

5. Expand thinking

Zookeeper design purpose

1) Consistency: no matter which server the client is connected to, it is shown to be the same view, which is the most important performance of zookeeper. 2) Reliability: it has simple, robust and good performance. If the message M is accepted by one server, it will be accepted by all servers. 3) Real time: zookeeper ensures that the client will obtain the update information of the server or the information of server failure within a time interval. However, due to network delay and other reasons, zookeeper cannot guarantee that two clients can get the newly updated data at the same time.

4) Wait free: slow or failed clients shall not interfere with fast client requests, so that each client can wait effectively. 5) atomicity: updates can only succeed or fail without intermediate status. 6) Sequencing: including global ordering and partial ordering: global ordering means that if message a is published before message B on one server, message a will be published before message B on all servers; Partial order means that if a message B is published by the same sender after message a, a must be ahead of B.

Asynchronous watcher processing

The implementation principle of zookeeper's watcher is also very simple, that is, a corresponding watcher object is saved on both zookeeper client and zookeeper server. Each zookeeper machine will have a complete node tree data and watcher data. Every time the leader notifies the follower / observer that the data has changed, each zookeeper server will push it to the responding zookeeper client according to the watcher event in its own node. After each ZK client receives it, it will call back according to the watcher reference in memory

6. References

7. More discussion

1) ZYQ: what is the main process of zookeeper selection?

Zhh: election at server startup: each server sends a vote, accepts votes from each server, processes votes, counts votes, and changes the server state.

During server operation: there is one more link than the above and the beginning to change the server state.

2) Wyq: the difference between spring cloud Eureka and zookeeper

Zhh: Eureka follows the AP principle, zookeeper follows the CP principle, C: consistency, a: availability, P: partition fault tolerance

3) HS: are notifications received for every node change? reason?

HS: if the update frequency of node data is very high, it cannot be. The reason is: when the client is notified of a data modification, the client registers the watch again. In this process, the data may have been modified many times. Therefore, do not do such a test: "if the data is modified n times, you will receive n notifications" to test whether the server works normally.

Ppt link video link