Features of zookeeper and its utilization scenarios (distributed locks and Master election)

Features of zookeeper and its utilization scenarios (distributed locks and Master election)

The data structure of zookeeper

Zookeeper's data model is similar to the distributed file system, which is a hierarchical attribute structure, as shown in the figure. Unlike the file system, Zookeeper's data is stored in a structured manner, and does not physically reflect files and directories.

​ Each node in the Zookeeper tree is called a Znode, and the Znode maintains a Stat state information, which includes the time and version of data changes. And each Znode can set a value. Zookeeper does not need to communicate with the database or store large-capacity objects. It only manages and coordinates related data. Therefore, it is not recommended to set the data size of value very large. Larger data will Bring greater network overhead.

​ The data of each node on Zookeeper is allowed to be read and written. Reading means obtaining the value data on the specified Znode, and writing means modifying the value data on the specified Znode. In addition, the creation rules of nodes are similar to the creation rules of files in the file system. Must be created hierarchically. To give a simple example, if you need to create /node/node1/node1-1, you must first create two hierarchical nodes /node/node1.

Features of Zookeeper

When a Znode in Zookeeper is created, it is necessary to specify the type of node. The node types are divided into:

• Persistence node, the data of the node will be persisted to disk,
• For temporary nodes, the life cycle of the node is consistent with the statement cycle of the client that created the node. Once the session of the client ends, the temporary node created by the client will also be deleted.
• For ordered nodes, an increasing sequence will be added after the created node, which is unique under the same level of parent nodes. It should be noted that persistent nodes or temporary nodes can also be set as ordered nodes. That is, persistent nodes or temporary ordered nodes.

After version 3.5.3, two types of nodes were added, namely

• Container node, when the last node under the container node is deleted, the container node will be deleted.
• For TTL nodes, we can set a survival time for persistent nodes or persistent ordered nodes. If the node has no modification and no child nodes within the survival time, it will be automatically deleted.

It should be noted that in the same directory, the name of the node must be unique, just like we cannot create two folders with the same name in the same directory.

Watcher mechanism

Zookeeper provides a subscription/notification mechanism for Znode, that is, when the state of the Znode node changes or the connection state of the Zookeeper client changes, an event notification will be triggered. This mechanism provides a very good solution for service callers to perceive changes in service providers in a timely manner during service registration and discovery.

In the java API provided by Zookeeper, three mechanisms are provided to register and monitor Znodes, namely:

• getData() is used to obtain the value information of the specified node, and can register for monitoring. When the monitored node is created, modified, or deleted, an event notification will be triggered and responded.
• getChildren() is used to get all the child nodes of the specified list, and allows the registration of listeners. When the child nodes of the listener node are created, modified, or deleted, a corresponding event notification is triggered.
• exists(), used to judge whether the specified node exists, and can also register to monitor the specified node. The time type of monitoring is the same as getData().

The triggering of the Watcher event is one-time. For example, the client registers the listener through getData('/node',true). If the data of the /node node is modified, the client will receive a modification event notification, but the /node will When a change occurs, the client cannot receive the Watcher event. To solve this problem, the client must retest the registration event in the received event callback.

Analysis of Common Application Scenarios

Based on the characteristics of nodes in Zookeeper, it can provide solutions for various application scenarios.

distributed lock

We can use the characteristics of zookeeper to implement distributed locks. The essence of locks is exclusiveness, which is to prevent multiple processes from accessing a shared resource at the same time.

This operation can be accomplished by using the characteristics of the temporary node and the uniqueness of the node at the same time.

• The process of acquiring a lock

  When acquiring an exclusive lock, all clients can create a temporary node /lock under the /Exclusive_Locks node on the Zookeeper server. Based on the uniqueness of nodes at the same level, Zookeeper will ensure that only one client among all clients can be successfully created. The successfully created client obtains an exclusive lock. Clients that do not obtain the lock need to monitor the child nodes under the /Exclusive_Locks node through the Watcher mechanism. change event.

• The process of releasing the lock

  In the process of acquiring the lock, we define the lock node/lock as a temporary node. According to the characteristics of the temporary node, the release of the lock will be triggered in the following two cases.

  • The client that acquired the lock disconnected from the server due to an exception. Based on the temporary node, the /lock node will be automatically deleted.
  • After the client that acquires the lock executes the business logic, it actively deletes the created /lock node.

  When the /lock node is deleted, Zookeeper will notify other clients that listened to the changes of the /Exclusive_Locks subnode. After receiving the notification, these clients initiate the operation of creating /lock nodes again to obtain exclusive locks.

