Zookeeper Foundation
May 26, 2021 Zookeeper
Table of contents
Before diving into how ZooKeeper works, let's take a look at the basic concepts of ZooKeeper. We'll discuss the following topics in this chapter:
1, Architecture (Architecture)
2, Hierarchical namespace (hierarchical namespace)
3, Session (session)
4, Watches (monitoring)
ZooKeeper's architecture
Take a look at the chart below. It describes ZooKeeper's "client-server architecture."
Each component, which is part of the ZooKeeper architecture, is described in the table below.
| Part | Describe |
|---|---|
| Client (Client) |
The client, a node in our distributed application cluster, accesses information from the server. /b10> For a specific interval, each client sends a message to the server to let the server know that the client is active. Similarly, when the client connects, the server sends a confirmation code. /b10> If the connected server does not respond, the client automatically redirects the message to another server. |
| Server (Server) | The server, a node in our ZooKeeper population, provides all services to the client. /b10> Send a confirmation code to the client to inform the server that it is active. |
| Ensemble | ZooKeeper Server Group. /b10> The minimum number of nodes required to form ensemble is 3. |
| Leader | Server node, which performs automatic recovery if any of the connected nodes fail. L eader is elected when the service starts. |
| Follower | The server node that follows the leader instruction. |
Hierarchical namespaces
The following illustration depicts the tree structure of the ZooKeeper file system for memory representing. /b10> The ZooKeeper node is called znode. /b11> Each znode is identified by a name and separated by a sequence of paths (/).
-
In the figure, there is first a znode separated by "/". /b10> At the root, you have two logical namespaces, config and workers.
-
Config namespaces are used for centralized configuration management, and workers namespaces are used for naming.
-
Under the config namespace, up to 1MB of data can be stored per znode. /b10> This is similar to the UNIX file system, where data can be stored in addition to the parent znode. /b11> The main purpose of this structure is to store synchronized data and describe the metadata of znode. /b12> This structure is called the ZooKeeper data model.
Znode has both file and directory features. D ata structures such as data length, meta-information, ACLs, timestamps, and so on are maintained like files, and can be used as part of path identification as directories. Each Znode consists of three parts:
- Stat: This is status information that describes the Znode version, permissions, and so on.
- Data: The data associated with the Znode
- c Hildren: The node under Znode
-
Version number - Each znode has a version number, which means that whenever the data associated with znode changes, its corresponding version number increases. /b10> The use of version numbers is important when multiple zookeyer clients try to perform operations on the same znode.
-
Action Control List (ACL) - ACL is basically the authentication mechanism for accessing znode. /b10> It manages all znode reads and writes.
-
Timestamp - Timestamp represents the time it takes to create and modify znode. /b10> It is usually in milliseconds. /b11> ZooKeeper identifies each change in znode from the Transaction ID (zxid). /b12> Zxid is unique and reserves time for each transaction so that you can easily determine the time that passes from one request to another.
-
Data Length - The total amount of data stored in znode is the data length. /b10> You can store up to 1MB of data.
The type of Znode
Znode is divided into persistent nodes, sequential nodes, and temporary (ephemeral) nodes.
-
Persistent node - Persistence nodes persist even after the client that created that particular znode is disconnected. /b10> By default, all znode is persistent unless otherwise noted.
-
Temporary nodes - Temporary nodes are valid when the client is active. /b10> When the client is disconnected from the ZooKeeper collection, the temporary node is automatically deleted. /b11> Therefore, only temporary nodes do not allow child nodes. /b12> If the temporary node is deleted, the next appropriate node fills its location. T emporary nodes play an important role in the leader election.
-
Sequential nodes - Sequential nodes can be persistent or temporary. /b10> When a new znode is created as a sequential node, ZooKeeper sets the path to znode by attaching a 10-bit serial number to the original name. /b11> For example, if you create znode with path /myapp as a sequential node, ZooKeeper changes the path to /myapp00000000001 and sets the next serial number to 00000000002. I f two sequential nodes are created at the same time, ZooKeeper does not use the same number for each znode. /b13> Sequential nodes play an important role in locking and synchronization.
Sessions (Sessions)
Sessions are important for ZooKeeper's operations. /b10> Requests in the session are executed in FIFO order. /b11> Once the client is connected to the server, a session is established and the client is assigned a session ID.
The client sends a heartbeat at a specific interval to keep the session valid. /b10>If the ZooKeeper collection does not receive a heartbeat from the client for more than the period specified when the server is turned on (session timeout), it determines that the client is dead.
Session timeouts are typically in milliseconds. /b10> When a session ends for any reason, temporary nodes created during that session are also deleted.
Watches (Monitoring)
Monitoring is a simple mechanism for clients to be notified of changes in the ZooKeeper collection. /b10> Clients can set Watches when reading a specific znode. /b11> Watches sends notifications of any znode (client registry) changes to the registered client.
Znode changes are modifications to znode-related data or changes in znode's children. /b10> Watches is triggered only once. /b11> If the client wants to be notified again, it must do so through another read operation. /b12> When the connection session expires, the client disconnects from the server and the associated watches are deleted.