Communication model of Zookeeper series __zookeeper

The topic of this article is to explain the zookeeper communication model, and this section will illustrate the zookeeper communication model through a schematic diagram.

Zookeeper Communication architecture

In the whole system of zookeeper, there are 3 roles in the service, client, Follower, leader. The client is responsible for initiating the application request, follower accepts the client initiates the request, participates in the transaction confirmation process, after leader Crash leader choice. And leader mainly assume the coordination of transactions, of course leader can also assume the function of receiving customer requests, in order to facilitate the description, the following description is the communication between client and follower, if the zookeeper configuration support leader receive client request, The client-leader communication is exactly the same as the client-follower communication pattern. The role between follower and leader may be converted at some point. A follower may be elected follower by a cluster (Quorum) leader after the leader crash is dropped. After a leader is crash, joining the cluster again (Quorum) will exist as a follower role. In a cluster (Quorum), there are only 1 leader and multiple follower at any other time except for the follower and leader distinctions in the electoral leader process. The communication architecture between Client, follower and leader is as follows:

between the client and the follower

In order for the client to have a high throughput, NIO is used to communicate between clients and follower. When the client needs to deal with the Zookeeper service, first read the configuration file to determine all the server lists within the cluster, select a follower as a communication target according to a certain load balance algorithm. So there is a communication channel between the client and the follower that is composed of NiO mode. This channel is persisted until the client closes the session or because the client or follower any one of the parties interrupts the communication connection for some reason. Normally, client and follower have heartbeat detection when they do not initiate a request.

between follower and leader

The communication between follower and leader is mainly due to follower received like (Create, delete, SetData, SetACL, CreateSession, CloseSession, Sync) Such commands that require leader to reconcile the final result will result in communication between follower and leader. Because leader and follower relationship between a one-to-many relationship, very suitable for client/server mode, so they are using C/s mode, by leader create a socket server, listening to the follower of the coordination request.

clusters in the process of selecting leader

Because there is no leader in the selection leader process, any member of the cluster needs to communicate with all other members, and when the membership of the cluster becomes large, this traffic is large. The process of selecting leader occurs when the zookeeper system has just started or is leader lost contact, select leader process will not be able to handle the user's request, in order to improve the availability of the system, it is necessary to minimize the time of the process. Choose which way to make them available for quick selection results. In this process, the Zookeeper adopts the strategy mode, which can be used to select the leader algorithm dynamically. The system defaults to provide 3 kinds of selection algorithms, Authfastleaderelection,fastleaderelection,leaderelection. where authfastleaderelection and leaderelection use UDP mode for communication, while Fastleaderelection still uses TCP/IP mode. In the new version of Zookeeper, a learner role was added to reduce the number of participants who chose leader. Make the selection process faster. Generally zookeeper leader are very fast, usually <200ms.

Zookeeper Communication process

To learn more about the zookeeper communication process, we first need to understand which client interfaces zookeeper provides, and we group by interfaces with the same communication process:

Zookeeper System Management Command

The Zookeeper System management interface is a command that is used to view the status of a zookeeper, and they are all in a 4-letter command format. Mainly includes: Ruok: Send this command to test whether zookeeper is functioning properly. Dump:dump ephemeral (temporary) node information for all surviving sessions on the server side. Stat: Gets the state of the server side of the connection server and status information for all customer service ports that connect to the server. Reqs: Gets the request that the current client has committed but has not yet returned. STMK: Turn on or off the trace level of zookeeper. GTMK: Gets whether the trace level of the current zookeeper is open. ENVI: Gets zookeeper Java-related environment variables. Srst: Resetting the server-side statistics status

When users send these commands to the server, because these requests are only related to the connected server, there is no business process logic, very simple. Zookeeper these commands with the fastest efficiency. These commands are sent to the server side for a single 4-byte int to represent different commands, and no string processing is used. When the server receives these commands, the results are returned immediately.

Session Creation

