Zookeeper leader election

Leader elections are key to ensuring distributed data consistency. T he Leader election is divided into zookeyer cluster initialization start-up election and Zookeeper cluster re-election during zookeeper cluster run. Learn about the zookeyer node's 4 possible state and transaction ID concepts before explaining the Leader election.

1, Zookeeper node status

• LOOKING: Look for the Leader state, where you need to go into the election process
• LEAD: Leader state, where the node indicates that the role is already Leader
• FOLLOWING: Follower status, indicating that leader has been elected and that the current node role is follower
• OBSERVER: Observer status, indicating that the current node role is observer

2, transaction ID

Each change in zooKeeper status receives a ZXID (ZooKeeper transaction id) tag. Z XID is a 64-bit number that is uniformly assigned by Leader, globally unique, and constantly increasing. Z XID shows the sequence of changes for all ZooKeeper. Each change has a unique zxid, if zxid1 is less than zxid2, which indicates that zxid1 occurs before zxid2.

3, Zookeyer cluster initialization start-up leader election

If you are running a Leader election, you need at least two machines, and here you select a cluster of servers consisting of three machines. T he Leader election process during initialization startup is shown in the figure below.

During the cluster initialization phase, when one server, ZK1, starts, it cannot perform and complete the Leader election alone, and when the second server, ZK2, starts, the two machines can communicate with each other, each trying to find the Leader, and then enters the Leader election process. T he electoral process begins as follows:

(1) One vote per server. B ecause this is the initial case, ZK1 and ZK2 will vote on themselves as leader servers, each poll will contain the myid and ZXID of the server being selected, using (myid, ZXID) to indicate that the ZK1 vote is (1, 0), ZK2 is (2, 0), and then each vote is sent to the other machines in the cluster.

(2) Accept votes from individual servers. A fter each server in the cluster receives the vote, first determine the validity of the vote, such as checking whether it is the current round of voting and whether it is from a server in the LOOK state.

(3) Processing of votes. F or each vote, the server needs to compare other people's votes with their own, as follows

• Prioritize ZXID. ZXID's larger servers take precedence over Leader.
• If ZXID is the same, compare myid. Myid's larger server serves as leader's server.

(4) Counting votes. A fter each vote, the server counts the voting information to determine whether more than half of the machines have received the same voting information, and for ZK1 and ZK2, two machines in the cluster have already received (2, 0) voting information, and ZK2 is considered to have been selected as Leader.

(5) Change the state of the server. O nce Leader is identified, each server updates its status, and if it is Flower, changes to FOLLOWING, and if it is Leader, to LEADER. When the new Zookeeper node ZK3 starts, it is found that there is already a Leader, no more elections, and the direct status is changed directly from LOOKING to FOLLOWING.

4. Leader re-selected during zookeeper cluster operation

During Zookeeper operation, if the Leader node is suspended, the entire Zookeyer cluster will suspend external services for a new leader election. S uppose you have three servers running, ZK1, ZK2, and ZK3, and the current Leader is ZK2, and if at some point Leader hangs up, the Leader election begins. The electoral process is shown in the figure below.

(1) Change of status. W hen Leader hangs up, the remaining non-Observer servers say their server status changes to LOOK and then begins the Leader election process.

(2) Each server will send out a vote. Z XID may be different on each server during operation, assuming ZXID of ZK1 of 124 and ZXID of ZK3 of 123, and in the first round of voting, ZK1 and ZK3 will vote for themselves (1,124), (3, 123), and then send the vote to all machines in the cluster.

(3) Receive votes from various servers. S ame process as at startup.

(4) Processing of votes. A s with the startup process, ZK1 will become leader due to the large ZK1 transaction ID.

(5) Counting votes. S ame process as at startup.

(6) Change the state of the server. Same process as at startup.