Master Election

Master election is a very common scenario in a distributed system. In a distributed architecture, in order to ensure the availability of services, cluster mode is usually adopted, that is, when one of the machines goes down, other nodes in the cluster will take over from the failed node to continue Work. In this scenario, you need to elect a node from the cluster as the master node, and the remaining nodes are on standby as backup nodes. When the original Master node fails, it is necessary to elect a node from other backup nodes in the cluster as the Master node to continue to provide services.

• The same node cannot repeatedly create an existing node. This is somewhat similar to the implementation scenario of distributed locks. In fact, the same is true for the Master election scenario. Assuming that there are 3 nodes in the cluster and the Master needs to be elected, then these three nodes go to the Zookeeper server to create a temporary node/master-election at the same time. Due to the characteristics of the node, only one client will be created successfully, and the Watcher is registered for this node. The event is used to monitor whether the current Master machine is alive. Once the Master is found to be "hanging", that is, the /master-election node is deleted, other clients will re-initiate the Master election operation.

• It is realized by using the characteristics of temporary ordered nodes. All clients participating in the election create a temporary ordered node under the /master node of the Zookeeper server. The node with the smallest number represents the Master. Subsequent nodes can monitor the deletion time of the previous node to trigger re-election.

Example: three nodes client01, client02, and client03 go to the /master node of Zookeeper Server to create temporary ordered nodes, client01, the node with the smallest number, represents the Master node, and three nodes client02 and client03 go to the /master node of Zookeeper Server to create temporary and valid nodes Node, client01 creates /client01-0000000001, client-02 creates /client02-0000000003, client-03 creates /client03-0000000002, the node with the smallest number client01 represents the Master node, client02 and client03 will respectively monitor the node with a smaller number than their own through the Watcher mechanism a node. For example, client02 monitors /client03-0000000002, and client03 monitors /client01-0000000001. If the smallest node is deleted, client03 will be elected as the Master.

Implementation Principle of Zookeeper Registration Center

After the Dubbo service is registered on Zookeeper, you can see the tree structure shown in the figure below on the Zookeeper server.

​ When the Dubbo service is started, it will take the URL of the current service created under /dubbbo/com.scmpe.dubbo.IHelloService/providesthe directory , where com.scmpe.dubbo.IHelloServiceit is the full path name of the interface publishing the service, and providers indicate the type of service provider, indicating the dubbo://ip:port protocol type and access address of the service publishing. Among them, the URL is a temporary node, and the others are all persistent nodes. Why does the URL use a temporary node here, because if the server that registered the node goes offline, the URL address of the server will be removed from the Zookeeper server.

​ When the Dubbo service consumer starts, it will /dubbbo/com.scmpe.dubbo.IHelloService/providesregister Watcher to monitor the sub-nodes under the node, so that it can perceive the change of the service provider node's offline and offline, and prevent the request from being sent to the offline server to cause access failure. At the same time, service consumers will write their own URLs /dubbbo/com.scmpe.dubbo.IHelloService/cosumers below . The purpose of this is to see which services a certain Dubbo service is being called on the monitoring platform; most importantly, if consumers of Dubbo services need to call IHelloService service, then it first goes back to /dubbbo/com.scmpe.dubbo.IHelloService/provides the path to obtain the provider URL list of all services, and then calculates an address for remote access through the load balancing algorithm.

​ On the whole, the service registration and dynamic perception functions use temporary nodes, persistent nodes, Watchers, etc. in Zookeeper. Looking back at the previously analyzed Zookeeper application scenarios, we can find that almost all scenarios are based on these. . In addition, it must be mentioned that Dubbo can also implement the following functions for different situations.

• Based on the characteristics of the temporary node, when the service provider goes down or goes offline, the registration center will automatically delete the information of the service provider
• When the registration center restarts, Dubbo can automatically reply to registration data and subscription requests.
• In order to ensure the security of node operations, Zookeeper provides ACL permission control, and in Dubbo, the authentication information of nodes can dubbo.registry.username/dubbo.registry.password be set through .
• The default root node of the registry is /dubbo. If you need to set different root nodes for different environments, you can use dubbo.registry.group to modify the root node name.