Shulou(Shulou.com)06/02 Report--

This article mainly introduces "how to apply zookeeper distributed coordination service". In daily operation, I believe many people have doubts about how to apply zookeeper distributed coordination service. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful to answer the doubts about "how to apply zookeeper distributed coordination service". Next, please follow the editor to study!

Distributed Services Coordinator zookeeper-Application scenarios and Monitoring

Zookeeper acts as a coordinator in distributed systems and can be applied to the implementation of Leader election, distributed locking, configuration management and other services. Below we learn and understand zookeeper (hereinafter referred to as ZK) from three aspects: API provided by zookeeper, application scenario and monitoring.

ZK API

ZK manages the stored data in the form of a Unix file system tree structure, as shown below:

Each of these tree nodes is called znode, and each znode is like a file, containing file meta-information (meta data) and data.

Below, we use server to represent the provider of the ZK service, and client represents the user of the ZK service. When the client connects to the ZK, the session session information is created accordingly.

There are two types of znode:

Regular: this type of znode can only be explicitly created or deleted by the client side

Ephemeral: this type of znode; can be created or deleted on the client side. When session terminates, ZK will also delete this type of znode.

When znode is created, it can also be marked with the sequential flag, and the znode marked with this logo will be appended with a self-increasing number suffix.

ZK provides the following API for client to manipulate data stored in znode and znode:

Create (path, data, flags): create a znode with a path of path, in which data [] data is stored. Flags can be set to Regular or Ephemeral, and optionally marked with sequential.

Delete (path, version): delete the znode of the corresponding path/version

Exists (path,watch): return true; if there is a znode corresponding to path. Otherwise, the false,watch flag can be used to set listening events.

GetData (path, watch): returns the data and meta information of the corresponding znode (such as version, etc.)

SetData (path, data, version): write data [] data to the znode of the corresponding path/version

GetChildren (path, watch): returns a collection of child nodes of the specified znode

ZK application scenario

Based on the operation of znode and znode data provided by the above ZK, Leader election, distributed lock, configuration management and other services can be easily realized.

Leader election

With Ephemeral marked with the sequential logo, we can achieve the Leader election. Suppose you need to select Leader from three client, and the implementation process is as follows:

1. Create a znode of Ephemeral type and mark it with the sequential flag:

[zk: localhost:2181 (CONNECTED) 4] ls / mastery [lock-0000000241, lock-0000000243, lock-0000000242]

2. Check all the znode under the / master path. If you create a znode with the lowest sequence number, you will consider yourself to be Leader;, otherwise record the znode whose sequence number is smaller than your own.

3. Non-Leader sets the listening event on the secondary sequence number znode, and repeat the above step 2

If the above / master/lock-0000000241 node is deleted (due to the corresponding client service exception or network exception, etc.), then the corresponding znode of / master/lock-0000000242 will promote itself to Leader. Client only cares about the znode and znode that it creates, which avoids the Herd Effect effect.

The implementation of the distributed lock is the same as that of the above Leader election. With a little modification, we can also implement the lease mechanism (time-limited authorization service) based on ZK.

Configuration management

Znode can store data. Based on this, we can use ZK to implement the configuration management of distributed systems. Suppose you need to synchronize the new ip/port to the A.conf configuration of the server in the whole network when you expand the device. The implementation process is as follows:

1. When An expands its capacity, znode is added to the ZK accordingly. The znode data is in the following form:

[zk: localhost:2181 (CONNECTED) 30] get / A/blk-0000340369 {"svr_info": [{"ip": "1.1.1.1.", "port": "11000"}]} cZxid = 0x2ffdeda3be.

2. Network-wide machine listening / A. When a new node joins the znode, the corresponding processing function is called to add the new ip/port of service A to the A.conf.

3. After completing step 2, continue to set up / A monitoring

The steps for service downsizing are similar. The corresponding ZK node is deleted when the machine goes offline, and the devices in the configuration are removed after the network-wide machines listen to the event.

ZK monitoring

ZK itself provides some "four-word commands". Through these four-character commands, we can obtain information about the role, number of znode, health status and other information of a ZK in a ZK cluster:

# echo "mntr" | / usr/bin/netcat 127.0.0.1 2181 zk_version 3.4.3-1240972, built on 02sweet 06and2012 10:48 GMTzk_packets_received 267044485 zk_packets_sent 267069992 zk_outstanding_requests 0 zk_server_state followerzk_znode_count 16216

The commonly used four-word commands are:

Mntr: displays information such as its role, number of znode, aPCge call time, number of packets received and sent, etc.

Ruok: diagnose whether your status is ok

Cons: show the current client connection

Just as we can't ask a drunken person if he or she is drunk, we can't be sure that a ZK that replies "imok" is the real ok. We can create / delete znode through the zkCli.sh simulation client that comes with ZK:

/ usr/local/zookeeper/bin/zkCli.sh create / zookeeper/test 'test' > / dev/null 2 > & 1/usr/local/zookeeper/bin/zkCli.sh delete / zookeeper/test > / dev/null 2 > & 1

Then judge whether the znode is added or deleted according to the returned value, so as to judge whether the ZK status is normal.

At this point, the study on "how to apply zookeeper distributed coordination service" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.