Zookeeper principle Analysis-server-side processing flow

1) Processor Chain

This part of the content we mainly explain the zookeeper request on the zookeeper server side of the processing process, for different roles zookeeper have different processing flow, The Zookeepeerserver Start method calls Setuprequestprocessors () to initialize the processor chain, which is overridden by the quilt class implementation.

1. Leaderzookeeperserver

Look at the code above, the following two processor flow chains are established

(1) preprequestprocessor (thread) = Proposalrequestprocessor (tune initialize) =>commitprocessor (thread) = = Leader.tobeappliedrequestprocessor=>finalrequestprocessor

(2) Proposalrequestprocessor constructor sets another processor chain, initialize method starts Syncrequestprocessor thread syncrequestprocessor (thread) = Ackrequestprocessor

2. Followerzookeeperserver

Look at the code above, the following two processor flow chains are established

(1) followerrequestprocessor = commitprocessor (thread) =>finalrequestprocessor (thread)

(2) syncrequestprocessor (thread) = Sendackrequestprocessor

3. Observerzookeeperserver

(1) observerrequestprocessor = commitprocessor (thread) =>finalrequestprocessor (thread)

(2) syncrequestprocessor (thread) = Sendackrequestprocessor

(3) Look like the above code mainly establishes the following two processor flow chain

2) Processor detailed

The main functions of each processor

1) preprequestprocessor

The main function of this processor is to preprocess the request and deserialize the client to the server requesting the binary data to sever the request operation.

Preprequestprocessor as the first processor of the leader, its request data source mainly comes from:

(1) leader make a ZK service receive client requests submitted to Preprequestprocessor queue

(2) As the leader of the cluster, the Learnerhanler.run method receives the learner to leader the polling request, the message type is Leader.request

Preprequestprocessor Processing Flow:

(1) For non-object requests: Sync,exists, GetData, getchildren,ping, Setwatches here only to do the session check to see if the timeout

(2) for transaction requests: Create, Delete,setdata,setacl,check,multi, creates different actions based on the requested type, such as: Type=createècreaterequest, Type=delete Èdeleterequest, wait.

(3) Zookeeper create a new transaction number ZXID

(4) Create and set the message header for the transaction request

(5) Deserialize the network client request object to extract the data into the message body of the transaction object

Preprequestprocessor Thread {

Run {

1. Submittedrequests.take () Take out the NIO read request

2. Build the corresponding record object according to the requested type and deserialize the Bytebuffer data in the request into the record

3. ZKS.GETNEXTZXID () generates a new transaction number increment, as Zxid

4. Build the transaction head Txnheader according to Cxid,zxid, SessionID, etc.

5.1 Pairs of Create/delete/setdata/setacl/createsession/closesession/check

1) checksession, check if expired

2) Create the corresponding transaction body CREATETXN/DELETETXN, etc.

3) Build Changerecord Add to Zks.outstandingchanges queue (Finalrequestprocessor will process, eventually change data)

5.2 Exists/getdata Just Checksession

6. Tune the next processor

}

ProcessRequest () {

Standalone version is zookeeper, adding NIO read requests to Submittedrequests

}

}

2) Proposalrequestprocessor

Proposalrequestprocessor's handling logic is relatively simple

(1) forwarding to the back of the processor

(2) In the case of a transactional request (where the request header exists), leader initiates an operation request to follower and more than half of the client is successfully responding

(3) If it is a transactional request, call leader's synchronous processor process

3) Commitprocessor

This processor logic is still a little bit complicated, leader and learner all need to use this processor

3.1) for non-transactional operations (queries, exist, etc.) go directly to the next processor to process the request

3.2) leader for transactional operations (create, SetData, etc.), the Commitprocessor thread task will hold here, The Proposalrequestprocessor processor in leader will send the request proposal to all followers, followers response leader, Then leader Learnerhandler processack processing response, when more than half of the time the Commitprocessor.commit () method to submit the request, Immediately after Commitprocessor passes the request to the next processor processing

3.2) Learner for transactional operations (create, SetData, etc.) Request Commitprocessor thread task will hold here, Followerrequestprocessor or Observerrequestprocessor Commitprocessor sends the request to the queue immediately after the transaction operation proposal is sent to leader, Follower receives a commit message from leader or observer receives a inform message from leader, which submits the request to Commitprocessor, and then Commitprocessor passes the request to the next processor for processing

Pseudo code:

commitprocessor{

Run () {

1. Toprocess needs to be handed over to the next processor, first to the next

2. Nextpending for transactional operations when requested, there is a non-empty loop until there is a commit.

3. Queuedrequests.size () = = 0&& committedrequests.size () > 0 follower Observer receive commit, add to toprocess collection

4. nextpending! = null&& committedrequests.size () > 0 Leader initiate a poll request and receive follower feedback, add to toprocess collection

5. nextpending = = NULL Front loop

6. If the request Reqeust is a transactional operation assigned to the Nextpending object

7. If you are not adding to the Toprocess collection

This is where the order of request responses is controlled primarily through the Nextpending object

}

Commit (Request) {

Add the request to the Committedrequests queue

}

ProcessRequest (Request) {

Called by the upstream processor to add the request object to the Queuedrequests request queue

}

}

4) Tobeappliedrequestprocessor

The logic of this processor is relatively simple

1) forward the request to a processor, which must be finalrequestprocessor

2) In fact leader before going to this processor will be in the Commitprocessor Hod one will wait until follower feedback to this, Follower feedback after the leader Learnerhandler Processack will add the request to tobeapplied collection, so here for the transaction request must have a corresponding removal in tobeapplied, If there is no concurrentlinkedqueue, the nosuchelementexception exception is thrown directly.

5) Finalrequestprocessor

This processor is the last processor that really goes to perform transactional operations to change the Dataree data.

1) Adjust the bottom layer to modify the data Zks.processtxn (HDR, TXN)

2) Add the request to the Committedlog collection

3) Build the response of the request, responding to the client

Pseudo code:

finalrequestprocessor{

ProcessRequest (Request request) {

Zks.outstandingchanges this thing, it's never been clear.

1. The transaction header is not empty and is a transaction class operation {

Zks.processtxn (HDR,TXN)//zkserver processing transaction operations

}

If it is closesesion, no response is generated

Generates a response based on the request type (Request.type) and Nioservercnxn.sendresponse writes to the Chanel channel

}

}

6) Syncrequestprocessor

This processor is used to log requests to the Txlog file and to improve the performance of the IO through a bulk brush drive, where requests are only written to the local disk before being passed to the next processor

Here's a look at the pseudo-code:

Syncrequestprocessor Thread {

Run () {

Flush point in time: 1. Queuedrequests is empty 2.toflush.size () > 1000

Create a new snapshot

Tune Zks.getzkdatabase (). Append (SI) add a transaction log

1) Success: is the transaction class operation has the transaction head, according to the rule to determine whether needs to have a new snapshot, joins to the Toflush collection

2) Failure: No transaction header Txnheader, optimize direct tune next processor

}

Flush () {

Zks.getzkdatabase (). commit (); Synchronize to this snapshot

Then loop over the next processor.

}

ProcessRequest () {

Join the blocking queue queuedrequests to let the synchronization thread handle itself

}

}

7) Ackrequestprocessor

be called by Proposalrequestprocessor, leader to do a successful response to a poll

8) Sendackrequestprocessor

Send response for leader poll request

3) Interaction diagram

1. Here is a diagram to illustrate the interaction of the processor chain at the leader end

2. Here is a diagram to illustrate the follower (Observer similar) end of the processor chain interaction process

Zookeeper principle Analysis-server-side processing flow