- Why add Watch
ZooKeeper is a service for coordinating (synchronizing) distributed processes, providing a simple and high-performance coordination kernel on which users can build more complex distributed coordination functions.
Multiple distributed processes operate the shared ZooKeeper memory data object ZNode through the API provided by ZooKeeper to achieve a certain consistent behavior or result. This mode is essentially a concurrency model based on state sharing, which is consistent with Java's multi-threaded concurrency model. , their threads or processes are all "shared memory communication". Java does not directly provide some kind of responsive notification interface to monitor the change of the state of an object. It can only waste CPU time without responsive polling and retry, or based on some kind of active notification (Notif) mechanism provided by Java (built-in queue) to respond to state changes, but this mechanism requires looping blocking calls. When ZooKeeper realizes the sharing of the state of these distributed processes (Data, Children of ZNode), it adopts a similar asynchronous non-blocking active notification mode, namely the Watch mechanism, based on performance considerations, which enables the "shared state communication" between distributed processes. More real-time and efficient, in fact, this is also the main task of ZooKeeper - coordination. Although Consul also implements the Watch mechanism, it is a blocking long polling.
- ZooKeeper VS JVM
From a certain point of view, it can be compared in this way (personal opinion, can be discussed), ZooKeeper is equivalent to JVM, ZooKeeper contains state objects (ZNode) and the underlying execution engine Zab of distributed processes, while JVM contains heap (multi-threaded shared A large number of object storage areas) and multi-threaded execution correctness constraint specification JMM (Java Memory Model), JMM ensures that the execution order of multi-threading is correct. The Zab protocol makes ZooKeeper's internal state modification operations directly serial in order, while the JVM is out-of-order and parallel. Additional mechanisms need to be added to ensure timing (memory barriers, processor atomic instructions), and when the state is read , JVM and ZooKeeper both read old data when reading directly, but ZooKeeper has a Watch mechanism to make responsive reading more efficient, while JVM can only use the underlying memory barrier to refresh the shared state, so that other threads can get the correct read when they read again. new data.
The interface provided by ZooKeeper makes the execution of all distributed processes asynchronous and non-blocking (WaitFree algorithm), and the internal version is based on the CAS operation, while the JVM provides a variety of blocking and non-blocking interfaces, including Synchronized, Volatile, AtomicOperations. When building more complex synchronization or coordination functions between threads or distributed processes based on the interface, the Java concurrency library directly provides synchronization tools such as locks, loop fences, semaphores, and basic abstract queue synchronizers, while ZooKeeper requires users Build various distributed coordination functions (distributed locks, distributed publish and subscribe, cluster membership management) based on the interface. As shown below:
| ZooKeeper | JVM | |
| shared state object | ZNode | objects in the heap |
| low-level execution mode | Zab sequential execution | Multiprocessor concurrent execution (memory barriers, atomic machine instructions) |
| API interface | Get、Watch_Get、Cas_Set、Exist | Synchronized、volatile、final、Atomic |
| Coordination or synchronization function | Distributed publish-subscribe, locks, read-write locks | Concurrent library synchronization tool, synchronization component based on abstract queue synchronizer |
- ZooKeeper's Watch Architecture
The overall process of Watch is shown in the figure below. The client first successfully registers the status of the node it wants to monitor with the ZooKeeper server. At the same time, the client locally stores the information related to the listener in the WatchManager. When the data status monitored by the ZooKeeper server occurs When it changes, ZooKeeper will actively notify and send the corresponding event information to the relevant session client, and the client will call back the relevant Watcher's Handler in a local response.
- Watch feature of ZooKeeper
- The watch is one-time and needs to be re-registered each time, and the client will not receive any notification when the session ends abnormally, and the fast reconnect still does not affect receiving notifications.
- The callback execution of Watch is executed sequentially, and the client will not see the latest data until it receives the notification of the change event of the concerned data. In addition, it is necessary to be careful not to block the Watch callback of the entire client in the Watch callback logic.
- Watch is lightweight, WatchEvent is the smallest communication unit, and its structure only contains notification status, event type and node path. The ZooKeeper server only informs the client what happened, not the specific content.
- Watcher interface design
As shown in the figure above, Watch is designed as an interface. Any class that implements the Watcher interface is a new Watcher. Watcher contains two enumeration classes, one KeeperState, which represents the state of ZooKeeper when the event occurs, and the other is the event. The types of occurrences are mainly divided into two categories (one is the change of ZNode content, the other is the change of ZNode child nodes). The specific description is shown in the following table.
| KeeperState |
EventType | TriggerCondition | EnableCalls | Desc |
|
SyncConnected (3)
|
None (-1) |
The client and server successfully establish a session | At this point, the client is connected to the server | |
| Ditto |
NodeCreated (1) |
The corresponding data node monitored by the Watcher is created | Exists | Ditto |
| Ditto |
NodeDeleted (2) |
The corresponding data node monitored by the Watcher is deleted | Exists, GetData, and GetChildren | Ditto |
| Ditto |
NodeDataChanged (3) |
The data content and data version number of the data nodes monitored by the Watcher change | Exists and GetData | Ditto |
| Ditto |
NodeChildrenChanged (4) |
The list of child nodes of the data node monitored by the Watcher changes, and the change of the content of the child nodes will not trigger | GetChildren | Ditto |
| Disconnected (0) |
None (-1) |
Client disconnects from ZooKeeper server | At this point, the client is disconnected from the server | |
| Expried (-112) |
None (-1) |
session timeout | At this time, the client session is invalid, and usually also receives a SessionExpiredException exception at the same time. | |
| AuthFailed (4) |
None (-1) |
There are usually two cases: 1. Use the wrong scheme for permission checking 2. SASL permission check failed |
Received AuthFailedException |
- Design of WatchEvent
如上图所示，WatchEvent有2种表示模式，一种是逻辑表示即WatchedEvent，是直接封装了各种抽象的逻辑状态（KeeperState，EventType），适用于客户端和服务端各自内部处理，另一种是物理表示即封装的更多是底层基础的传输数据结构（int，String），并且实现了序列化接口，主要用来做底层的数据传输。