Shulou(Shulou.com)06/02 Report--

Today, I would like to talk to you about how to analyze the principle of zookeeper. Many people may not know much about it. In order to make you understand better, the editor has summarized the following contents for you. I hope you can get something according to this article.

I. the role of zookeeper

1. Leader (leader): responsible for initiating and deciding the vote and updating the system status.

two。 Learner (learner): including follower (follower) and observer (observer).

3. Follower (follower): used to accept the client's request and return the result to the client, and participate in the voting during the election process.

4. Observer (observer): you can accept client connections and forward write requests to leader, but observer does not participate in the voting process and only synchronizes the status of leader. The purpose of observer is to expand the system and improve the reading speed.

5. Client (client): request initiator.

II. Election mechanism

The core of Zookeeper is atomic broadcasting, which ensures synchronization between Server. The protocol that implements this mechanism is called the Zab protocol. There are two modes of Zab protocol, which are reply mode (primary mode) and broadcast mode (synchronization). When the service starts or the leader crashes, the Zab enters recovery mode, and when the leader is elected and most of the Server finishes synchronizing with the status of the leader, the recovery mode ends. State synchronization ensures that leader and Server have the same system state.

In order to ensure the order consistency of transactions, zookeeper uses an incremental transaction id number (zxid) to identify transactions. All proposals (proposal) are made with zxid when they are made. In the implementation, zxid is a 64-bit number, and its high 32-bit epoch is used to identify whether the leader relationship has changed. Each time a leader is selected, it will have a new epoch, indicating which leader period it currently belongs to. The lower 32 bits are used to increment the count.

There are three states during the operation of each Server:

LOOKING: currently Server doesn't know who leader is and is searching for it.

LEADING: the current Server is the selected leader.

FOLLOWING: leader has been elected, and the current Server is synchronized with it.

Suppose you have a Zookeeper cluster of five servers with an id of 1-5, and they are all newly started, that is, there is no historical data, and they are all the same in terms of the amount of data stored. Assuming that these servers start in order, let's see what happens, as shown in the figure.

1. Server 1 starts, at this time, only one server is started, and the messages it sends out do not respond, so its election status has always been LOOKING.

two。 Server 2 starts, and it communicates with server 1, which started at first, and exchanges its election results with each other. Since neither server has historical data, server 2 with a higher id value wins, but since not more than half of the servers agree to elect it (more than half of the servers in this example are 3), servers 1 and 2 continue to maintain the LOOKING state.

3. Server 3 starts, and according to the previous theoretical analysis, server 3 becomes the leader of server 1, 2, and 3, but unlike the above, three servers elected it, so it became the Leader of this election.

4. Server 4 starts, according to the previous analysis, server 4 should theoretically be the largest of servers 1, 2, 3, 4, but since more than half of the servers have elected server 3, it can only accept the life of a younger brother.

5. Server 5 starts up and acts as a younger brother like 4.

Node structure [zk: 127.0.0.1 cZxid 2181 (CONNECTED) 2] get / 20181112hello # data cZxid = 0x4 # transaction for creating node zxidctime = Mon Nov 12 15:31:17 CST 2018 # creation time mZxid = 0x4 # Last updated transaction zxidmtime = Mon Nov 12 15:31:17 CST 2018 # Last update time pZxid = 0x4 # Last update child node zxidcversion = 0 # child node change number Number of znode child node modifications dataVersion = 0 # data change version number aclVersion = 0 # change number of the access control list ephemeralOwner = 0x0 # if it is a temporary node, this is the session id of the znode owner. 0 if it is not a temporary node. DataLength = 5 # data length numChildren = 0 # number of child nodes IV, node type

There are two types of Znode, ephemeral and persistent.

The type of Znode is determined at creation time and cannot be modified later.

At the end of a client session of a transient Znode, the zookeeper deletes the transient znode, and the transient znode cannot have child nodes.

The persistent Znode does not depend on the client session and will only be deleted if the client explicitly wants to delete the holding Znode.

Znode has four forms of directory nodes

PERSISITENT

EPHEMERAL

PERSISITENT_SEQUENTIAL

EPHEMERAL_SEQUENTIAL

Fifth, write data flow

1. Client writes data to ZooKeeper's Server1 and sends a write request.

two。 If Server1 is not a Leader, then Server1 forwards the received request to Leader further, because one of the Server of each ZooKeeper is Leader. This Leader broadcasts the write request to each Server, such as Server1 and Server2, and notifies Leader when each Server is written successfully.

3. When Leader receives most of the Server data written successfully, it indicates that the data has been written successfully. If there are three nodes, as long as two nodes have successfully written the data, then the data is considered to have been written successfully. After a successful write, Leader will tell Server1 that the data has been written successfully.

4. Server1 further informs Client that the data has been written successfully, and then the whole write operation is considered successful.

VI. Observation (watcher)

Watcher is a core function in Zookeeper. Watcher can monitor changes in the data of directory nodes and changes in subdirectories. As soon as these states change, the server will notify all Watcher set on this directory node, so that each client will quickly know that the state it is concerned about has changed and respond accordingly.

You can set the observed actions: exists, getChildren, getData

Operations that can be observed: create, delete, setData

Detailed explanation of the principle of monitoring:

1. First, there must be a main () thread

two。 When the Zookeeper client is created in the main thread, two threads are created, one for network connection communication (connet) and one for listening (listener).

3. The registered listening event is sent to the Zookeeper through the connect thread.

4. Add registered listeners to the list in Zookeeper's list of registered listeners.

5. When Zookeeper detects a change in data or path, it sends this message to the listener thread.

6. The process () method is called inside the listener thread.

After reading the above, do you have any further understanding of how to interpret the principle of zookeeper? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.