Zookeeper 选举机制

最新推荐文章于 2024-08-28 17:00:15 发布

TABE_

最新推荐文章于 2024-08-28 17:00:15 发布

阅读量269

点赞数

文章标签： zookeeper 选举机制

本文链接：https://blog.csdn.net/TABE_/article/details/120835021

版权

4 篇文章 0 订阅

订阅专栏

选举机制中的概念

1、Serverid：服务器ID
比如有三台服务器，编号分别是1,2,3。编号越大在选择算法中的权重越大。

2、Zxid：数据ID
服务器中存放的最大数据ID，值越大说明数据越新，在选举算法中数据越新权重越大。

3、Epoch：逻辑时钟
或者叫投票的次数，同一轮投票过程中的逻辑时钟值是相同的。每投完一次票这个数据就会增加，然后与接收到的其它服务器返回的投票信息中的数值相比，根据不同的值做出不同的判断。

4、Server状态：选举状态
zookeeper节点一共包含4种状态：

假如有以下5台机器server1、server2、server3、server4、server5。

在这里插入图片描述

每个server 自身都有一票，在初始化或者server崩溃数过半的时候，每个server都有一个自身的myid(zookeeper配置文件)，这里myid由1、2、3、4、5表示。

在选举过程中主要是依据zxid和myid来进行轮询server然后比较统计投票。

选举分为两种情况，初始化和leader挂掉的时候，要进行leader选举，至少需要3台机器。为了方便选举，集群机器台数基本是奇数。

因为一共5台服务器，只有超过半数以上，即最少启动3台服务器，集群才能正常工作。

当启动初始化集群的时候，server1的myid为1，zxid为0 server2的myid为2，zxid同样是0，以此类推。此种情况下zxid都是为0。先比较zxid，再比较myid。

服务器1启动，给自己投票，然后发投票信息，由于其它机器还没有启动所以它收不到反馈信息，服务器1的状态一直属于Looking(选举状态)。
服务器2启动，给自己投票，同时与之前启动的服务器1交换结果，由于服务器2的myid大所以服务器2胜出，但此时投票数没有大于半数，所以两个服务器的状态依然是LOOKING。
服务器3启动，给自己投票，同时与之前启动的服务器1,2交换信息，由于服务器3的myid最大所以服务器3胜出，此时投票数正好大于半数，所以服务器3成为领导者，服务器1,2成为小弟。
服务器4启动，给自己投票，同时与之前启动的服务器1,2,3交换信息，尽管服务器4的myid大，但之前服务器3已经胜出，所以服务器4只能成为小弟，更改选票信息为服务器3。
服务器5启动，后面的逻辑同服务器4成为小弟。

所以，在初始化的时候，一般到过半的机器数的时候谁的myid最大一般就是leader。

按照上述初始化的情况，server3成为了leader，在运行期间处于leader的server3挂了，那么非Observer服务器server1、server2、server4、server5会将自己的节点状态变为LOOKING状态

开始进行leader选举。现在选举同样是根据myid和zxid来进行。
首先每个server都会给自己投一票竞选leader。假设server1的zxid为123，server2的zxid为124，server4的zxid为169，server5的zxid为188。
同样先是比较zxid再比较myid，server1、server2、server4比较server4根据优先条件选举为leader。然后server5还是跟随server4，即使server5的zxid最大，但是当选举到server4的时候，机器数已经过半。不再进行选举，跟随已经选举的leader

zookeeper集群为保证数据的一致性所有的操作都是由leader完成，之后再由leader同步给follower。重点就在这儿，zookeeper并不会确保所有节点都同步完数据，只要有大多数节点（即n/2+1）同步成功即可。
咱们假设有一个写操作成功那么现在数据只存在于节点leader，之后leader再同步给其他follower。这时候宕掉3个机器，由于有过半的机器无法进行投票选举leader的操作，此时leader无法提供任何服务。所以宕掉的机器不要过半，过半就会导致无法正常服务。
在leader选举的时候会有30s-120s的过程，在这期间也是无法提供服务的。