The ZooKeeper data model is a tree-like data structure similar to the file system; and the difference between the file system is that data can be saved at every node in a tree (leaf node and non-leaf node) and that each node visit must start with a root node, with a slash as a separate access path, such as /root/a/b/, which has no concept of relative path, all nodes must be accessed through an absolute path; the node in the ZnodeZookeeper tree is referred to as znode, znode maintains a stat structure with a version number and

The ZooKeeper data model is a tree-like data structure similar to the file system; and the difference between the file system is that data can be saved at every node in a tree (folate node and non-folate node) and that each node visit must start with a root node, with a slash as a separate access path, such as /root/a/b/, which has no concept of relative path, and all nodes must be accessed through an absolute path;

The node in the ZooKeeper tree is known as znode, and znode maintains an stat structure containing version numbers and time stampes; the version numbers are constantly increment, the data contained in each znode are updated and the version numbers are changed;

When the client tries to update or delete a znode, it must provide the current version number of the znode that it wants to update/delete, and if the version number is incorrect, the update/deletion will fail (a somewhat similar optimistic lock to the database operation).

The client can add an observer to znode (similar to the event) and when znode changes, the observer is triggered and the corresponding client receives a notification;

The Zookeeper client can set up an observer for three operations: exists, get Children, getData:

When znode's subpoint is created or deleted, triggers when znode itself is deleted

Trigger when znode is created, deleted or the data is updated

Trigger when znode is deleted or znode data is updated

The observer will only be triggered once and will need to be re-registered after triggering if he or she wants to be triggered several times; the common place for the observer is the use of ZooKeeper as a configuration centre, with various clients (applications) listening to znode through the observer to obtain the latest configuration;

When creating a Znode, you can ask ZooKeeper to add a single incremental counter to this znode so that you can create several identical znodes under the same parent node, and each znode ends with a string of numbers and increases it single-transit;

This counter is unique only at the same parent's node, with a maximum value of 2147483647 and will spill over after;

Znode contains two types: temporary znode and persistent znode; temporary znode will be deleted when the client who created the znode is overtimed, whereas the persistent znode has nothing to do with the client; it can only be clearly deleted;

Temporary Znode cannot have a sub-node, but it is visible to all clients;

The sequenced Znode and temporary Znode combinations can serve as distribution locks, operating as: the client that creates the minimum value of the sequenced znode as the recipient of the distribution lock, and when the client closes the Session, the created znode will be removed, while the remaining creation of the minimum order znode will capture the distribution lock; in order to avoid the shock effects, each client will only need to set an observer on the slightly smaller znode, so that when the znode is removed, only one client will be awakened.

ZooKeeper uses the Master/Slave model to achieve the Leader electoral mechanism through the ZAB algorithm;

All of ZooKeeper's machines can be divided into three categories: Leader, Follower, Learner, which is used mainly to synchronize Znode data, and the elections are held mainly between multiple Follower; the purpose of the elections is mainly to elect as Leader the machine holding a relatively large (relatively majority) identification ID for Zxid and Myid (ZooKeeper server);

Each new operation in the ZooKeeper cluster will have a unique global identity, known as zxid, or ZooKeeper Affairs ID, which will always be incremental;

Zxid is a 64-digit figure with two parts: term of office (epoch) and counting (counter), 32 for term of office and 32 for number of number of number of places; the term of office will be added 1 after the election of a new Leader, and the counting will be increased during the same Leader term, and the sequence of operations will be recorded in this way.

The core of the ZAB algorithm is a two-to-two comparison between multiple Followers, and if a Follower's zxid + myids are larger than n/2+1 (n is the total number of Followers), they will be elected as Leader;

Just because the elections required a majority of them, the cluster collapsed if the majority of them crashed.

The ZooKeeper group is all done by Leader and then synchronized to Follower via Leader, which does not guarantee synchronisation to all Follower before returning the results to the client, as long as half (n/2+1) Follower is successful;

The client can connect to any machine in the cluster for reading, but cannot guarantee that the latest data can be read, so it is better to call Synchronize the latest data before GetData.

ZooKeeper Basic Knowledge Summary