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

This article mainly explains how to build a Zookeeper server, the content is clear, interested friends can learn, I believe that after reading it will be helpful.

What is ZooKeeper?

ZooKeeper is a top-level project of Apache, which provides efficient and highly available distributed coordination services for distributed applications, such as data publishing / subscribing, load balancing, naming services, distributed coordination / notification, distributed locking and other distributed basic services. Because of its convenient use, excellent performance and good stability, ZooKeeper is widely used in large-scale distributed systems such as Hadoop, HBase, Kafka and Dubbo.

There are three operation modes of Zookeeper: stand-alone mode, pseudo-cluster mode and cluster mode.

Stand-alone mode: this mode is generally suitable for the development and test environment, on the one hand, we do not have so many machine resources, on the other hand, the usual development and debugging does not need excellent stability. Cluster mode: a ZooKeeper cluster is usually composed of a group of machines. Generally, more than 3 machines can form a usable ZooKeeper cluster. Each of the machines that make up the ZooKeeper cluster maintains the current server state in memory, and each machine keeps communicating with each other. Pseudo-cluster mode: this is a special cluster mode in which all the servers in the cluster are deployed on a single machine. When you have a good machine on hand, if you deploy it in stand-alone mode, resources will be wasted. In this case, ZooKeeper allows you to start multiple ZooKeeper service instances on a single machine by starting different ports, so as to provide external services with the characteristics of cluster.

Knowledge of ZooKeeper

Role leader in Zookeeper (leader): responsible for initiating and deciding voting, updating system status follower (follower): used to receive client requests and return results to clients, voting observers (observer): can accept client connections and forward write requests to leader, but observer does not participate in the voting process, just to expand the system and improve the speed of reading.

Data Model of Zookeeper

Hierarchical directory structure, named in accordance with regular file system specifications, similar to Linux each node is called znode in zookeeper, and it has a unique path identification node Znode can contain data and child nodes, but a node of EPHEMERAL type cannot have multiple versions of data in a child node Znode. For example, there are multiple data versions in a path. Then querying the data under this path needs to take the version with the client application can set the monitor node on the node does not support partial read and write, but a complete read and write at one time

Node characteristics of ZooKeeper

ZooKeeper nodes are lifecycle, depending on the type of node. In ZooKeeper, nodes can be divided into persistent nodes (PERSISTENT), temporary nodes (EPHEMERAL) according to their duration, and sequential nodes (SEQUENTIAL) and unordered nodes (unordered by default) according to whether they are ordered or not.

Once a persistent node is created, it will always be saved in the Zookeeper unless it is actively removed (it will not disappear because the session of the client that created the node fails), temporary node

Application scenarios of Zookeeper

ZooKeeper is a highly available distributed data management and system coordination framework. Based on the implementation of the Paxos algorithm, the framework ensures the strong consistency of data in the distributed environment, and it is based on this characteristic that ZooKeeper solves many distributed problems.

It is worth noting that ZooKeeper is not naturally designed for these application scenarios, but is a typical usage later explored by many developers according to the characteristics of its framework and using a series of API interfaces (or primitive sets) provided by it.

Data publish and subscribe (configuration Center)

Publish and subscribe model, the so-called configuration center, as the name implies, is that publishers publish data to ZK nodes for subscribers to obtain data dynamically, and achieve centralized management and dynamic update of configuration information. For example, the global configuration information, the service address list of the service framework, etc., are very suitable for use.

Some configuration information used in the application is put on ZK for centralized management. This kind of scenario usually goes like this: when the application starts, it will actively obtain the configuration, and at the same time, register a Watcher on the node, so that every time there is an update in the configuration, it will notify the subscribing client in real time, thus achieving the goal of obtaining the latest configuration information. In the distributed search service, the meta-information of the index and the node state of the server cluster machine are stored in some designated nodes of the ZK for each client subscription. Distributed log collection system. The core job of this system is to collect logs distributed on different machines. The collector usually allocates the collection task unit according to the application, so it is necessary to create a node P with the application name as path on the ZK, and register all the machine ip of the application on the node P in the form of child nodes, so that when the machine changes, it can notify the collector to adjust the task assignment in real time. Some information in the system needs to be obtained dynamically, and there will be manual questions to modify this information. Usually an interface, such as the JMX interface, is exposed to get some information about the runtime. With the introduction of ZK, you don't have to implement your own solution, just store the information on the specified ZK node. Note: in the above-mentioned application scenarios, there is a default premise: scenarios where the amount of data is small, but the data may be updated quickly.

