zookeeper选举机制有什么作用(zookeeper在什么情况下选举)

动物园管理员的选举机制是什么？很多新手对此不是很清楚。为了帮助大家解决这个问题，下面小编就为大家详细讲解一下。需要的人可以从中学习，希望你能有所收获。

Zookeeper是一个分布式服务框架，主要用于解决分布式应用中遇到的一些数据管理问题，如统一命名服务、状态同步服务、集群管理、分布式应用配置项管理等。

我们可以简单地把Zookeeper理解为分布式家庭的管家，那么管家团队是如何选择Leader的呢？好奇？让我们来看看。

人类选举的基本原理

在解释动物园管理员的选举过程之前，我们先介绍一下人类选举。

我们每个人或多或少都经历过几次选举，在投票过程中可能会遇到以下情况：

情况一：你熟悉几个候选人，你会投给你认为更有能力的人；

熟人选举

情况二：我也是考生，对其他几个考生不熟悉。这个时候你肯定在考虑拉票，因为你觉得自己是最好的人，大家都应该投我一票。可惜在拉票的过程中，你发现别人比你优秀，你开始自卑。最后，你把票投给了你认为最强的人。

自己参加选举

每个人投完票后，最后会从投票箱中清点，得票最多的人当选。

思维导图

在整个投票过程中，我们可以提炼出四个核心概念：

候选人能力：投票的基本原则是选择最强的人。

如果是强票：如果后来发现更强的人，他可以改变投票。

投票箱：所有人的票都会放在投票箱里。

领袖：领袖是得票最多的人。

从人类的选举原则出发，我们简单地推导一下动物园管理员的选举原则。

Zookeeper选举的基本原理

请注意，如果Zookeeper部署在单台机器上，则不需要选举，而只需要集群模式。

动物园管理员的选举原则类似于人类选举的逻辑。应用人类选举的四个基本概念详细解释动物园管理员。

个人能力

如何衡量动物园管理员节点的个人能力？答案取决于数据是否足够新。如果一个节点的数据比较新，说明这个节点的个人能力比较强。感觉奇怪吗？就这样！

在Zookeeper中，事务id(以下简称zxid)通常用于标识数据的新度(版本)。一个节点的最新zxid越大，这个节点的数据就越新，这个节点的能力就越强。

zxid的全称是Zookeeper事务id，也就是ZooKeeper事务Id。

遇强改投

在集群选举开始时，节点首先认为自己最强(即数据最新)，然后在选票上写上自己的名字(包括zxid和sid)，其中zxid是交易id，sid唯一标识自己。

然后，它将投票传递给其他节点，同时，它还将接收来自其他节点的投票。收到选票后，每个节点都会比较这个人是不是比我强(zxid比我大)。如果是的话，那么我需要换票。别人比我强的时候我也不能厚脸皮吧？

投票箱

与人类选举投票箱略有不同，Zookeeper集群在每个节点的内存中维护一个投票箱。节点会把自己的选票和其他节点的选票放在这个投票箱里。由于选票是相互分发的，每个节点的投票箱中的选票最终将是相同的。

领导者

在投票的过程中，我们会统计是否有超过一半的选票和我们的选择在同一个节点，也就是我们都认为某个节点最强。一旦集群中超过一半的节点认为某个节点最强，那个节点就是领头羊，投票就结束了。

什么场景下 Zookeeper 需要选举？

当Zookeeper集群中的服务器出现以下两种情况之一时，需要进入Leader选举。

(1)服务器被初始化和启动。

(2)在服务器运行期间，Leader失败。

启动时期的 Leader 选举

假设动物园管理员集群中有五个服务。

器，id从1到5编号，并且它们都是最新启动的，没有历史数据。

集群刚启动选举过程

假设服务器依次启动，我们来分析一下选举过程：

(1)服务器1启动

发起一次选举，服务器1投自己一票，此时服务器1票数一票，不够半数以上(3票)，选举无法完成。

