Zookeeper Monitoring mechanism

In zookeeper, all read operations (Getdata,getchildren and exists) can be set to listen. Listening is very useful in some scenarios, and when you are concerned about changes in some data, if you do not listen, you can only keep polling to see if the data has changed, while listening can avoid the overhead of polling. Setting up monitoring

The Zookeeper listener event is triggered only once, the listener event notifies the client asynchronously, and supports a variety of listening methods. Trigger only once
When the data changes, a listener event is sent to the client and the listener is canceled, unless the client sets up the listener again, and no longer listens.
If you call the GetData ("/znode1", True) method, the second parameter, True, indicates that the client will receive a listener message if the/ZNODE1 has changed or been deleted. If the/znode1 changes again, the listener message will not be received unless the client performs another get operation to set the listener.
The usual way for applications to use Zookeeper's listening capabilities is:
1. The client sets the listener for the specific object;
2. The specific object changes, the server sends the listener message to the client, and cancels the listener;
3. The client receives a listener message, initiates a query, and, if necessary, decides whether to listen again.
Zookeeper guarantees that query and listen are atomic operations, and all data changes after the client queries the data can be monitored. Send to Client
The request operation must be successfully returned to the client initiating the operation before the notification message can be sent. The listener is sent asynchronously to the listener. Zookeeper provides a sequence of guarantees: A client setting up a listener will not see data changes until it receives a listener event. Monitoring mode
This involves different ways of changing data, and the zookeeper server maintains two listening queues: The data listening queue and the child listening queue. GetData () and exists () set the data Listener, GetChildren () set the child to listen. SetData () will trigger the data listener, create () will trigger a node to be created by the listener and the child changes the child to listen, delete () will also trigger a data listener and child monitoring.

Monitoring information is maintained on the service side of the zookeeper and is a lightweight operation. When a client connects to a new server, the listener is triggered. After the client disconnects from the server, the listener will not be able to send to the client, and when the client is reconnected, any previous registered listener will automatically re-register and trigger according to the situation, the whole process is completed automatically.
There is a situation where the listener event is lost: When a client is disconnected from the server, a monitored node is created and deleted, and the client will not receive any listener events.
The listener list on the zookeeper server is only stored in memory and is not persisted. When a client disconnects from the server, all of its watch is removed from memory, and the client automatically re-registers all of its watch when it is re-connected. Monitoring Events

Zookeeper provides the following types of events, which describe how to listen for these events: Created event: Call the Exists method to set the listener, Deleted event: Call exists, GetData, GetChildren to set the listener; Changed Event: Call GetData set Listener, child event: Call GetChildren to set the listener. Cancel Monitoring

The client can cancel the listener, even if the connection is broken, the client is still able to cancel the listener by setting the local flag, and when the listener succeeds, it receives the following event:
1. Child Remove Event: Cancels the GetChildren call registration of the listener successfully;
2. Data Remove Event: Cancels the exists and GetData call registration for the listener success. zookeeper protection for monitoring

With regard to monitoring, zookeeper provides the following guarantees:
1. The listener is orderly, and the Zookeeper client library ensures sequential distribution of events, listening, and asynchronous responses;
1. When the client sees the new data of a node, it will see the listener event of that node first;
2. The sequence of zookeeper monitoring events is consistent with the order in which the Zookeeper service looks for updates. Precautions

Using Zookeeper's listening mechanism, you need to be aware of:
1. The listener is triggered only once, and if you receive a listening event and want to continue listening, you must set up the listener again;
2. Because monitoring is a one-time And there is a delay between receiving a listener and sending a new request (listening again), so you can't guarantee to see each change in the node. Therefore, your application logic should not rely on each change of the listener node;
3. For a notification message a listener object is only triggered once. For example, if the same listener is registered to listen on exists and getdata simultaneously, when the object is deleted, the listener will only be called once to send the delete notification;
4. When the client and server are disconnected (for example, the server is hung), you will not get any listening messages until the connection is rebuilt. For this reason, the session event will be sent to all listener event handlers, notifying them of Safe mode: You will not be able to receive listening messages during the break chain, and you need to be cautious.