Watcher and configurations in zookeeper

Question guidance:
1. When will the zookeeper observer call?
2. What problems does the traditional remote polling service have?
3. What is the callback service mechanism in ZK?
4. Why is watcher not permanently registered in ZK?
5. What is znode?











Before reading this document, you must first clarify the following concepts:
1. What is znode?


2. What is a client?

We use the znode term to represent zookeeper data nodes.

Znode maintains a stat structure, which includes the version number, ACL change, and timestamp of data changes to allow cache checksum and coordinated updates. The version number increases whenever the znode data changes. When a client receives data, it also receives the data version number.

Data stored in each znode is read and written automatically. Read operations get all znode data, and write operations replace all znode data. Each node has an access control table (ACL) to limit who can perform what operations.

 

Zookeeper has the following three types of roles: <ignore_js_op> system model: <ignore_js_op>

Traditional round-robin remote service
In traditional remote services, service providers often register their own services in remote services. Service callers constantly perform remote service round-robin to check whether the service provider provides or updates the service. Therefore, the disadvantage is that the latency is relatively high, and because many unnecessary empty polling results in high load and network losses, this mode should be like this in zk.


<Ignore_js_op>



Asynchronous callback service in ZK

ZK actually implements asynchronous callback instead of polling, and introduces an event inotifications mechanism: the client first registers to the zk service to receive znode change events, that is to say, once the znode of watch changes, the client will be notified accordingly and then process its own business logic.

<Ignore_js_op>

• The ZK client can register an observer through exists, getchildren, and getdata. The observer simply specifies a callback
• When will the observer call it? Once the znode of the listener changes, the zk Service sends the corresponding znode path to the client, and the client calls the corresponding previously registered return function for processing. For create, delete, and setdata of nodes, the observer is triggered, that is, the callback () function.
  

The server only stores event information, the client stores event information, and the watcher execution logic. When registering watcher, the client maintains the correspondence between znode path and callback () locally. The server maintains the corresponding connection session, znode path, and event type. After the server triggers the corresponding event type, it will send the event type to the client and znode path, and the client will call the corresponding callback () according to the ing relationship (), the subsequent business logic is implemented on the client.

Single watcher trigger in ZK

The watch in ZK is triggered once, and only one notification is triggered for a change. To receive the notification next time, you need to register it again. Why not register watcher permanently? This mainly takes into account the performance impact. See the following situation

• Client C1 sets a watcher for znode/task
• Client C2 comes and adds znode to/task
• Client C1 received the notifications and learned that the monitored znode has changed.
• Client C1 is processing the notifications. At this time, client C3 adds a znode for/task.

In step 3, C1 has triggered a watcher. In Step 4, there is no watcher. Unless watcher is reset, a watcher will be lost in this process, this involves the CAP principle. Zookeeper can only ensure the final consistency, but cannot ensure the strong consistency. However, because ZK ensures the sequence consistency, it can ensure the final consistency.

• Strong Consistency: After a data change in a distributed system, access to any service can obtain the latest data.
• Weak Consistency: After a data change, some services can obtain the latest data, and some services cannot
• Final consistency: After updating a data, the latest data may not be obtained at the beginning, but the latest data can be displayed.
• Ordered consistency: Update n data sets to ensure that services are updated in order of n data sets.

In fact, there is a solution for the above case, specifically, getdata every time after watcher registration, to ensure that the data version is the latest, but compared with the traditional polling advantage is very obvious.

ZK versions

Once the data of each znode changes, there will be an incremental version number. During zk api execution, you must specify the version number. The znode operation can be performed only when the version number provided by the client matches the version number on the server. The version number is important when multiple clients operate on the same znode. See the following situation.

• For example, if client C1 writes znode/nginx/conf data and some configuration information, the/nginx/conf version changes from Version1 to version2.
• At the same time, client C2 also wants to write/nginx/Conf, because the client version of C2 is still Version1, and the server version is already version2, it will conflict at the moment, this operation will end with a failure. Therefore, you must first update C2 to version2 and then submit the operation.

Upgrade version2 to version3 on ZK, and upgrade C2 to version3 locally.

<Ignore_js_op>

Watcher and configurations in zookeeper