投票结果：服务器1为1票。

服务器1状态保持为LOOKING。

(2)服务器2启动

发起一次选举，服务器1和2分别投自己一票，此时服务器1发现服务器2的id比自己大，更改选票投给服务器2。

投票结果：服务器1为0票，服务器2为2票。

服务器1，2状态保持LOOKING

(3)服务器3启动

发起一次选举，服务器1、2、3先投自己一票，然后因为服务器3的id最大，两者更改选票投给为服务器3;

投票结果：服务器1为0票，服务器2为0票，服务器3为3票。此时服务器3的票数已经超过半数(3票)，服务器3当选Leader。

服务器1，2更改状态为FOLLOWING，服务器3更改状态为LEADING。

(4)服务器4启动

发起一次选举，此时服务器1，2，3已经不是LOOKING  状态，不会更改选票信息。交换选票信息结果：服务器3为3票，服务器4为1票。此时服务器4服从多数，更改选票信息为服务器3。

服务器4并更改状态为FOLLOWING。

(5)服务器5启动

与服务器4一样投票给3，此时服务器3一共5票，服务器5为0票。

服务器5并更改状态为FOLLOWING。

最终的结果：

服务器3是 Leader，状态为 LEADING;其余服务器是 Follower，状态为 FOLLOWING。

运行时期的Leader选举

在 Zookeeper运行期间 Leader 和 非 Leader 各司其职，当有非 Leader 服务器宕机或加入不会影响 Leader，但是一旦  Leader 服务器挂了，那么整个 Zookeeper 集群将暂停对外服务，会触发新一轮的选举。

初始状态下服务器3当选为Leader，假设现在服务器3故障宕机了，此时每个服务器上zxid可能都不一样，server1为99，server2为102，server4为100，server5为101

集群 Leader 节点故障

运行期选举与初始状态投票过程基本类似，大致可以分为以下几个步骤：

(1)状态变更。Leader 故障后，余下的非 Observer  服务器都会将自己的服务器状态变更为LOOKING，然后开始进入Leader选举过程。

(2)每个Server会发出投票。

(3)接收来自各个服务器的投票，如果其他服务器的数据比自己的新会改投票。

(4)处理和统计投票，每一轮投票结束后都会统计投票，超过半数即可当选。

(5)改变服务器的状态，宣布当选。

话不多说先来一张图：

运行器 Leader 故障后选举流程

(1)第一次投票，每台机器都会将票投给自己。

(2)接着每台机器都会将自己的投票发给其他机器，如果发现其他机器的zxid比自己大，那么就需要改投票重新投一次。比如server1  收到了三张票，发现server2的xzid为102，pk一下发现自己输了，后面果断改投票选server2为老大。

选举机制中涉及到的核心概念

敲黑板了，这些概念是面试必考的。

(1)Server id(或sid)：服务器ID

比如有三台服务器，编号分别是1,2,3。编号越大在选择算法中的权重越大，比如初始化启动时就是根据服务器ID进行比较。

(2)Zxid：事务ID

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

(3)Epoch：逻辑时钟

也叫投票的次数，同一轮投票过程中的逻辑时钟值是相同的，每投完一次票这个数据就会增加。

(4)Server状态：选举状态

LOOKING，竞选状态。

FOLLOWING，随从状态，同步leader状态，参与投票。

OBSERVING，观察状态,同步leader状态，不参与投票。

LEADING，领导者状态。

总结

(1)Zookeeper 选举会发生在服务器初始状态和运行状态下。

(2)初始状态下会根据服务器sid的编号对比，编号越大权值越大，投票过半数即可选出Leader。

(3)Leader 故障会触发新一轮选举，zxid 代表数据越新，权值也就越大。

看完上述内容是否对您有帮助呢？如果还想对相关知识有进一步的了解或阅读更多相关文章，请关注行业资讯频道，感谢您对的支持。