ZooKeeper 的集群选主、数据同步

(一)ZooKeeper 的全新集群选主
以一个简单的例子来说明整个选举的过程:假设有五台服务器组成的 zookeeper 集群,它们的 serverid 从 1-5,同时它们都是最新启动的,也就是没有历史数据,在存放数据量这一点上,都是一样的。假设这些服务器依序启动,来看看会发生什么
1、服务器 1 启动,此时只有它一台服务器启动了,它发出去的报没有任何响应,所以它的选举状态一直是 LOOKING 状态
2、服务器 2 启动,它与最开始启动的服务器 1 进行通信,互相交换自己的选举结果,由于两者都没有历史数据,所以 id 值较大的服务器 2 胜出,但是由于没有达到超过半数以上的服务器都同意选举它(这个例子中的半数以上是 3),所以服务器 1、2 还是继续保持 LOOKING状态
3、服务器 3 启动,根据前面的理论分析,服务器 3 成为服务器 1,2,3 中的老大,而与上面不同的是,此时有三台服务器(超过半数)选举了它,所以它成为了这次选举的leader
4、服务器 4 启动,根据前面的分析,理论上服务器 4 应该是服务器 1,2,3,4 中最大的,但是由于前面已经有半数以上的服务器选举了服务器 3,所以它只能接收当小弟的命了
5、服务器 5 启动,同 4 一样,当小弟

总结:zookeeper server 的三种工作状态
LOOKING:当前 Server 不知道 leader 是谁,正在搜寻,正在选举
LEADING:当前 Server 即为选举出来的 leader,负责协调事务
FOLLOWING:leader 已经选举出来,当前 Server 与之同步,服从 leader 的命令

(二)ZooKeeper 的非全新集群选主
那么,初始化的时候,是按照上述的说明进行选举的,但是当 zookeeper 运行了一段时间之后,有机器 down 掉,重新选举时,选举过程就相对复杂了。
需要加入数据 version、serverid 和逻辑时钟。

数据 version:数据新的 version 就大,数据每次更新都会更新 version
server id:就是我们配置的 myid 中的值,每个机器一个
逻辑时钟:这个值从 0 开始递增,每次选举对应一个值,也就是说:如果在同一次选举中,那么这个值应该是一致的;逻辑时钟值越大,说明这一次选举 leader 的进程更新,也就是每次选举拥有一个 zxid,投票结果只取 zxid 最新的

选举的标准就变成:
1、逻辑时钟小的选举结果被忽略,重新投票
2、统一逻辑时钟后,数据 version 大的胜出
3、数据 version 相同的情况下,server id 大的胜出
根据这个规则选出 leader。

(三)数据同步
选完 leader 以后,zk 就进入状态同步过程。
1、leader 等待 server 连接;
2、follower 连接 leader,将最大的 zxid 发送给 leader;
3、leader 根据 follower 的 zxid 确定同步点;
4、完成同步后通知 follower 已经成为 uptodate 状态;
5、follower 收到 uptodate 消息后,又可以重新接受 client 的请求进行服务了。
以下是流程图:
在这里插入图片描述

猜你喜欢

转载自blog.csdn.net/lv_hulk/article/details/88571058