[ZooKeeper] Zookeeper Developer Handbook

Zookeeper data model

Zookeeper has a hierarchical name space (name space), much like a standard distributed file system, the difference is that each node can be associated Data and child nodes. The path of the node is a canonical, absolute, slash-separated path; like the following:

Znodes

Each node in the Zookeeper tree is called A znode; Znodes maintain the following statistical structure

★ Version number of data changes: used with the timestamp to verify the cache and coordinate updates. Each time the data in the node changes, the version number will also increase. For example, once the client receives the data, it will also receive the version of the data. When the client performs an update or delete operation, it must provide the version number of the data of the node he wants to change. If the provided version number cannot match the actual version number of the current data, the update operation will fail (this behavior can be overridden)

★ acl (Access Control List) changed version Number

★ Timestamp

Several features related to Znodes

★ Watches: The client can be set on znode monitor. The change of znode will trigger the monitoring, and then clear the monitoring. Once the monitoring is triggered, Zookeeper will send a notification to the client.

★ Data access: The reading and writing of data in znode are atomic; read will read all data related to znode, and write will replace all data in znode. Each node has an access control list (Access Control List ACL) to restrict who can do what. Zookeeper is not designed to be a regular database or storage of large objects. If required, it can be stored in a large-capacity storage system (such as NFS or HDFS);

★ Temporary nodes: temporary nodes are created along with nodes The session exists and dies, and the temporary node is not allowed to have child nodes;

★ Sequence node—unique naming: After creating a node, you can also request zookeeper to append a monotonic increase at the end of the path Counter. This counter is unique relative to the parent node;

★ Container node (added in version 3.6.0): A container node is a special node used in scenarios such as leader and lock.

Time in Zookeeper

Zookeeper has multiple ways to track time:

★ zxid: Each change of Zookeeper status will receive a mark in the form of zxid (Zookeeper transaction id). This mark shows the sequence of all changes in Zookeeper. Each change has a unique zxid. If zxid1 is less than zxid2, it means that zxid1 occurs before zxid2.

★ Version numbers: Each change of the node will cause one of the version numbers of the node to increase. Three version numbers:

version: the version number of the znode data change;

cversion: the version number of the znode child node change;

aversion: znode acl change The version number of ;

★ Tick (ticks): When using multi-service Zookeeper, the server uses the ticket to define the time of the event, such as status upload, session timeout, and connection timeout between nodes.

★ Real time: Zookeeper will not use real time or clock time, except that the timestamp is placed in the stat structure when znode is created and znode is modified.

Zookeeper Stat Structure (data structure)

Each znode consists of the following fields:

< li style="margin-top:0.5em; margin-bottom:0.5em; padding:0px 5px">

czxid

The zxid of the change that caused this znode to be created.

• mzxid

  The zxid of the change that last modified this znode.

• pzxid

  The zxid of the change that last modified chi ldren of this znode.

• ctime

  The time in milliseconds from epoch when this znode was created.

• < p style="line-height:15.36px; text-align:left; margin:0px; padding:0px">mtime

  The time in milliseconds from epoch when this znode was last modified.

• version

  The number of changes to the data of this znode.

• cversion

  The number of changes to the children of this znode.

• aversion

  The number of changes to the ACL of this znode.

• ephemeralOwner

  The session id of the owner of this znode if the znode is an ephemeral node. If it is not an ephemeral node, it will be zero.

• dataLength< /p>

  The length of the data field of this znode.

• numChildren

  The number of children of this znode.

Zookeeper session

Zookeeper client uses language binding to create a handle to the service to establish a session with the Zookeeper service . Once the session is created, the handle is in the CONNECTING state, and the client client class library is connected to one of the servers in the Zookeeper service, at this time it is in the CONNECTED state. Under normal circumstances, it will be in either of these two states. If an unrecoverable error occurs, such as a session timeout or authentication failure, or the application explicitly closes the handle, the handle will be in the CLOSED state. The following flowchart shows the possible states:

In order to create a client session, the application code must provide a connection string that contains a comma-separated host:port number in pairs, Each host: The port number corresponds to a Zookeeper server, such as 127.0.0.1:4545 or 127.0.0.1:3000, 127.0.0.1:3001, 127.0.0.1:3002. The Zookeeper client will choose any server to connect to. If the connection fails or is disconnected from the server for other reasons, the client will automatically try to connect to the next server in the list until the connection is re-established.

When the client gets the handle to connect to the Zookeeper service, Zookeeper creates a Zookeeper session, which is represented by a 64-bit number and points to the client. If the client connects to another Zookeeper server, the session id will be sent as part of the handshake before connecting. As a security measure, the server creates a password for the session id that all servers can verify. This password will be sent to the client with the session id when the client establishes a session. Whenever the client re-establishes a connection with a new server, the client will send the password and session id.

Session expiration is managed by the Zookeeper cluster itself, not the client. When the ZK client establishes a connection with the cluster, a timeout period is provided. This timeout period is used by the cluster to determine when the client’s session expires. When the cluster cannot monitor the client within the specified session timeout period, it means a timeout. When the session times out, the cluster will delete all nodes belonging to the session and notify the connected clients. . At this time, the client with the expired session remains disconnected from the cluster. Unless a new connection is established with the cluster, the session will not be notified that the session has expired.

The other parameter of the ZK session establishment call is the default watcher. The watcher will be notified when there is any state change in the client. For example, if the client loses the connection with the server, the watcher will be notified, or the client’s session expires, and so on.

For the original text, please refer to the official document.

For building, please refer to: ZK cluster Installation configuration