ZooKeeper 技术内幕|Leader 选举是一个什么样的过程

news2024/10/7 4:31:14

几个问题，引发思考：

什么时候 leader 选举？
选举的过程？
选举过程中，是否能提供服务？
选举结果，是否会丢失数据？

服务器角色

2 个小问题：

服务器节点有多少角色？
每个角色的作用？

角色

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 不参与投票：只用于提供非事务请求的处理

疑问：节点成为 Follower 还是 Observer 是配置文件中设定的？

Leader 选举

2 个小问题：

什么时候，进行 Leader 选举？
Leader 选举的具体过程，是什么？

时机

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

启动时，集群服务器刚启动
运行时，Leader 崩溃

服务器的状态流转：

过程

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

各个服务器节点，广播自己的优先级标识 (sid，zxid)
服务器节点收到其他广播消息后，跟自己的优先级对比，自己优先级低，则变更当前节点投票的优先级(sid，zxid) ，并广播变更后的结果
当任意一个服务器节点收到的投票数，超过了法定数量(quorum)，则，升级为 Leader，并广播结果。

疑问：法定数量（quorum），一般设置为集群规模大小的半数以上，quorum 在哪配置的？

特别说明：

服务器节点的优先级标识：(sid，zxid)
优先比较 zxid （事务 ID），其次比较sid（服务器ID）
sid (服务器 ID) 是节点配置文件中设定的
当前服务器上的 zxid 是什么时候设定的？是在 Leader 执行事务过程中，向当前服务器同步的？如何活的当前服务器上的 zxid？

具体选举过程：

补充说明：

由于网络延时，节点得不到足够多广播信息时，会做出错误的投票判断，纠正过程更耗时
选举过程中，服务器节点会等待一定时间，再广播投票信息，时间间隔一般设定为 200 ms
上面 Leader 选举，采取事件触发 Push 方式 广播消息，称为 快速 Leader 选举，因为之前的 Leader 选举，采用 Pull 方式，每隔 1s 拉取一次。

疑问：

服务器节点，等待 200ms 的起始时间点是什么？是收到一轮新投票消息，开始计时？

RE：

正常情况下，投票信息是事件触发，广播出去的；

当某个服务器节点，判断支持当前节点的投票数量 >= 法定数量（quorum），则，仍然等待 200ms，确认是否有更优的投票。

真正的投票信息：

属性	说明
id	被推举 Leader 的 sid
zxid	被推举 Leader 的事务ID
electionEpoch	投票的轮数，约束：同一轮投票，计数有效
peerEpoch	被推举 Leader 的 epoch
state	当前服务器的状态

一次 Leader 选举过程，属于同一个 electionEpoch，结束时，会选出新的 Leader；服务器节点，在比较 (sid，zxid) 之前，会先比较选举轮次 electionEpoch，只有同一轮次的 Leader 投票信息才是有效的：