Zookeeper Programming Guide (i) __ programming

Zookeeper Programming Guide (i)Introduction to Data Model node time STAT structure session monitoring access control pluggable authentication consistency assurance bindings Building Unit: Zookeeper Operation Wizard Program Structure FAQ and troubleshooting
Introducing this article is a developer's guide to programmers who want to take full advantage of the coordination services provided by ZK to create distributed applications.     It contains conceptual and practical information. The first 4 parts of the Guide show a higher-level discussion of the ZK concept. They are necessary to understand how ZK works and how to use ZK. The first 4 parts do not contain the source code, but do assume that you are familiar with the issues associated with distributed computing. The first 4 parts include: Data model session monitoring consistency Assurance
The latter 4 sections provide programming practices bindings Building Unit: Zookeeper Operation Wizard Program Structure FAQ and troubleshooting

The data model ZK has a hierarchical namespace, very similar to a distributed file system. The only difference is that a node in a namespace can have not only data but also byte points. As if there is a file system, the file can also be a directory. The node path is represented as a canonical, absolute, and slash-splitting path. There is no relative reference.     Any Unicode character can be used in a path, except for the following restrictions: 1. Null NULL characters cannot be part of a path.  2, the following characters can not be used, or rendering is not good, or show abnormal.     \-\ and \-\? 3, the following characters are not allowed: \? -UF8FFF, \?-UFFFF, \uxfffe-\UXFFFF (where X is a digit 1-e), \?     - \?. 4, "." Characters can be used as part of the name, but "." "". " A node in a path that cannot be used alone. Because ZK does not use relative paths. The following path is invalid: "/a/b/./c" or "/a/b/...     /C ". 5, "Zookeeper" is a reserved string.
Each node in the node ZK tree is called a znode. Znode has a stat structure that contains the version number of the data and ACL changes. The stat structure also contains a timestamp. The version number plus the timestamp allows ZK to verify the cache and coordinate the update. Each time a node's data changes, the version number increases. The client obtains the data, and also gets the version number of the data. When the client performs an update or deletion, it must provide the data version number of the node to be manipulated.     If the supplied version number does not match the actual version number, the update fails. Znode is the main object of programmer action. There are several features to mention: The monitoring client can set up monitoring on the node. The change in the node triggers the monitoring and then clears the monitor (similar to the Edge trigger in event programming, only once). When ZK triggers a monitor, it sends a notification to the client.
Data stored in data access nodes is read and written by atoms. Reading gets all the data, and the write updates all the data.     Each node has access control list ACL restrictions on who can do what. ZK design is not a general-purpose database or large object storage. Instead, it manages coordinated data. This data can be configuration, state information, collections, and so on. The common feature of all kinds of coordinated data is that they are small: in kilobytes. The ZK client and server implementations must have a complete check to ensure that the node's data is less than 1M, but the data is much less than 1M on average. Manipulating relatively large data takes more time on some operations because it requires more data to be passed over the network or storage media, which can affect the latency of some operations. If large data storage is required, the usual pattern for processing this data is to store them on a block file system, such as NFS or HDFS, where the pointer to the storage location is stored in ZK.
The temporary node ZK has the concept of a temporary node. As long as the session that creates the node is active, the node exists. The session ends and the node is deleted. Because of this nature, temporary nodes are not allowed to have child nodes.
Sequential node-unique naming when creating nodes, ZK can be asked to append a monotonically increasing count to the end of the path. The count is unique to the parent node. The format of the count is%010d, such as/root/child_0000000000;/root/child_0000000001; note: The order number used to store the next count exists in a signed integer (4 bytes) maintained by the parent node. When incremented by more than 2147483647, the count overflows.
Time ZK tracks time in a variety of ways zxid each time a change to the ZK state, a token is received, in the form of a transaction number (ZK transaction ID). This exposes the full sequence of all changes to ZK.         Each change will have a unique zxid, if the zxid1 is smaller than Zxid2, then zxid1 occurs before Zxid2.         The change of the version number node increments one version number of the node, the version number of the node data change, the version number of the node point change, and the version number of the node ACL change. Tick (clock clicks, a fixed interval) when using ZK services with multiple servers, the server uses ticks to define the timing of events, such as state uploads, session timeouts, and connection timeouts between servers.         Ticktime is only indirectly exposed (2*ticktime) through the smallest time-out period; If the client request timeout is less than the minimum timeout, the server notifies the client that the timeout is the minimum timeout. Real time ZK does not use the actual time, or the clock time. In addition to node creation or modification, the timestamp is stored in the stat structure.
    STAT structure   The stat structure of each node consists of the following attributes:         CZXID   The change corresponding to the creation of this node, the transaction number     & nbsp   MZXID   Last modified the change of this node the corresponding transaction number         ctime   node creation of the number of milliseconds         Mtime & The number of milliseconds the node was last modified         version   node data change version number         cversion   node sub node changed More version number         aversion   node ACL change version number          ephemeralowner   Create node Session ID (Temporary node), non-temporary node for 0         datalength   node data length         Numchildren   byte point Number of