Zookeeper (iv): Core Principles (Watcher, events and states)

Zookeeper is mainly to unify the working state of each node in the distributed system, and coordinate to provide the node resource preemption in the case of resource conflict, and provide each node with a way to understand the state of the whole cluster. All of these implementations depend on the event monitoring and notification mechanisms in zookeeper .

Events and states in the zookeeper

Events and states form the two dimensions of the Zookeeper Client connection description. Note that many posts on the web are about events that are connected to zookeeper clients, but ignoring the changes in Zookeeper client state is also a matter of listening and notifying. Here we describe in detail the events and states in zookeeper in the following two tables (the events and states that are defined as @deprecated in the Zookeeper API are not covered).

Zookeeper the state of the client connection to the Zookeeper server

Connection Status	State meaning
Keeperstate.expired	The client and server are sending a heartbeat notification during the ticktime time period. This is an implementation of the lease agreement. The client sends a request that tells the server its last lease time, and after the server receives it, tells the client which point of time the next lease time is. When the client timestamp reaches the last lease time without receiving any new lease time from the server, it considers itself offline (after which the client discards the connection and tries to reestablish the connection). This expiration state is the expired state
keeperstate.disconnected	As stated in the above state, when the client disconnects a connection (possibly a lease expires or the client is actively disconnected) this is the client and server connection is the disconnected state
keeperstate.syncconnected	Once the client and the server node establish a connection (note that although the cluster has multiple nodes, but the client connects to one node at a time), and complete a version, ZXID synchronization, then the client and server connection state is syncconnected
Keeperstate.authfailed	This state occurs when the zookeeper client fails to authenticate the connection

It should be noted that when these states are triggered, the type of event logged is: Eventtype.none.

Watch event in Zookeeper (when zookeeper client listens to a Znode node "/node-x")

Zookeeper Events	Event meaning
eventtype.nodecreated	This event is triggered when the Node-x node is created
Eventtype.nodechildrenchanged	This event is triggered when the immediate child node of the Node-x node is created, deleted, and the child node data is changed.
Eventtype.nodedatachanged	This event is triggered when the data of the Node-x node is changed
eventtype.nodedeleted	When the Node-x node is deleted, the event is triggered.
Eventtype.none	When the zookeeper client's connection state changes, that is, keeperstate.expired, keeperstate.disconnected, keeperstate.syncconnected, keeperstate.authfailed State Switch, the event type described is Eventtype.none

Watch mechanism

Znode changes (Znode itself, deletions, modifications, and changes in sub-znode) can be notified to the client via the watch mechanism. to implement watch, you must implement the Org.apache.zookeeper.Watcher interface and pass the object of the implementation class into a method that can watch. the Watch option can be set for all read operations (GetData (), GetChildren (), exists ()) in Zookeeper . The Watch event has the one-time trigger ( one-time trigger) feature and notifies the client setting the watch if the watch Monitor's znode changes.

In all of the read operations mentioned above, if Watcher is required, we can customize the watcher, if it is a Boolean variable, when True, the system default watcher is used, The default watcher of the system is the watcher defined in the zookeeper constructor. The Watcher in the parameter is empty or false, indicating that Wather is not enabled.

Watch feature 1: Disposable trigger

When the client sets watch in Znode, the client gets a watch event if the Znode content changes. For example: After the client set GetData ("/znode1", true), if the/znode1 changes or delete, then the client will get a/znode1 watch event, but/znode1 again changed, The client is not able to receive the watch event unless the client has set a new watch.

Watch feature 2: Send to Client

The Watch event is sent asynchronously to the client. Zookeeper can ensure that the order in which the client sends past updates is sequential. For example, if a znode is not set watcher, the client is not aware of any changes to the Znode until the Znode setting watcher sent to the cluster. A different angle to explain: Because Watch has a one-time trigger feature, so in the server side without watcher, any changes to Znode will not be notified to the client. However, even if a znode is set to watcher and the client is notified when Znode changes, the client receives the change event, but before the Watcher is set again, if the other client modifies the Znode, in this case, Znode The second change the client is unable to receive notifications. This may be due to network latency or other factors, so we cannot expect to be able to monitor the changes to the nodes each time we use zookeeper. Zookeeper can only guarantee eventual consistency, and cannot guarantee strong consistency.

Watch feature 3: Set Watch's data content

There are many ways to change znode, such as: node creation, node deletion, node change, child node change, and so on. Zookeeper maintains two watch lists, one node data watch list, and the other is a child node watch list. GetData () and exists () set the data Watch,getchildren () to set the child node watch. Choosing between the two allows us to choose a different watch mode depending on the return result, GetData () and exists () return the contents of the node, GetChildren () returns a list of child nodes. Therefore, the SetData () trigger content watch,create () triggers the contents of the current node watch or the child of its parent node watch. Delete () simultaneously triggers the parent node's child watch and content watch, as well as the child node's content watch.

Operation Mechanism of Zookeeper watcher

1,watch is a lightweight, in fact, the callback of the local JVM, the server side just save whether there is a Boolean type set Watcher. (See Source: Org.apache.zookeeper.server.FinalRequestProcessor)
2, on the server side, in the finalrequestprocessor processing corresponding Znode operation, according to the watcher variables passed by the client, Add to the corresponding zkdatabase (org.apache.zookeeper.server.ZKDatabase) for persistent storage, and nioservercnxn yourself as a watcher callback, Monitor server-side event changes
3,leader by voting through a znode change request, and then notify the corresponding Follower,follower according to their own in-memory zkdatabase information, send notification information to the zookeeper client.
After the 4,zookeeper client receives the notification information, it finds a list of watcher corresponding to the change path, triggering the callback.

Flow chart

Zookeeper (iv): Core Principles (Watcher, events and states)