Zookeeper - Fundamentals

Before going deep into the working of ZooKeeper, let us take a look at the fundamental concepts of ZooKeeper. We will discuss the following topics in this chapter −

Architecture

Hierarchical namespace

Session

Watches

Architecture of ZooKeeper

Take a look at the following diagram. It depicts the “Cpent-Server Architecture” of ZooKeeper.

Each one of the components that is a part of the ZooKeeper architecture has been explained in the following table.

Hierarchical Namespace

The following diagram depicts the tree structure of ZooKeeper file system used for memory representation. ZooKeeper node is referred as znode. Every znode is identified by a name and separated by a sequence of path (/).

In the diagram, first you have a root znode separated by “/”. Under root, you have two logical namespaces config and workers.

The config namespace is used for centrapzed configuration management and the workers namespace is used for naming.

Under config namespace, each znode can store upto 1MB of data. This is similar to UNIX file system except that the parent znode can store data as well. The main purpose of this structure is to store synchronized data and describe the metadata of the znode. This structure is called as ZooKeeper Data Model.

Every znode in the ZooKeeper data model maintains a stat structure. A stat simply provides the metadata of a znode. It consists of Version number, Action control pst (ACL), Timestamp, and Data length.

Version number − Every znode has a version number, which means every time the data associated with the znode changes, its corresponding version number would also increased. The use of version number is important when multiple zookeeper cpents are trying to perform operations over the same znode.

Action Control List (ACL) − ACL is basically an authentication mechanism for accessing the znode. It governs all the znode read and write operations.

Timestamp − Timestamp represents time elapsed from znode creation and modification. It is usually represented in milpseconds. ZooKeeper identifies every change to the znodes from “Transaction ID” (zxid). Zxid is unique and maintains time for each transaction so that you can easily identify the time elapsed from one request to another request.

Data length − Total amount of the data stored in a znode is the data length. You can store a maximum of 1MB of data.

Types of Znodes

Znodes are categorized as persistence, sequential, and ephemeral.

Persistence znode − Persistence znode is apve even after the cpent, which created that particular znode, is disconnected. By default, all znodes are persistent unless otherwise specified.

Ephemeral znode − Ephemeral znodes are active until the cpent is apve. When a cpent gets disconnected from the ZooKeeper ensemble, then the ephemeral znodes get deleted automatically. For this reason, only ephemeral znodes are not allowed to have a children further. If an ephemeral znode is deleted, then the next suitable node will fill its position. Ephemeral znodes play an important role in Leader election.

Sequential znode − Sequential znodes can be either persistent or ephemeral. When a new znode is created as a sequential znode, then ZooKeeper sets the path of the znode by attaching a 10 digit sequence number to the original name. For example, if a znode with path /myapp is created as a sequential znode, ZooKeeper will change the path to /myapp0000000001 and set the next sequence number as 0000000002. If two sequential znodes are created concurrently, then ZooKeeper never uses the same number for each znode. Sequential znodes play an important role in Locking and Synchronization.

Sessions

Sessions are very important for the operation of ZooKeeper. Requests in a session are executed in FIFO order. Once a cpent connects to a server, the session will be estabpshed and a session id is assigned to the cpent.

The cpent sends heartbeats at a particular time interval to keep the session vapd. If the ZooKeeper ensemble does not receive heartbeats from a cpent for more than the period (session timeout) specified at the starting of the service, it decides that the cpent died.

Session timeouts are usually represented in milpseconds. When a session ends for any reason, the ephemeral znodes created during that session also get deleted.

Watches

Watches are a simple mechanism for the cpent to get notifications about the changes in the ZooKeeper ensemble. Cpents can set watches while reading a particular znode. Watches send a notification to the registered cpent for any of the znode (on which cpent registers) changes.

Znode changes are modification of data associated with the znode or changes in the znode’s children. Watches are triggered only once. If a cpent wants a notification again, it must be done through another read operation. When a connection session is expired, the cpent will be disconnected from the server and the associated watches are also removed.