“This is the 22nd day of my participation in the First Challenge 2022. For details: First Challenge 2022.”
Source view Zookeeper
Start ZooKeeper from the source code
Zookeeper 下载地址 :
/ / select branch 3.5.8 https://github.com/apache/zookeeper.gitCopy the code
package org.apache.zookeeper.version;
public interface Info {
int MAJOR = 1;
int MINOR = 0;
int MICRO = 0;
String QUALIFIER = null;
int REVISION = -1;
String REVISION_HASH = "1";
String BUILD_DATE = "2020-10-15";
}
Copy the codeThen compile and execute at root:
mvn clean install -DskipTests
Copy the codeOpen source projects usually find entry classes from the startup script, you can find the boot main class from the bin directory zkserver. sh or zkserver. CMD to run
org.apache.zookeeper.server.quorum.QuorumPeerMain
Copy the codeConf file zoo_sample. CFG, rename it zoo. CFG, and configure the zoo. CFG file location in the startup parameters
Bin/zkCli. Sh - server 192.168.50.190:2181Copy the codeRun the client from the source (org. Apache. The zookeeper. ZooKeeperMain), pay attention to the need to join the launch parameters, see below:
Start the ZooKeeper cluster from the source code
Copy 3 zoo. CFG files, modify the corresponding cluster configuration, create their own myID files in the data directory, fill in the machine ID, and create three startup nodes with different configurations, as shown below:
Start or Leader failure Elects the leader process
The leader elects a multi-level queue architecture
The whole Bottom layer of ZooKeeper election can be divided into election application layer and message transmission layer. The application layer has its own queue to receive and send votes uniformly, and the transmission layer also designs its own queue. However, the queue is divided according to the sending machine to avoid mutual influence when sending messages to each machine. For example, if a machine fails to send messages, messages to normal machines will not be affected.
Leader election source code flow chart
This section describes ZAB protocol
The whole Zookeeper is the implementation of a multi-node distributed consistency algorithm, and the underlying implementation protocol is ZAB. ZAB full name: Zookeeper Atomic Broadcast. Zookeeper is an efficient and reliable distributed coordination service for distributed applications. Zookeeper does not use Paxos to solve distributed consistency, but ZAB protocol, ZAB is a simplified implementation of Paxos algorithm. ZAB protocol definition: The ZAB protocol is designed for the distributed coordination service Zookeeper to support crash recovery and atomic broadcast. We’re going to focus on those two things. Based on this protocol, Zookeeper implements a system architecture in active/standby mode to ensure data consistency among replicas in the cluster. The details are shown in the figure below:
News broadcast
The message broadcast process of THE ZAB protocol uses an atomic broadcast protocol, similar to a two-phase commit process. All write requests sent by the client are received by the Leader, who encapsulates the request into a transaction Proposal and sends it to all Follwers. Then, according to the feedback of all Follwers, if more than half (including the Leader himself) respond successfully, The commit operation is performed. The whole broadcast process is as follows:
Crash recovery
What if the Leader crashes during message broadcast? Is there any guarantee that the data are consistent? In fact, when the Leader crashes, it enters what we described at the beginning as crash recovery mode (crash: the Leader loses contact with half of the Follwer). Let’s go into more details. Hypothesis 1: After the Leader copies data to all follwers, the Follower crashes before receiving an ACK from the Follower. What should I do? Hypothesis 2: What if the Leader crashes after receiving an ACK and committing himself and sending part of the COMMIT? To address these issues, ZAB defines two principles: The ZAB protocol ensures that transactions that are only proposed/replicated by the Leader, but not committed, are discarded. The ZAB protocol ensures that transactions that have been committed at the Leader are eventually committed by all servers. Therefore, ZAB designs the following election algorithm to ensure that transactions that have been committed by the Leader are committed, while discarding those that have been skipped. Aiming at this requirement, if the Leader election algorithm can ensure that the newly elected Leader server has the transaction with the largest ZXID of all machines in the cluster, then it can guarantee that the newly elected Leader must have all the submitted proposals. This has the advantage of saving the Leader server the step of checking the commit and discard of the transaction.
Data synchronization
After the crash is recovered, the Leader server first confirms whether the transactions have been committed by half of Follwer, i.e. whether data synchronization has been completed, before the official work (receiving client requests) is performed. The goal is to keep the data consistent. When Follwer servers are successfully synchronized, the Leader adds them to the list of available servers. In fact, the Leader server processes or discards transactions depending on the ZXID. How can the ZXID be generated? A: In ZAB protocol transaction number ZXID design, ZXID is a 64-bit number, where the lower 32 bits can be regarded as a simple incrementing counter for each transaction request from the client. Each Leader produces a new transaction Proposal and performs + 1 on the counter. The higher 32 bits represent the ZXID of the largest transaction Proposal in the local log from the Leader server, and the corresponding epoch value (Leader election cycle) is resolved from the ZXID. When a new election is over, this value will be increased by one. And the transaction ID increments from 0.
