在之前的【Zookeeper系列】基本介绍里有提到 ZK 的角色，那篇文章只是简单介绍 Leader、Follower 和 Observer 这三种角色。那么在一个 ZK 集群中，我怎么知道 ZK 服务是哪一个角色呢？角色是怎么分配的？为什么某个 ZK 是 Follower，而不是 Leader ？结论先行，先简单回答上面的问题。
-
我怎么知道 ZK 服务是哪一个角色呢？ 可以在 ZK 安装包的
bin路径下执行：zkServer.sh status，可以很清楚的看到打印出来Mode对应的角色，有可能是 leader，follower 或 observer。 -
角色是怎么分配的？为什么某个 ZK 是 Follower，而不是 Leader ？ 通过 ZK 内部的选举机制，其细节可继续往下看这篇文章...
[ps.为了降低复杂度，本篇文章并不会深入聊zab协议]
前置内容：
ZXID：当发生写请求的时候，在 ZK 内会发起一个事务，每个事务会分配一个 zxid作为标识符。zxid 是64位的 long 类型，高32位代表时间戳，低32位可以认为是事务ID，用来标识服务器状态的变更次数
SID：服务器ID。用来标识一台在 ZooKeeper 集群中的机器，每台机器不能重复。注意：这里和启动时指定的myid一致
Epoch：每个 Leader 任期的代号。每次新选举一个 Leader 就会递增1
Observer：不参与投票和选举【换句话说，不参与 Leader 的选举，也不会投票给某个节点】
节点状态：
-
LEADING：Leader节点的状态
-
LOOKING：参与选举的状态
-
FOLLOWING：Follower节点的状态
-
OBSERVING：Observer节点的状态
好了，前置知识大概这么多，接下来咱们看一下，上面这些东西和选举有什么关系。
选举目的是为了从一堆 ZK 的服务节点中找一个大佬（Leader），然后所有非 Observer 节点都会成为小弟（Follower）。Leader负责读写数据，而 Follower 会分担大佬的负担，分担部分的读请求。
那么问题来了，根据什么条件判断，认为某一台 ZK 服务能成为 Leader 呢？
实际上，选举的规则是按照 Epoch > 事务Id > SID 依次由大到小排序，值最大作为 Leader。
简单来说，选举的时候会比较epoch的大小，如果所有 ZK 节点的 Leader 任期大小一样，则继续比较 ZXID 的低32位，也就是事务Id大小，如果事务ID大小都一样的话，就会比较服务器ID（SID）
ps. 由于我是基于 Docker 部署 ZK 集群，进入其中的ZK节点，执行 cat /data/version-2/currentEpoch既可以看到epoch的大小
root@zoo3:/# cat /data/version-2/currentEpoch
5
ZK 集群选举
接下来，看下 ZK 集群是怎样选举 Leader 的，但值得注意的是，选举区分了第一次启动和非第一次启动。第一次选举流程比较简单，但非第一次选举的时候，会涉及到 Leader 宕机或假死的情况，这样的话细节就会多一些。
背景：ZK集群是由5台ZK节点组成，只要集群中过半的节点投票就可选出 Leader
第一次启动
在集群节点启动之初，所有的epoch都是一样的，此时 Leader 还没选举出来，此时不会有写请求进来，所以事务Id也是没有的，所以最终的判断条件是根据SID，也就是节点的ZOO_MY_ID决定，理论上来说，ZOO_MY_ID 值最大的就会成为Leader，但为什么说是理论上呢？咱们来看下实际的效果。
场景1:
基于docker-compose一次性部署5台ZK节点，参考我另外一篇博客【Zookeeper系列】基于docker-compose快速搭建Zookeeper集群
最终结果是例子中的zoo5成为Leader，符合上面 ZOO_MY_ID 值最大的就会成为 Leader 的说法。
场景2:
先把5台节点都关掉【执行docker-compose stop，模拟集群的节点准备启动的状态】，然后依次执行
docker start zoo1
docker start zoo2
docker start zoo3
集群中有5台节点，先启动3台，符合过半投票的情况，这时候已经可以选举出 Leader，盲猜一下，应该是 zoo3 这台机器成为Leader 了吧？进入 zoo3 容器，执行 zkServer.sh status 查看节点角色。果然，此时的 zoo3 是 Leader
此时，再依次执行 docker start zoo4 和 docker start zoo5，可以发现，Leader依旧是 zoo3。这是因为，当成功选举出 Leader 后，后续启动的 zk 节点都会成为 Follower（现在先不讨论Observer的情况）。
但这种结果并不与选举规则冲突，当 zk 集群内的机器不是同一时刻启动的时候，其大致选举流程是：
-
先启动 zoo1 ，zoo1会先给自己投票，但由于票数没有过半，所以 zoo1 此时是 LOOKING 状态；
-
接着启动 zoo2，zoo2一开始也会给自己投票，然后与 zoo1 交换投票信息。zoo1会发现当前的 epoch 和 zxid 都与 zoo2一样，但 zoo2 的 Sid 比自己大，zoo1 就会改票，将自己的那一票给了 zoo2，此时 zoo2 虽然有 zoo1 的投票支持，但投票票数还是没超过一半，不能成为Leader，zoo2 也保持 LOOKING 状态；
-
再启动 zoo3，同样的 zoo3 也会先给自己投票后，再和 zoo1、zoo2 交换投票信息。zoo1 和 zoo2 都发现与 zoo3 的 epoch 和 zxid 一样大小，但 zoo3 的 Sid 比自己高，所以 zoo1 和 zoo2 都改票投给了 zoo3，此时 zoo3 有了3张票（包括自己自投），超过半数，所以 zoo3 就成为了 LEADING 状态，zoo1 和 zoo2 成为了 FOLLOWING 状态。
-
接着启动 zoo4 和 zoo5，此时 zoo1、zoo2 和 zoo3 节点都不是 LOOKING 状态，不会交换投票的信息，发现 zoo3 是 LEADING 状态，所以 zoo4 和 zoo5 都投票给 zoo3，并更改自己的状态为 FOLLOWING 状态
但为什么在场景1的时候，不是 zoo3 成为 Leader 而是 zoo5 成为 Leader 呢？这是因为在近乎同一时刻，zk 集群所有的服务都启动了，此时所有节点都是先投票给自己，然后再与其他节点交换信息，发现 zoo5 的 Sid 最大，接着所有的节点都投票给了 zoo5 ，其余节点就都处于 FOLLOWING 状态，而 zoo5 是 LEADING 状态。
非第一次启动
场景1：
假设 zoo3 是 Leader，其余都是 Follower。当 zoo3 宕机，其余节点都变为 FOLLOWING 状态，重新参与选举。
为降低复杂度，将真实的 zxid 简化为只有事务Id。假设 zoo1、zoo2、zoo4、zoo5 的 (epoch,zxid,sid) 分别是 (1,13,1)，(1,10,2)，(1,13,4)，(1,12,5)
此时选举流程是怎样呢？
-
首先存活节点发现大佬没了，就会将自己的状态更改为 LOOKING 状态，此时所有节点都会给自己投票，然后与其他节点交换投票信息；此时发现大家的epoch一样，则比较彼此的 zxid
-
很明显，zxid 最大的是 zoo1 和 zoo4，再继续比较彼此的 sid
-
此时可以轻易得出，zoo4 的 sid 最大，就会将 zoo4 的状态更改为 LEADING。其余节点投票给 zoo4，并更改状态为 FOLLOWING
场景2：
zoo3 为 LEADING 状态，此时 zoo3 假死。如果 zoo3 忽然网络出问题，断开与其他 follower 节点的连接。其他节点以为 zoo3 宕机，则重新选举新 Leader，假设此时 zoo1 成为大佬，此时 zoo3 忽然正常了，那么剩下的 follower 节点会不会蒙圈？怎么会有两个大佬，正所谓一山不能容二虎，我应该听谁？
实际上，zk 有考虑到这种情况，还记得上面说的 epoch 的定义吗？这是每个 Leader 的代号，每更新一次 Leader，epoch 就会递增1。假如 zoo3 假死前，所有的节点的 epoch 都是2。zoo3 假死，zoo3 的 epoch 不会变，因为没想到有其他节点想替代自己的位置嘛。但其他节点选举 zoo1 为 Leader 后，除了 zoo3 ，其他的节点的 epoch 都是3了。此时 zoo3 恢复正常，即使向其他节点同步事务消息，但其余节点发现 zoo3 的 epoch 和自己不一样，就不会认这个大佬，而是认准 zoo1 才是自己的老大。
总结
实际上，zk 集群的选举并不简单，底层选举算法使用到的 ZAB 协议保证分布式消息一致性，本篇文章并没过多描述。对于初学者来说，了解其选举的规则和某些场景下是如何选举，大概了解流程足矣。当实际开发中，为了保证高可用，需要注意的是 ZK 集群节点为奇数。另外，感兴趣的读者可以再去关注 ZAB 协议的细节。
参考资料：
《从Paxos到Zookeeper分布式一致性原理与实践》
如果觉得文章不错的话，麻烦点个赞哈，你的鼓励就是我的动力！对于文章有哪里不清楚或者有误的地方，欢迎在评论区留言~
网友评论