Zookeeper技术内幕——深入探究Leader选举过程

概要

什么时候 leader 选举

选举的过程

脑裂

ZK 集群中，服务器节点，有 3 中角色：

Leader：ZK 集群工作机制的核心：

调度者：集群内部各个服务节点的调度者

事务请求：事务请求的唯一调度和处理者，保证集群事务处理的顺序性

Follower：

非事务请求：Follower 直接处理非事务请求，对于事务请求，转发给 Leader

Proposal 投票：Leader 上执行事务时，需要 Follower 投票，Leader 才真正执行

Leader 选举投票

Observer：ZK 3.3.0+ 版本开始引入，提升 ZK 集群的非事务处理能力

非事务请求：Follower 直接处理非事务请求，对于事务请求，转发给 Leader

Observer 跟 Follower 的区别：

Follower 参与投票：Leader 选举、Proposal 提议投票（事务执行确认）

Observer 不参与投票：只用于提供非事务请求的处理

Leader 选举时机

下面任何一种情况，都会触发 Leader 选举：

启动时，集群服务器刚启动

运行时，Leader 崩溃

服务器的状态流转：

过程

Leader 选举过程，本质就是广播优先级消息的过程，选出数据最新的服务节点，选出优先级最高的服务节点，基本步骤：

各个服务器节点，广播自己的优先级标识 (sid，zxid)

服务器节点收到其他广播消息后，跟自己的优先级对比，自己优先级低，则变更当前节点投票的优先级(sid，zxid) ，并广播变更后的结果

当任意一个服务器节点收到的投票数，超过了法定数量(quorum)，则，升级为 Leader，并广播结果。

关于sid和zxid的详解：

服务器节点的优先级标识：(sid，zxid)

优先比较 zxid （事务 ID），其次比较sid（服务器ID）

sid (服务器 ID) 是节点配置文件中设定的

当前服务器上的 zxid 是什么时候设定的？是在 Leader 执行事务过程中，向当前服务器同步的？如何活的当前服务器上的 zxid？

如何应对网络延迟：

由于网络延时，节点得不到足够多广播信息时，会做出错误的投票判断，纠正过程更耗时

选举过程中，服务器节点会等待一定时间，再广播投票信息，时间间隔一般设定为 200 ms

上面 Leader 选举，采取事件触发 Push 方式 广播消息，称为 快速 Leader 选举，因为之前的 Leader 选举，采用 Pull 方式，每隔 1s 拉取一次。

分布式系统 Leader 选举：脑裂

脑裂（split brain）：服务器集群的 2 个子集，能够同时独立选举 Leader，并正常运行，形成 2 个集群。

解决办法：

Leader 选举的法定数量（quorum），超过正常集群的半数。

Leader 选举的必要条件：节点数量 > 法定数量。