Load balancing

Load balancing here refers to soft load balancing. In a distributed environment, in order to ensure high availability, the same application or provider of the same service will usually deploy multiple copies to achieve peer-to-peer services. Consumers have to choose one of these peer-to-peer servers to execute the relevant business logic, among which the typical one is the producer and consumer load balance in message middleware.

Naming Service (Naming Service)

Naming service is also a common scenario in distributed systems. In a distributed system, by using naming services, client applications can obtain information such as the address and provider of resources or services according to the specified name. Named entities can usually be machines in a cluster, service addresses provided, remote objects, and so on-all of which we can collectively call names (Name). One of the more common is the list of service addresses in some distributed service frameworks. By calling the API provided by ZK to create the node, you can easily create a globally unique path, which can be used as a name.

Dubbo, the open source distributed service framework of Alibaba Group, uses ZooKeeper as its naming service to maintain the global service address list. In the Dubbo implementation: at startup, the service provider writes its URL address to the specified node / dubbo/$ {serviceName} / providers directory on the ZK, which completes the publication of the service. When the service consumer starts, subscribe to the provider URL address in the / dubbo/$ {serviceName} / providers directory and write its own URL address to the / dubbo/$ {serviceName} / consumers directory. Note that all addresses registered with ZK are temporary nodes, which ensures that service providers and consumers are automatically aware of changes in resources.

In addition, Dubbo has monitoring for service granularity by subscribing to the information of all providers and consumers under the / dubbo/$ {serviceName} directory.

Distributed notification / coordination

ZooKeeper has a unique watcher registration and asynchronous notification mechanism, which can well realize the notification and coordination between different systems in the distributed environment, and realize the real-time processing of data changes. The method of use is usually that different systems register the same znode on the ZK and listen for changes in the znode (including the content of the znode itself and its child nodes). If one system update the znode, then the other system can receive the notification and deal with it accordingly.

Another heartbeat detection mechanism: the detection system and the detected system are not directly related, but through the association of a node on the zk, the system coupling is greatly reduced. Another system scheduling mode: a system consists of a console and a push system, and the duty of the console is to control the push system to carry out the corresponding push work. Some of the operations that managers do in the console actually modify the status of some nodes on the ZK, and ZK notifies them of these changes to the client that registers Watcher, that is, the push system, and then makes the corresponding push task.

Another work reporting mode: some similar to the task distribution system, after the sub-task starts, register a temporary node to zk, and report their progress regularly (write the progress back to this temporary node), so that the task manager can know the progress of the task in real time.

Distributed lock

Distributed lock, which is mainly due to the fact that ZooKeeper ensures strong data consistency for us. Lock services can be divided into two categories, one is to keep exclusive, the other is to control the timing.

