Zookeeper cluster construction and zab protocol

In a single-machine environment, jdk zookeeper is installed, based on a virtual machine, the zookeeper pseudo cluster is built. The zookeeper cluster contains three nodes, and the external service port numbers of the nodes are 2181, 2182, and 2183.

  1. Based on zookeeper-3.4.10, copy three copies of zookeeper installed server files, the directory names are zookeeper2181, zookeeper2182, zookeeper2183
cp -r zookeeper-3.4.10 zookeeper2181
cp -r zookeeper-3.4.10 zookeeper2182
cp -r zookeeper-3.4.10 zookeeper2183
  1. Modify the configuration file corresponding to the zookeeper2181 server.
# The number of milliseconds of each tick
tickTime=2000
# The number of ticks that the initial 
# synchronization phase can take
initLimit=10
# The number of ticks that can pass between 
# sending a request and getting an acknowledgement
syncLimit=5
# the directory where the snapshot is stored.
# do not use /tmp for storage, /tmp here is just 
# example sakes.
dataDir=/home/zookeeper/zookeeper2181/data
# the port at which the clients will connect
clientPort=2181
# 集群配置信息
# server.A = B:C:D
# A 是一个数字,表示这个服务器的编号
# B 是这个服务器的ip地址
# C zookeeper服务器之间的通信端口
# D leader选举的端口
server.1=192.168.60.130:2287:3387
server.2=192.168.60.130:2288:3388
server.3=192.168.60.130:2289:3389
  1. In the directory specified by dataDir in the previous step, create a myid file, and then add the number corresponding to the sever configuration file in the previous step to the file
#zookeeper2181对应的数字为1
# /home/zookeeper/zookeeper2181/data目录下执行命令
echo "1" > myid
  1. zookeeper2182, zookeeper2183 refer to step 2/3 for corresponding configuration
  2. Start three servers separately and check the cluster status
    Login command
    ./zkCli.sh -server 192.168.60.130:2181
    ./zkCli.sh -server 192.168.60.130:2182
    ./zkCli.sh -server 192.168.60.130:2183
    

Conformance agreement: ZAB agreement

The full name of the ZAB protocol is Zookeeper Atomic Broadcast (zookeeper atomic broadcast) zookeeper uses the zab protocol to ensure the final consistency of distributed transactions.
Based on the zab protocol, the roles in the zookeeper cluster are mainly the following three categories

Roles description
leader The leader is responsible for the initiation and resolution of voting, and updates the system status
Follow (Follower) Follower is used to receive client requests and return results to the client, and participate in voting during the election process
Observer Observer can receive client connections and forward write requests to the leader node, but the observer does not participate in the voting process and only synchronizes the state of the leader. The purpose of the observer is to expand the system and improve the reading speed.
Client Request sender

The working principle of the zab broadcast mode is to solve the consistency of data through a similar two-phase submission protocol;
Insert picture description here

  1. The leader accepts a write request from the client
  2. The leader generates a new transaction and does not generate a unique zxid for the transaction
  3. The leader sends this transaction proposal (propose) to all followers nodes
  4. The follower node adds the received transaction request to the history queue and sends an ack to the leader;
  5. When the leader receives the ack message from most followers (more than half of the nodes), the leader sends a commmit request
  6. When the follower receives the commit request, the transaction request is committed from the history queue;

Guess you like

Origin blog.csdn.net/qq_43079376/article/details/108698800