Watches and ZooKeeper operations

The write operations in ZooKeeper are atomic and durable. There is the guarantee of a successful write operation if it has been written to persistent storage on a majority of ZooKeeper's servers. However, the eventual consistency model of ZooKeeper permits reads to log the latest state of the ZooKeeper service, and the sync operation allows a client to be up-to-date with the most recent state of the ZooKeeper service.

The read operations in znodes, such as exists, getChildren, and getData, allow watches to be set on them. On the other hand, the watches triggered by znode's write operations, such as create, delete, and setData ACL operations do not participate in watches.

The following are the types of watch events that might occur during a znode state change:

  • NodeChildrenChanged: A znode's child is created or deleted
  • NodeCreated: A znode is created in a ZooKeeper path
  • NodeDataChanged: The data associated with a znode is updated
  • NodeDeleted: A znode is deleted in a ZooKeeper path

A watch event's type depends on the watch and the operation that triggered it. Some crucial information about how the three main operations have event-generating actions is shown in this table:

Operation

Event-generating Actions

exists

A znode is created or deleted, or its data is updated

getChildren

A child of a znode is created or deleted, or the znode itself is deleted

getData

A znode is deleted or its data is updated

A watch event includes the path of the znode where the event was generated. Thus, a client can find a znode creation and deletion for the NodeCreated and NodeDeleted events through the inspection of the path to the znode. To discover which children have changed after a NodeChildrenChanged event, the operation getChildren has to be called to retrieve the new list of children. Similarly, in order to discover the new data for a NodeDataChanged event, getData has to be called.

ZooKeeper provides a set of guarantees from its data model perspectives and watch infrastructure built on top of it, which enables the easy, fast, and scalable building of other distributed coordination primitives:

  • Sequential consistency: This ensures that the updates from clients are always applied in a FIFO order.
  • Atomicity: This ensures that the updates either succeed or fail, so there is no partial commit.
  • Single system image: A client sees the same view of the ZooKeeper service, which doesn't depend on which ZooKeeper server in the ensemble it connects to.
  • Reliability: This ensures that the updates will persist once they are applied. This is until they are overwritten by some clients.
  • Timeliness: The clients' view of the system is guaranteed to be up-to-date within a certain time bound. This is known as eventual consistency.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.145.83.150