Maintaining exclusivity means that only one client who tries to acquire the lock can successfully acquire the lock. The usual practice is to treat a znode on zk as a lock, which is implemented by create znode. All clients create the / distribute_lock node, and the client that is successfully created owns the lock. Control timing, that is, all the views to acquire the lock of the client, will eventually be scheduled to execute, but there is a global timing. The practice is similar to the above, except that / distribute_lock already exists here, and the client creates a temporary ordered node under it (this can be specified by the node's attribute control: CreateMode.EPHEMERAL_SEQUENTIAL). The parent node (/ distribute_lock) of the Zk maintains a copy of the sequence, which ensures the timing of the creation of the child nodes, thus forming the global timing of each client.

Since the name of the child node under the same node cannot be the same, as long as the znode is created under a node, it indicates that the lock is successful. The registered listener listens to this znode and notifies other clients to lock it as soon as the znode is deleted. Create a temporary sequential node: create a node under a node, and a request creates a node. because it is sequential, the one with the lowest sequence number acquires the lock, and when the lock is released, notify the next sequence number to acquire the lock.

Distributed queue

In terms of queues, there are two kinds of queues, one is the conventional first-in-first-out queue, and the other is to wait for the members of the queue to gather before they are executed in order. The first type of queue is consistent with the basic principle of timing control in the distributed lock service described above, so I won't go into detail here.

The second queue is actually an enhancement based on the FIFO queue. Usually, you can set up a / queue/num node in advance under the znode of / queue, and assign a value of n (or directly assign n to / queue) to indicate the queue size. After that, each time a queue member joins, you can determine whether the queue size has been reached and decide whether execution can be started. A typical scenario for this usage is that in a distributed environment, a large task Task A can only be done when many subtasks are completed (or conditionally ready). At this time, when one of the subtasks is completed (ready), then set up your own temporary timing node (CreateMode.EPHEMERAL_SEQUENTIAL) under / taskList. When / taskList finds that the number of child nodes below it meets the specified number, it can proceed to the next step in sequence processing.

Use dokcer-compose to build a cluster

We have introduced so many application scenarios about ZooKeeper above, so let's first learn how to build a ZooKeeper cluster and then carry out the above application scenarios.

The directory structure of the file is as follows:

├── docker-compose.yml

Write docker-compose.yml files

The docker-compose.yml file is as follows:

Version: '3.4'services: zoo1: image: zookeeper restart: always hostname: zoo1 ports:-2181 environment: ZOO_MY_ID: 1 ZOO_SERVERS: server.1=0.0.0.0:2888:3888;2181 server.2=zoo2:2888:3888;2181 server.3=zoo3:2888:3888;2181 zoo2: image: zookeeper restart: always hostname: zoo2 ports:-2181 environment: ZOO_MY_ID: 2 ZOO_SERVERS: server.1=zoo1:2888:3888;2181 server.2=0.0.0.0:2888:3888 2181 server.3=zoo3:2888:3888;2181 zoo3: image: zookeeper restart: always hostname: zoo3 ports:-2183 zookeeper restart 2181 environment: ZOO_MY_ID: 3 ZOO_SERVERS: server.1=zoo1:2888:3888;2181 server.2=zoo2:2888:3888;2181 server.3=0.0.0.0:2888:3888;2181

In this configuration file, docker runs three zookeeper images and binds the local ports 2181, 2182, and 2183 to port 2181 of the corresponding container through the ports field.

ZOO_MY_ID and ZOO_SERVERS are two environment variables needed to build a Zookeeper cluster. ZOO_MY_ID identifies the id of the service, which is an integer between 1 and 255. it must be unique in the cluster. ZOO_SERVERS is a list of hosts in the cluster.

Execute docker-compose up under the directory where docker-compose.yml is located, and you can see the startup log.

Connect ZooKeeper

After starting the cluster, we can connect to ZooKeeper to perform node-related operations on it.

First, we need to download the ZooKeeper. ZooKeeper download address. Unzip it into its conf directory and change zoo_sample .cfg to zoo.cfg.

Profile description

# number of heartbeats in The number of milliseconds of each tick# tickTime:CS communications # the interval between Zookeeper servers or clients and servers to maintain a heartbeat, that is, a heartbeat is sent at each tickTime time. TickTime is in milliseconds. TickTime=2000# The number of ticks that the initial# synchronization phase can take# initLimit:LF initial communication time # the maximum number of heartbeats (number of tickTime) that can be tolerated during the initial connection between the follower server (F) and the leader server (L) in the cluster. InitLimit=5# The number of ticks that can pass between# sending a request and getting an acknowledgement# syncLimit:LF synchronous communication time limit # the maximum number of heartbeats (number of tickTime) that can be tolerated between requests and responses between follower servers and leader servers in the cluster. SyncLimit=2# the directory where the snapshot is stored.# do not use / tmp for storage, / tmp here is just# example sakes.# dataDir: data file directory # Zookeeper the directory where the data is saved. By default, Zookeeper saves log files for writing data to this directory as well. DataDir=/data/soft/zookeeper-3.4.12/data# dataLogDir: log file directory # Zookeeper the directory where the log file is saved. DataLogDir=/data/soft/zookeeper-3.4.12/logs# the port at which the clients will connect# clientPort: client connection port # the port on which the client connects to the Zookeeper server. Zookeeper listens on this port and accepts access requests from the client. ClientPort=2181# the maximum number of client connections.# increase this if you need to handle more clients#maxClientCnxns=60## Be sure to read the maintenance section of the# administrator guide before turning on autopurge.## http://zookeeper.apache.org/doc/current/zookeeperAdmin.html#sc_maintenance## The number of snapshots to retain in dataDir#autopurge.snapRetainCount=3# Purge task interval in hours# Set to "0" to disable autopurge feature#autopurge.purgeInterval=1# server name and address: cluster information (server number, server address, LF communication port Election port) # this configuration item is written in a special format as follows: # server.N=YYY:A:B#, where N represents the server number, YYY represents the IP address of the server, and An is the LF communication port, indicating the port of information exchanged between the server and the leader in the cluster. B is the election port, which indicates the port on which the servers communicate with each other when the new leader is elected (when the leader dies, the rest of the servers will communicate with each other and select a new leader). In general, the A port of each server in the cluster is the same, and so is the B port of each server. However, when the pseudo-cluster is used, the IP address is the same, only when the A port and B port are different.

You don't have to modify zoo.cfg, just configure it by default, and then execute the command in the unzipped bin directory. / zkCli.sh-server 127.0.0.1 zkCli.sh 2181 can be connected.

Welcome to ZooKeeper!

2020-06-01 15 myid:]-INFO [main-SendThread (localhost:2181): ClientCnxn$SendThread@1025]-Opening socket connection to server localhost/127.0.0.1:2181. Will not attempt to authenticate using SASL (unknown error)

