ZooKeeper data model

ZooKeeper has a hierarchical namespace, similar to a distributed file system. The only difference between them is that each node in the namespace can have data associations as their child nodes. It's like having a file system that allows files to also be directories of files. Node paths are usually expressed as canonical, slash-separated absolute paths. They don't have relative paths. Any unicode characters included in the path must comply with the following constraints:
1) Null characters cannot be used as path names;
2) The following strings cannot be used as, which is superior to their display unfriendly, or easy to cause confusion (\u0001 - \u001F and \u007F - \u009F)
3) The following strings are not allowed. (\ud800 - uF8FF, \uFFF0 - uFFFF)
4) The "." character can be used as part of the name, but "." and ".." cannot exist alone to represent the path of a node, because ZooKeeper does not use relative path. The following examples are invalid "/a/b/./c" or "/a/b/../c"
5) The "zookeeper" keyword is reserved

ZNodes

Each node in the ZooKeeper tree structure can be called a znode. Znodes maintain a state data structure, including data change version number, ACL change and timestamp. The version number plus a timestamp allows ZooKeeper to perform cache replacement and coordinate updates. Whenever the data of a znode changes, the version number will be incremented. For example, whenever a client receives data, it also receives a version of this data. At the same time, when the client performs an update or delete operation, it must provide the data version of the changing znode node. If the version number provided by the znode does not match the actual version number of the current data, the update will fail.

Note:

In a distributed application project, the word node can be considered as a single host, a server, a member of the whole, and a client processor and so on. In the ZooKeeper documentation, znodes are considered data nodes. Servers are considered the hosts that make up the ZooKeeper service. Quorum peers are considered to be servers that form a whole, and clients are considered to be a host or a process that is using the ZooKeeper service.

Znodes are the main entities accessed by programmers. They have many features worth understanding:

Watches

Clients can listen on znodes. Changes to the znode will trigger this listener and then clear it. When a listener is triggered, ZooKeeper sends a notification to the client.

Data Access

The data stored in the znode in the namespace is read or written atomically. Read operations will read all data bytes associated with the znode, and write operations will replace all data. Each node has an Access Control List (ACL) data access list that restricts who can do what.

ZooKeeper is not designed to be used as a database or large object storage. Instead, it is used to manage and coordinate data. The source form of data can be configuration information, status information, region information, etc. A common property of the different forms of coordination data is that they are relatively small, in the range of KB bytes. Both the ZooKeeper client and server have sanity checks to ensure that znodes are less than 1M data, but the data can be much smaller than this average. Operating on relatively large data will cause the operation to take a long time, thus affecting the delay of other operations, because this extra time requires data migration through the network or storage media. If the storage of big data is necessary, the usual way to handle this data is to keep it in a large storage system, such as NFS or HDFS, and then store a pointer to the data storage location in ZooKeeper.

Ephemeral Nodes

ZooKeeper has the concept of temporary nodes. As long as the session that created the nodes is active, these nodes still exist. When the session is closed, these nodes will also be deleted. Because of this behavior, temporary nodes are not allowed to have child nodes.

Sequence Nodes -- Unique Naming (sequence node-unique naming)

When creating a node you can ask ZooKeeper to add a monotonically increasing counter at the end of the path. This counter is unique to this parent node. The format of the counter is %010d (decimal padded with zeros), formatted for simple sorting. For example "0000000001". Check out Queue Recipe for an example using this feature. Note: The counter used to store the next sequence number is a signed int maintained by the parent node. This counter will overflow when incremented beyond 2147483647 (the result should be "-2147483647").

The above is the detailed content of ZooKeeper data model. For more information, please follow other related articles on the PHP Chinese website!