Leader选举是保证分布式数据一致性的关键。
当Zookeeper集群中的一台服务器出现服务器初始化启动，或者服务器运行期间无法和Leader保持连接时，需要进入Leader选举。
注: 服务器角色
- Leader 事务请求的唯一调度和处理者，保证集群事务处理的顺序性。集群内部各服务的调度者。
- Follower 处理客户端的非事务请求，转发事务请求给Leader服务器，参与事务请求Proposal的投票，
参与Leader选举投票。 - Observer，3.3.0版本以后引入的一个服务器角色，在不影响集群事务处理能力的基础上提升集群的非事务处理能力。处理客户端的非事务请求，转发事务请求给Leader服务器。不参与任何形式的投票。
1.服务器启动时期的Leader选举
The leader is a server that has been chosen by an ensemble of servers and that continues to have support from that ensemble. The purpose of the leader is to order client requests that change the ZooKeeper state: create, setData, and delete. The leader transforms each request into a transaction, and proposes to the followers that the ensemble accepts and applies them in the order issued by the leader.
领导者（leader）是由一组服务器竞选出来的服务器，并且一直得到该组服务器的支持。领导者（leader）的主要工作是实施更改 ZooKeeper 状态的客户端请求：包括创建、设置和删除数据。leader将每个请求转换为事务（transaction），并propose给它的追随者（followers），追随者（followers）将接受并按领导者（leader）发出的顺序执行这些请求。
When a process starts, it enters the ELECTION state. While in this state the process tries to elect a new leader or become a leader. If the process finds an elected leader, it moves to the FOLLOWING state and begins to follow the leader. Processes in the FOLLOWING state are followers. If the process is elected leader, it moves to the LEADING state and becomes the leader. Given that a process that leads also follows, states LEADING and FOLLOWING are not exclusive. A follower transitions to ELECTION if it detects that the leader has failed or relinquished leadership, while a leader transitions to ELECTION once it observes that it no longer has a quorum of followers supporting its leadership.
当进程启动时，它将进入"选举"（ELECTION）状态，试图选举新的领导者（leader）或成为领导者（leader）。如果流程找到已经当选的领先者（leader），它将更新到"跟随"（FOLLOWING）状态并开始跟随该领导者（leader）。 处于"跟随"（ FOLLOWING）状态的进程是追随者（followers）。如果进程是当选了领导者（leader），它将更新到"领导"（ LEADING ）状态，并成为领导者（leader）。鉴于一个领导者（leader）进程也跟随自己发出的更改指令，所以"领导"（ LEADING ）状态和"跟随"（ FOLLOWING）状态并不是互斥的。跟随者如果发现领导者失败或已经放弃了领导，则过渡到"选举"（ELECTION ）状态，而领导者（leader）在发现其不再有支持其领导层的法定（quorum）追随者（followers）的人数后，将过渡到"选举"（ELECTION ）状态。
经典的示例
举一个经典的示例，可以帮助我们建立起直觉上的理解（intuitive understanding）
假设五台ZooKeeper服务器，分别为zk1,zk2,zk3,zk4,zk5，sid分别为1、2、3、4、5，依次启动zk1, zk2, zk3, zk4, zk5。问哪台是leader?
当前的情景是由zk1,zk2,zk3,zk4,zk5组成的全新的“ensemble”进行选举，ZooKeeper选举所采用的具体算法是Paxos算法。 假设5台服务器都做了正确设置，数据 ID 和逻辑时钟都一致，那么可以比较的权重只有服务器 ID。zk1,zk2,zk3,zk4,zk5的服务器 ID分别为1、2、3、4、5。当以zk1,zk2,zk3,zk4,zk5的顺序依次启动时，具体选举过程如下：
- 服务器 zk1 启动，给自己投票，然后发投票信息，此时服务器 zk1 的状态将进入 LOOKING。
- 服务器 zk2 启动，给自己投票，同时与之前启动的服务器 zk1 交换结果，由 于服务器 zk2 的服务器 ID大所以服务器 zk2 胜出，zk1的投票改为 zk2，但此时相同的票数仍不够组成最小的”Quorum“， 所以两个服务器的状态都进入LOOKING。
- 服务器 zk3 启动，给自己投票，同时与之前启动的服务器 zk1, zk2 交换信息， 由于服务器 zk3的编号最大所以服务器 zk3胜出，zk1，zk2的投票均改为 zk3。此时投票数正好等于”Quorum“， 所以在zk1,zk2,zk3确认connect后，服务器 zk3 状态更新为leader，服务器 zk1, zk2 状态更新为follower。
- 服务器 zk4启动，给自己投票，同时与之前启动的服务器 zk1, zk2, zk3交换信息， 尽管服务器 zk4 的编号大，但此时服务器zk1，zk2，zk3已经不是LOOKING状态，不会更改选票信息。交换选票信息结果：服务器zk3为3票，服务器zk4为1票。此时服务器zk4服从多数，更改选票信息为服务器zk3，在和leader connect后，退出LOOKING状态，更新为follower。
- 服务器 zk5 启动，后面的逻辑和（4）类似，成为follower。
注：Paxos算法
Paxos由Lamport于1998年在《The Part-Time Parliament》论文中首次公开，最初的描述使用希腊的一个小岛Paxos作为比喻，描述了Paxos小岛中通过决议的流程，并以此命名这个算法，但是这个描述理解起来比较有挑战性。后来在2001年，Lamport觉得同行不能理解他的幽默感，于是重新发表了朴实的算法描述版本《Paxos Made Simple》。
自Paxos问世以来就持续垄断了分布式一致性算法，Paxos这个名词几乎等同于分布式一致性。Google的很多大型分布式系统都采用了Paxos算法来解决分布式一致性问题，如Chubby、Megastore以及Spanner等。开源的ZooKeeper，以及MySQL 5.7推出的用来取代传统的主从复制的MySQL Group Replication等纷纷采用Paxos算法解决分布式一致性问题。
2. 服务器运行时期的Leader选举
Each server enters into the LOOKING state, where it must either elect a new leader or find the existing one. If a leader already exists, other servers inform the new one which server is the leader. At this point, the new server connects to the leader and makes sure that its own state is consistent with the state of the leader. If an ensemble of servers, however, are all in the LOOKING state, they must communicate to elect a leader. They exchange messages to converge on a common choice for the leader. The server that wins this election enters the LEADING state, while the other servers in the ensemble enter the FOLLOWING state. The leader election messages are called leader election notifications, or simply notifications.
The protocol is extremely simple. When a server enters the LOOKING state, it sends a batch of notification messages, one to each of the other servers in the ensemble. The message contains its current vote, which consists of the server’s identifier (sid) and the zxid (zxid) of the most recent transaction it executed.
每个服务器将进入"查看"状态，它必须选择新的领导者或查找现有领导者。如果领导者已存在，则其他服务器会通知新服务器哪个服务器是领导者。此时，新服务器连接到引线，并确保其自己的状态与引线的状态一致。但是，如果一组服务器都处于"查找"状态，则必须进行通信以选出一位领导者。他们交换信息，以汇聚领导者的共同选择。赢得此选举的服务器进入"领先"状态，而集合中的其他服务器进入"选择"状态。领导人选举消息称为领导人选举通知，或简称通知。
该协议非常简单。当服务器进入"看"状态时，它会发送一批通知消息，其中一条发送到集合中的其他服务器。该消息包含其当前投票，其中包括服务器的标识符 （sid） 及其执行的最新事务的 zxid （zxid）。
Upon receiving a vote, a server changes its vote according to the following rules:
- Let voteId and voteZxid be the identifier and the zxid in the current vote of the receiver, whereas myZxid and mySid are the values of the receiver itself.
- If (voteZxid > myZxid) or (voteZxid = myZxid and voteId > mySid), keep the current vote.
- Otherwise, change my vote by assigning myZxid to voteZxid and mySid to vote Zxid.
In short, the server that is most up to date wins, because it has the most recent zxid. This simplifies the process of restarting a quorum when a leader dies. If multiple servers have the most recent zxid, the one with the highest sid wins. Once a server receives the same vote from a quorum of servers, the server declares the leader elected. If the elected leader is the server itself, it starts executing the leader role. Otherwise, it becomes a follower and tries to connect to the elected leader.
收到表决后，服务器会根据以下规则更改其投票：
- 让投票Id和投票Zxid是接收方当前投票的标识符和zxid，而myZxid和mySid是接收者本身的值。
- 如果（投票Zxid myZxid）或（投票Zxid + myZxid和投票IdmySid），保持当前投票。
-否则，通过分配我的Zxid投票Zxid和mySid来投票给Zxid来改变我的选票。
简而言之，最新的服务器获胜，因为它具有最新的 zxid。这简化了当领导者死亡时重新启动仲裁的过程。如果多个服务器具有最新的 zxid，则 sid 最高的服务器将获胜。一旦服务器从服务器法定人数获得相同的投票，服务器将宣布当选领导。如果当选的引线是服务器本身，它将开始执行领导角色。否则，它将成为追随者，并尝试连接到当选的领导人。
附录：源码URL
源码URL FastLeaderElection.java