Depth understanding of architecture ZooKeeper

Previous article, we explained the ZooKeeper to get started, this article focuses on the next ZooKeeper architecture, understanding ZooKeeper architecture can help us better design collaboration services.

First we look at the overall architecture diagram of ZooKeeper.

ZooKeeper overall architecture

upload/2020_01/200118155149391.png

Applications using ZooKeeper ZooKeeper client library to use the service, the establishment of a session of a client and ZooKeeper node in the cluster, ZooKeeper client is responsible for interaction and ZooKeeper cluster. ZooKeeper cluster can have two modes: standalone mode and quorum mode. ZooKeeper ZooKeeper node cluster in standalone mode as well as a stand-alone, standalone mode is typically used to develop. Usually in production environments ZooKeeper quorum mode, the plurality of replacement ZooKeeper ZooKeeper nodes in the cluster quorum mode.

Session is an important concept ZooKeeper client, create a session ZooKeeper ZooKeeper client library and nodes in the cluster. The client can take the initiative to close the session. Also, if the node does not receive data ZooKeeper client within the timeout time associated with the session, then, the node will ZooKeeper closed session. In addition ZooKeeper ZooKeeper client library If you find a connection error, it will automatically establish a connection with other ZooKeeper nodes.

The figure below shows how ZooKeeper client is re-connected?

ZooKeeper reconnection

upload/2020_01/200118155134181.png

At first ZooKeeper ZooKeeper session client and cluster node 1 established after a period of time, ZooKeeper node 1 fails, the client automatically and ZooKeeper ZooKeeper cluster node 3 to re-establish a session connection.

Quorum mode in ZooKeeper ZooKeeper cluster comprising a plurality of nodes. FIG ZooKeeper Cluster has three nodes, wherein the node is a leader node 1, node 2 and node 3 are nodes follower. Only one cluster leader node, there may be a plurality of nodes follower, leader node can process read and write requests, read requests follower can only process. Upon receipt of a write request follower write request will be forwarded to the leader to deal with.

Quorum mode

upload/2020_01/200118155134182.png

Here's under ZooKeeper ensure data consistency:

Data consistency

    Linearization (Linearizable) writes: arrives first write requests will be processed first leader, leader decides to perform sequential write requests.
    Client FIFO order: a request from a given client execution order of transmission.

To give you a better understanding of the Quorum mode, the following will configure ZooKeeper cluster Quorum mode of a 3 node.

First, we need three profiles, dataDir and clientPort configuration items to configure different values. server.n section 3 of the configuration file are the same. In server.1 = 127.0.0.1: 3333: 3334, where 3333 is the port number of the communication between the quorum, 3334 is the port number for the leader election.

In dataDir also need to create a directory for each node myid file, the contents of which is a number used to identify the current host, profile configuration server.n in n Why are the numbers, then myid file to enter this number.

The following is a node of the first profile, wherein the directory is node1, port number is 2181, the directory further node2 two nodes respectively and node3, port numbers 2182 and 2183, respectively, the lowermost three rows are the same of:

# Heartbeat check time of 2 seconds
tickTime = 2000
# initialization connected to the frequency and spacing server, a total time of 10 * 2 = 20 sec
10 initLimit =
frequency communication between # ZK Leader and follower, the total time of 5 * 2 = 10 seconds
= 5 syncLimit
# database snapshots stored in memory location, if you do not set the parameters, update transaction logs will be stored in the default location.
= dataDir / Data / ZK / Quorum / node1
# ZK server listening port 
clientPort = 2181

server.1=127.0.0.1:3333:3334
server.2=127.0.0.1:4444:4445
server.3=127.0.0.1:5555:5556

Let's start this cluster, the first node first start, start a command as follows:

zkServer.sh start-foreground /usr/local/apache-zookeeper-3.5.6-bin/conf/zoo-quorum-node1.cfg

Note: start-foreground option zkServer.sh running in the foreground, the log directly hit the console. If we hit the log file, the log will hit three zkServer.sh the same file.

In the first start after the log node appears as follows:

The reason for the three node configuration file configuration, but only started one node, at present he and the other two other nodes can not establish a connection, it is reported this problem.

Then start the second node, run the following command:

zkServer.sh start-foreground /usr/local/apache-zookeeper-3.5.6-bin/conf/zoo-quorum-node2.cfg

After the start, we can find in the log node 2 in such a line:

2019-12-29 13:15:13,699 [myid:2] - INFO  [QuorumPeer[myid=2](plain=/0.0.0.0:2182)(secure=disabled):Leader@464] - LEADING - LEADER ELECTION TOOK - 41 MS

This indicates that the node 2 becomes the leader node, can also be found in the following line of the log in the log node 1, node 1 became described follower node.

2019-12-29 13:15:13,713 [myid:1] - INFO  [QuorumPeer[myid=1](plain=/0.0.0.0:2181)(secure=disabled):Follower@69] - FOLLOWING - LEADER ELECTION TOOK - 61 MS

For a three-node cluster because it represents the most two, Quorum pattern is formed, the next start of the third node, run the following command:

zkServer.sh start-foreground /usr/local/apache-zookeeper-3.5.6-bin/conf/zoo-quorum-node3.cfg

After starting in the log has the following line, a third node joined the cluster, and a node is added as a follower.

2019-12-29 13:15:52,440 [myid:3] - INFO  [QuorumPeer[myid=3](plain=/0.0.0.0:2183)(secure=disabled):Follower@69] - FOLLOWING - LEADER ELECTION TOOK - 15 MS

Let's start the client to use this three-node cluster, add the -server option in the command, followed by the specified host name and port number three nodes, the command is as follows:

zkCli.sh -server 127.0.0.1:2181,127.0.0.1:2182,127.0.0.1:2183

2019-12-29 13:45:44,982 [myid:127.0.0.1:2181] - INFO  [main-SendThread(127.0.0.1:2181):ClientCnxn$SendThread@1394] - Session establishment complete on server localhost/127.0.0.1:2181, sessionid = 0x101fff740830000, negotiated timeout = 30000

Logs can be seen by starting the client and port number 2181 to establish a connection node, which is the first node and a connection is established.

We execute ls -R / command data look znode this cluster.

[zk: 127.0.0.1:2181,127.0.0.1:2182,127.0.0.1:2183(CONNECTED) 1] ls -R /
/
/zookeeper
/zookeeper/config
/zookeeper/quota

Let's kill a ZooKeeper node, to see whether the client can re-connect. Now we even node 1, the node 1 kill us, you can find the client and the port number 2183 of the node to re-establish a connection, that is, and established a connection node 3 in the client's log.

2019-12-29 14:03:31,392 [myid:127.0.0.1:2183] - INFO  [main-SendThread(127.0.0.1:2183):ClientCnxn$SendThread@1394] - Session establishment complete on server localhost/127.0.0.1:2183, sessionid = 0x101fff740830000, negotiated timeout = 30000

We then look at the client whether the normal use, performs ls -R /, can be found in the data can be returned to normal, indicating that the client is capable of normal use.

[zk: 127.0.0.1:2181,127.0.0.1:2182,127.0.0.1:2183(CONNECTED) 4] ls -R /
/
/zookeeper
/zookeeper/config
/zookeeper/quota


This article explains the ZooKeeper architecture, and how to configure a three-node cluster ZooKeeper.

Guess you like

Origin www.linuxidc.com/Linux/2020-01/162065.htm