ZooKeeper Data Model

ZooKeeper's data model, which is structurally similar to a standard file system, has a hierarchy of namespaces, all with a tree hierarchy, each node in the ZooKeeper tree is called-
Znode. Like the file system's directory tree, each node in the ZooKeeper tree can have child nodes. But there are also differences:

1. The Znode combines both file and directory features. Data structures such as data, meta-information, ACLs, timestamps, and so on are maintained as files, and can be used as part of a path identifier as well as a sub-znode. The user to Znode has the increment, the deletion, the change, the check and so on operation (permission to allow the case).
2. The Znode has atomic operations, and the read operation gets all the data associated with the node, and the write operation replaces all of the node's data. In addition, each node has its own ACL (access control list), which defines the user's permissions, which define the actions that a particular user can perform on the target node.
3. Znode Storage data size is limited. ZooKeeper Although it can be associated with some data, but is not designed as a regular database or big data storage, instead, it is used to manage scheduling data, such as distributed applications in the configuration file information, state information, collection location and so on. The common feature of these data is that they are all very small data, usually in kilobytes per unit of size. ZooKeeper servers and clients are designed to strictly check and limit the data size of each znode to up to 1M, which should be much smaller than this value in general usage.
4. Znode is referenced by a path, like a file path in Unix. The paths must be absolute, so they must be preceded by a slash character. In addition, they must be unique, meaning that each path has only one representation, so these paths cannot be changed. In ZooKeeper, the path is determined by the
   Unicode strings, and there are some limitations. The string "/zookeeper" is used to hold management information, such as critical quota information.

3.1. Data structure diagram

Each node in the diagram is called a znode. Each znode consists of 3 parts:
①stat: This is the status information, which describes the version of the Znode, permissions and other information
②data: Data associated with the Znode
③children: Sub-node under this Znode
3.2. Node type
There are two types of znode, the temporary node and the permanent node, respectively. The type of the node is determined when it is created and cannot be changed.
Temporary node: The node's life cycle relies on the session in which it was created. Once the session is over, the temporary node will be automatically deleted, and of course it can be deleted manually. Temporary nodes are not allowed to have child nodes.
Persistent node: The node's life cycle is not dependent on the session and can only be deleted if the client displays a delete operation.
Znode also has a serialization feature that, if specified at the time of creation, automatically appends an increasing sequence number to the Znode name. The sequence number is unique for the parent node of this node, which records the order in which each child node is created. Its format is "%10d" (10 digits, digits with no numeric value are supplemented with 0, for example "0000000001").

In this way, there are four types of znode nodes, each corresponding to:
Persistent: Persistent node ephemeral: temporary node
Persistent_sequential: Persistent node, serialized ephemeral_sequential: temporary node, serialization
3.3. Node properties
Each Znode contains a series of properties that can be obtained by command get.

Dataversion: The data version number, each set operation on the node, the value of dataversion
Increases by 1 (even if the same data is set), which effectively avoids the sequencing problems that occur when data is updated.
Cversion: The version number of the child node. When Znode's child nodes change, the value of cversion increases by 1.
The version number of the Aclversion:acl. The transaction ID created by Czxid:znode.
Mzxid:znode the modified transaction ID, that is, each modification to Znode will update Mzxid. For ZK, each change will produce a unique transaction ID,ZXID (ZooKeeper Transaction ID). With Zxid, you can determine the sequencing of the update operation. For example, if ZXID1 is smaller than Zxid2, the zxid1 operation precedes Zxid2, and Zxid is unique for the whole ZK,
Even if the operation is of a different znode.
CTime: Timestamp when the node was created.
Mtime: Timestamp when the node's latest update occurred.

Ephemeralowner: If the node is a temporary node, the Ephemeralowner value represents the node
The session ID of the binding. If not, the Ephemeralowner value is 0.
Before client and server communication, you first need to establish a connection, which is called the session. After the connection is established, if a connection timeout occurs, authorization fails, or the connection is explicitly closed, the connection is in the CLOSED state, at which point the session ends.

ZooKeeper Data Model