Basic concepts of Zookeeper (II.)

The first blog post, we have a simple understanding of zookeeper, and more obvious, easy to understand, this blog, we understand its basic concepts, as shown in the following figure:

Understanding its basic concepts helps us learn later, although today's articles are conceptual in nature, but significant. one, cluster role:

Zookeeper clusters usually have three roles: Leader,follower,observer.

role	Description
Leader Server	The core of the whole zookeeper cluster work mechanism, does not accept the client's request, mainly is responsible for carries on the vote the initiation and the resolution, updates the system state.
Follower Server	Zookeeper a follower of the cluster state, used to accept customer requests and return results to the client, participating in the leader poll.
Observer server	Acting as an observer, observer can receive client connections and forward write requests to leader nodes. But observer not participate in the voting process, only synchronized leader state. The purpose of observer is to extend the system and improve the reading speed.

The system model is shown in the figure:

Second, the session:

The session refers to the client and the Zookeeper server connection, the zookeeper session, the client relies on with the server to establish a TCP long connection to maintain a conversation, the client starts with the server first to establish a TCP connection, through this connection , the client can maintain a valid session with the server through heartbeat detection, and can also send requests to the zookeeper server and get a response. Third, data node:

There are two types of nodes in zookeeper:
1. A machine in the cluster becomes a node
2. Data unit Znode in the data model, divided into persistent nodes and temporary nodes

The Zookeeper data model is a tree, and the node of the tree is the znode,znode in which information can be saved.
As shown in the following illustration:

ZK general data structure is consistent with the above figure, as shown in the diagram above is like a tree, the tree has a root node, then some of its sub nodes, and then each child node can have children under it, most of the development is with the ZK of these data nodes, to read and write these data nodes, to complete the task.

Unlike traditional file systems, the data in zookeeper is stored in memory, which enables high throughput and low latency for distributed synchronization Services.

In the zookeeper data model of the example above, the following points are included: each node (Znode) stores synchronization-related data (this is the original intention of the zookeeper design, the amount of data is very small, probably B to KB level), such as state information, configuration content, location information, and so on. A znode maintains a state structure that includes: version number, ACL change, timestamp. Each time the Znode data changes, the version number is incremented so that the client's read request can retrieve the state-related data based on the version number. Each znode has an ACL that restricts access to the Znode. In a namespace, the read and write request operations on the data stored on the Znode are atomic. The client can set up a monitor (Watch) on one znode, and if the Znode data changes, zookeeper notifies the client, triggering the execution of the logic implemented in the monitor. Each client connects to the zookeeper, and a session is established, in which the connecting, connected, and closed three states may occur during the session. Zookeeper supports the concept of a temporary node (ephemeral Nodes), which is associated with a session in zookeeper, which is deleted if the connection is disconnected. Four, version:

The version in ZK is used to record the node data or the node's list of child nodes or the number of changes to the permission information, note that this is the number of changes. If the version of a node is 1, it means that the node has been modified once since it was created, so how does this release work, typically we can use the version to implement the distributed lock service. We know that in the database, there are generally two kinds of locks, one is pessimistic lock one is optimistic lock. Pessimistic lock

Pessimistic lock is also called pessimistic concurrent lock, is a very strict locking strategy in the database, with strong exclusivity, to avoid data inconsistency caused by different transactions to the same data concurrent update, the next transaction can not access the same resources before the last transaction is completed, and it is suitable for the scene that the data update is very competitive. optimistic Lock

Optimistic locks use more scenes than pessimistic locks, pessimistic locks believe that transaction access to the same data must be interfered with each other, so the simple and rough use of exclusive access, and optimistic locks that different transactions to access the same resources are rarely interfere with each other, so there is no need for concurrent control during transaction processing, Of course, optimistic lock is also a lock, it will still have concurrent control. Our usual practice for the database is to add a version field to each table, read the data before the transaction modifies the data, and then add the read version number to the condition of the UPDATE statement, for example, the version number read is 1, We modify the data statement can be written in this way, update so-and-so table set field a = So-and-so value where id=1 and Version=1, if the update failed to indicate that the other transactions have been modified data, the system needs to throw exceptions to the client, let the client handle themselves, The client can choose to retry. Lock, the ZK version has a similar effect.

ZK has three types of versions: version cversion aversion

Version Type	Description
Version	The version number of the current data node data content
Cversion	The version number of the current Data section idea node
Aversion	Current data node ACL change version number

v. Watcher (Event listener):

Watcherwatcher we can understand that he is an event listener.

Zookeeper allows the user to register some watcher on the specified node, and when the data node changes, the Zookeeper server sends the notification of the change to the interested client.

Two clients have registered the Watcher (event listener) in the zookeeper cluster, and when the node data in ZK changes, ZK sends the notification of this change to the client, and when the client receives this change notification, it can return to the ZK, To get detailed information on this data. ACL access control:

ACLs are shorthand for access control Lists, zookeeper use ACL policies for permission controls with the following permissions:
1. Create: Creation of child node permissions
2. READ: Getting Permissions for node data and child node lists
3. WRITE: Update node data permissions
4. Delete: Permissions to delete child nodes
5. ADMIN: Set permissions on Node ACLs

The above permission is somewhat similar to our information system's authority management, when we develop systems, we generally do these rights management of data, a ZK cluster may serve a lot of business, especially in some large companies, the ZK cluster node will hold important information, then this information is usually only for a part of the visitors open, ACLs allow us to authorize access to certain nodes to secure the data.

Next blog post we build zookeeper cluster.