ZooKeeper 集群中的三个服务器角色:Leader
、Follower
和 Observer
。其中,Leader 选举是 ZooKeeper 中最重要的技术之一,也是保证分布式数据一致性的关键所在。
而paxos算法中的角色为Proposer
, Acceptor
, Learning
raft算法中的角色为Leader
, Follower
, Candidate
文章目录
1.Leader 的选举机制
Zookeeper 在配置文件中并没有指定 Master
和 Slave
。但是,Zookeeper 工作时, 是有一个节点为 Leader
,其他则为 Follower
,而这个 Leader 是通过内部的选举机制临时产生的。
每个 Server 首先都提议自己是 Leader,并为自己投票,然后将投票结果与其他 Server 的选票进行对比,权重大的胜出,使用权重较大的选票更新自身的投票箱,我们介绍下服务器启动时期的 Leader 选举。
- 每一个 Server 都会发出一个投票
在集群初次启动时,每个 Server 都会推荐自己为 Leader,然后各自将这个投票发给集群中其他 Server。 - 接收来自各个 Server 的投票
每个 Server 在接收到其他 Server 的投票后,首先会判断该票的有效性,包括检查是否本轮投票,是否来自 Looking 状态的 Server。(Looking 状态表示当前集群正处于选举状态) - 处理投票
针对每一个投票,Server 都会将别人的投票和自己的投票进行 PK,计算出 Zxid 最大的 Server,并将该 Server 设置成下一次投票推荐的 Server。 - 统计投票
每次投票结束之后,都会统计所有投票,获取投票最多的 Server 将成为获胜者,如果获胜者的票数超过集群个数的一半,则该 Server 将为推选为 Leader。否则继续投票,直至 Leader 被选举出来。 - 改变服务器状态
一旦 Leader 确定后,Leader 会通知其他 Follower 集群已经成为 Uptodate 状态,Follower 在收到 Uptodate 消息后,接收 Client 的请求并开始对外提供服务。
2.选举 Leader 的具体实例
上述的选举过程比较抽象,我们以一个有5个节点的集群为例,目前均为 shutdown 状态。
- Server 1 启动
Server 1 启动后会提议自己为 Leader 并为自己投票,然后将投票结果发送给其他 Server,由于其他 Server 还未启动,因此收不到任何反馈信息,此时 Server 1 会处于 Looking 状态。
- Server 2 启动
Server 2 启动后会提议自己为 Leader 并为自己投票,然后与 Server 1 交换投票结果,由于 Server 2 的编号大于 Server 1,因此 Server 2 胜出。但是,由于投票数未过集群数的一半,两个 Server 仍然均处于 Looking 状态。 - Server 3 启动
Server 3 启动后会提议自己为 Leader 并为自己投票,然后与 Server 2、Server 3 交换投票结果,由于 Server 3 的编号最大,因此 Server 3 胜出。此时, Server 3 的票数大于集群数的一半了,因此 Server 3 会更新为 Leader ,Server 1、Server 2 更新为 Follower。 - Server 4 启动
Server 4 启动后会提议自己为 Leader 并为自己投票,然后与 Server 1、Server 2、Server 3 交换投票结果,发现 Server 3 已经成为了 Leader,因此 Server 4 也成为了 Follower。 - Server 5 启动
与 Server 4 一样,Server 5 启动后会给自己投票,然后与其他 Server 交换信息,发现 Server 3 已经成为了 Leader,因此 Server 5 也成为了 Follower。
3.投票 vote 的数据结构
- id:服务器ID,用来唯一标识 ZooKeeper 集群中的服务器;
- Zxid:事务ID,用来唯一标识一次服务器状态的变更;
- electionEpoch:代表当前服务器的选举轮次,是一个自增序列;
- peerEpoch:被推举的 Leader 的选举轮次;
- state:当前服务器的状态。