Any client's business request is based on the existence of the session. A session is a communication channel between the client and the follower and maintains all States from the beginning of creation between them. When a zookeeper client is started, the follower is found first according to a certain algorithm, then the NIO connection is established with follower. When the connection is established, send the command for the create session so that the server side creates an object session that maintains the connection state for the connection. When the server receives the Create session command and looks up from the local session list to see if the same SessionID already exists, close the original session and recreate the new session. The process of creating the session will need to be sent to leader, followed by leader notifying other follower that most follower log this action to the local journal and then notify leader, leader send a commit to all follower. The follower that connects the client returns the successful session response that was created. The coordination process between leader and follower will be explained in detail later. When the client successfully creates a session, the other business commands are processed properly.

Zookeeper Query Command

Zookeeper query commands are primarily used to query server-side data and do not change server-side data. All query commands can be immediately returned from the client-connected server without the need for leader coordination, so the data from the query command may be out-of-date. However, due to any modification of the data, leader will publish the results of the changes to all follower, so generally speaking, follower data can be updated in a timely manner. These query commands include the following commands: exists: Determines whether node for the specified path exists, returns True if it exists, or returns false. GetData: Gets the data Getacl for the node from the specified path: Gets the ACL for the specified path. GetChildren: Gets all child nodes for node of the specified path.

All query commands can specify watcher to track data changes in the specified path. Once the specified data has changed (create,delete,modified,children_changed), the server sends the command to and fro the watcher. Watcher detailed explanations will be explained separately in Zookeeper's watcher.

Zookeeper Modify Command

Zookeeper modification commands are mainly used to modify node data or structure, or permission information. Any modification commands need to be submitted to the leader for coordination, and the coordination is completed before they are returned.   Modification commands mainly include: 1.   CreateSession: Request server to create a session 2.   Create: Creates a node 3.   Delete: Deletes a node 4.   SetData: Modify data for one node 5.   SetACL: Modify ACL 6 for one node. CloseSession: Request server to close session

We know from the previous communication diagram that any modification command requires leader coordination. In the process of leader coordination, 3 times the response between leader and follower should be requested. It also involves logging of the transaction log and, worse still, take snapshot operations. Therefore, this process can be time-consuming. But zookeeper communication is the biggest feature is asynchronous, if the request is continuous, zookeeper processing is centralized processing logic, and then bulk delivery, the size of the batch is also controlled. If the request is small, send it immediately. In this way, when the load is very large can also ensure a large throughput, timeliness also to a certain extent to ensure that.

Zookeeper server-side business process-processor chain

<!--endfragment-->

Zookeeper handles business requests through chained processor, and each processor is responsible for handling specific functions. The different zookeeper role of the server processor chain is not the same, the following describes the standalone zookeeper server, leader and follower different processor chain.

the processor in the zookeeper Ackrequestprocessor: When leader sends proposal from follower, follower sends an ACK response, and leader receives an ACK response and calls this processor for processing. It is primarily responsible for checking whether the request has reached the confirmation of most follower, and submitting commitprocessor for commit if the condition is met Commitprocessor: Process requests from the commited queue that have been coordinated and commit by the leader or remove requests from the request queue that do not require leader coordination to proceed with the next step. Finalrequestprocessor: Any request processing needs to pass through this processor, which is the last processor of the request processing, which is mainly responsible for wrapping different types of response packs according to different requests. Of course, the follower and leader request will not need to send a response because there is no client connection (the code is reflected in if (REQUEST.CNXN = null) {return;} ）。 The first of the Followerrequestprocessor:follower processor chain is primarily responsible for coordinating the modification and synchronization requests to the leader. Preprequestprocessor: As the first processor on the leader and standalone servers, the primary role is to generate changelog for all modification commands. Proposalrequestprocessor:leader is used to request that the request be wrapped as a proposal to follower requests for confirmation. Sendackrequestprocessor:follower is used to send an ACK response to a leader. Syncrequestprocessor: Responsible for writing the transaction that has been commit to the transaction log and take snapshot. Tobeappliedrequestprocessor: is responsible for transferring the tobeapplied request to the next request for processing.

Standalone Zookeeper processor chain

Leader Processor Chain

Follower Processor Chain