Zookeeper Full analytic--client end (RPM)

Zookeeper's client deals directly with users and is the interface of our use of zookeeper. Understanding the structure and working principles of ZK client facilitates the rational use of ZK and the discovery of problems earlier in use. This paper will describe the working principle and internal working mechanism of ZK client in the research of source code technology.

After reading the general framework of ZK client I would like to have a simple way to describe the basic structure of the ZK client, to think about it I think the picture can reflect the situation, so I drew this general structure diagram:

I think since I drew this picture, let's start with this picture.

Module:

We can assume that ZK's client consists of three main modules: Zookeeper, Watchermanager, CLIENTCNXN

Zookeeper is the real interface of the ZK client side, the user can operate the most important class, when the user creates a zookeeper instance, almost all operations are arranged by this instance, the user does not care how to connect to the server, Watcher when the trigger is triggered, and so on.

Watchermanager, as the name implies, it is used to manage Watcher, Watcher is a major feature of ZK, allowing multiple clients to monitor one or more znode, When Znode changes, it is possible to notify each client that monitors the Znode. We consider a ZK client simply as a zookeeper instance, so the Watchermanager within this instance manages all watcher that ZK client binds.

CLIENTCNXN is a module that manages all network IO, and all the information and data that interacts with ZK server pass through this module, including sending a request to ZK server, accepting response from ZK server, and from ZK The server accepts the Watcher Event. CLIENTCNXN completely manages the network and externally it seems that the network operation is transparent.

Thread:

Every time we create a zookeeper instance, two threads are created: Sendthread and Eventthread. So when we use the ZK client side, we should try to create only one zookeeper instance and use it repeatedly. A large number of creation destruction zookeeper instances will not only create and destroy threads repeatedly, but also create a large number of sessions on the server side.

Sendthread is a thread that really handles network IO, and all packets sent and received over the network are processed in this thread. The body of this thread is a while loop:

    while (ZooKeeper.state.isAlive ()) {try {if (Sockkey = = null) {//don ' t re-establish Co                Nnection If we is closing if (closing) {break;                } startconnect ();                Lastsend = Now;            Lastheard = Now;            } ..... selector.select (to);            Set<selectionkey> selected;            Synchronized (this) {selected = Selector.selectedkeys ();  }//Everything below and until we get back to the Select are//non blocking, so time is effectively A constant.            That's/Why we just has to does this once, here now = System.currenttimemillis ();                for (Selectionkey k:selected) {... if (Doio ()) {lastheard = now;        } ... ... }    } catch () {...} }

This uses the Java NIO feature, which triggers a loop when the selector detects an event, and the main operation is done in Doio ():

    Boolean Doio () throws Interruptedexception, IOException {        Boolean packetreceived = false;        Socketchannel sock = (Socketchannel) sockkey.channel ();        if (sock = = null) {            throw new IOException ("Socket is null!");        }        if (sockkey.isreadable ()) {            ...        }                 if (sockkey.iswritable ()) {        ...        }        if (Outgoingqueue.isempty ()) {            disablewrite ();        } else {            enablewrite ();        }        return packetreceived;    }

This is probably the process:

1. If there is data readable, the packet is read, and if the packet is the response of the request previously issued, the packet must be inside the pending queue. Remove it from the pending queue and add this information to the waiting event queue if the packet is a watcher event and add this information to the waiting event queue.

2. If there is data in the outgoingqueue that needs to be sent, send the packet and move the packet from the outgoing queue to the pending queue, meaning that the data I have sent out, but also waiting for the server side of the reply, So this request is now in the pending state.

Another thread eventthread is used to handle the event. As mentioned earlier, when Sendthread receives data from the server, it adds some information to the event thread, such as the finish event and the Watcher event. The Eventthread is designed to handle these event, and when the finish event is received, the corresponding package is placed into the finish state so that the client function waiting for the result can be returned. When you receive the Watcher event, you will contact Watchermanager to find the corresponding watcher, remove this watcher from the Watchermanager (because each watcher will only be notified once) And callback Watcher's process function. So all Watcher's process functions are run in Eventthread.

Keep the connection:

The approximate structure and processing flow of the ZK client should have been introduced so far. One of the remaining questions is how ZK client handles the problem when the network is down. In fact, this process is not complicated, presumably by performing the following steps:

1. The network fails, and the exception thrown by the network operation is captured.

2. Confirm that the network operation failed, clear the current server-related network resources, including sockets and so on.

3. Try the link server one by one in the server list.

The process is transparent to the outside world and the ZK client has quietly replaced a connected server.

Well, for the ZK client introduction is probably so much, I hope this introduction for everyone to learn and use zookeeper have some help. For the article does not introduce or not clear the place need to further review the source code to solve.

Transfer from http://www.spnguru.com/2010/08/zookeeper%E5%85%A8%E8%A7%A3%E6%9E%90%E2%80%94%E2%80%94client%E7%AB%AF/

Zookeeper Full analytic--client end (RPM)