JLine support is enabled

2020-06-01 15 main-SendThread 03V 52576 [myid:]-INFO [main-SendThread (localhost:2181): ClientCnxn$SendThread@879]-Socket connection established to localhost/127.0.0.1:2181, initiating session

2020-06-01 15 main-SendThread 03VR 52599 [myid:]-INFO [main-SendThread (localhost:2181): ClientCnxn$SendThread@1299]-Session establishment complete on server localhost/127.0.0.1:2181, sessionid = 0x100001140080000, negotiated timeout = 30000

WATCHER::

WatchedEvent state:SyncConnected type:None path:null

[zk: 127.0.0.1 2181 (CONNECTED) 0]

Next we can use the command to view the node

Use the ls command to view what is contained in the current ZooKeeper

Command: ls /

[zk: 127.0.0.1 ls 2181 (CONNECTED) 10]

[zookeeper] ```

A new znode node "zk" and the string associated with it are created

Command: create / zk myData

[zk: 127.0.0.1 create 2181 (CONNECTED) 11] create / zk myData

Created / zk [zk: 127.0.0.1 zk 2181 (CONNECTED) 12] ls / [zk, zookeeper] [zk: 127.0.0.1 zk 2181 (CONNECTED) 13] ```

Get znode node zk

Command: get / zk

[zk: 127.0.0.1 get 2181 (CONNECTED) 13] get / zk

MyData cZxid = 0x400000008 ctime = Mon Jun 01 15:07:50 CST 2020 mZxid = 0x400000008 mtime = Mon Jun 01 15:07:50 CST 2020 pZxid = 0x400000008 cversion = 0 dataVersion = 0 aclVersion = 0 ephemeralOwner = 0x0 dataLength = 6 numChildren = 0

`

Delete znode Node zk

Command: delete / zk

[zk: 127.0.0.1 delete 2181 (CONNECTED) 14] delete / zk

[zk: 127.0.0.1 ls 2181 (CONNECTED) 15] ls / [zookeeper] ```

Due to the limited space, the next article will be implemented one by one in code according to the ZooKeeper application scenarios mentioned above.

ZooKeeper's Docker configuration file store

ZooKeeper's Docker configuration file store

ZooKeeper's Docker configuration file store

You can pull the project directly from the above. It only takes two steps to start RocketMQ.

Pull the project from GitHub and execute the docker-compose up command in the ZooKeeper folder

After reading the above content, do you have a further understanding of how to build a Zookeeper server? if you want to learn more, please follow the industry information channel.

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.