13.0 Zookeeper Leader Election Principles
Category Zookeeper Tutorial
Zookeeper's leader election has two phases: one is leader election during server startup, and the other is leader election during runtime when the leader server crashes. Before analyzing the election principles, let's introduce a few important parameters.
Server ID (myid): The larger the number, the greater the weight in the election algorithm.
Transaction ID (zxid): The larger the value, the newer the data, and the greater the weight.
Logical Clock (epoch-logicalclock): The logical clock value is the same during the same round of voting, and it increases after each vote.
Election States:
LOOKING: Campaigning state.
FOLLOWING: Follower state, synchronizes with the leader state, participates in voting.
OBSERVING: Observing state, synchronizes with the leader state, does not participate in voting.
LEADING: Leader state.
1. Leader Election During Server Startup
Each node starts in the LOOKING state, and then begins the main election process. Here, we take a cluster composed of three machines as an example. When the first server, server1, starts, it cannot conduct leader election. When the second server, server2, starts, the two machines can communicate with each other and enter the leader election process.
(1) Each server sends a vote. Since it's the initial situation, both server1 and server2 vote for themselves as the leader server. Each vote includes the recommended server's myid, zxid, and epoch, denoted as (myid, zxid). At this time, server1's vote is (1,0), and server2's vote is (2,0). Then, they send their votes to the other machines in the cluster.
(2) Receives votes from various servers. Each server in the cluster, upon receiving a vote, first checks the validity of the vote, such as whether it is for this round (epoch) and whether it comes from a server in the LOOKING state.
(3) Processes votes separately. For each vote, the server needs to compare the other server's vote with its own. The comparison rules are as follows:
a. Prioritize comparison of epoch.
b. Check zxid; the server with the larger zxid is prioritized as the leader.
c. If zxid is the same, then compare myid; the server with the larger myid becomes the leader server.
(4) Counts votes. After each vote, the server counts the vote information to determine if more than half of the machines have received the same vote information. Both server1 and server2 count that two machines in the cluster have accepted the vote (2,0), thus selecting server2 as the leader node.
(5) Changes server status. Once the leader is determined, each server updates its own status. If it's a follower, it changes to FOLLOWING; if it's the leader, it changes to LEADING. At this point, server3 continues to start and directly joins, changing itself to FOLLOWING.
2. Leader Election During Runtime
When the leader server in the cluster crashes or becomes unavailable, the entire cluster cannot provide external services and enters a new round of leader election.
(1) Changes status. After the leader crashes, other non-Observer servers change their status to LOOKING.
(2) Each server sends a vote. During runtime, the zxid on each server may be different.
(3) Processes votes. The rules are the same as during startup.
(4) Counts votes. The same as during startup.
(5) Changes server status. The same as during startup.
-2.0 Zookeeper Installation and Configuration
-3.0 Zookeeper Linux Server Cluster Setup Steps
-4.0 Zookeeper Java Client Setup
-5.0 ZooKeeper Data Model znode Structure Detailed
-6.0 Zookeeper Session Basic Principles
-7.0 Zookeeper Basic Client Commands Usage
-8.0 Zookeeper Four-Letter Commands
-10.0 Zookeeper Access Control ACL
-11.0 Zookeeper Watcher Event Mechanism Analysis
-12.0 Zookeeper Data Synchronization Process
- 13.0 Zookeeper Leader Election Principles
-14.0 Zookeeper Distributed Lock Implementation Principles