zookeeper的选举机制

最新推荐文章于 2024-04-04 15:05:52 发布

阿兴呢！！！

最新推荐文章于 2024-04-04 15:05:52 发布

阅读量241

点赞数 1

分类专栏： ZOOKEEPER 文章标签： zookeeper 服务器分布式 hadoop 大数据

原文链接：https://blog.csdn.net/cvwarrior_wutu/article/details/122178897

版权

ZOOKEEPER 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

zookeeper的选举机制

Zookeeper作为一个开源的分布式的，为分布式应用提供协调服务的Apache项目。

    它有一个很重要的特点：半数机制，集群中只要有半数以上节点存活，Zookeeper集群就能正常服务，所以Zookeeper适合安装奇数台服务器（最少3台）。

    Zookeeper虽然在配置文件中并没有指定Master和Slave。但是，Zookeeper工作时，是有一个节点为Leader，其他则为Follower，Leader是通过内部的选举机制临时产生的。

下面我就用一个简单的例子来说明整个选举的过程。

    首先我们假设有五台服务器组成的Zookeeper集群，它们的id从1-5，同时它们都是最新启动的，也就是没有历史数据，在存放数据量这一点上，都是一样的，并且这些服务器是从1-5依序启动的。

在这里插入图片描述

1.服务器1启动，发起一次选举。服务器1投自己一票。此时服务器1票数一票，不够半数以上（3票），选举无法完成，服务器1状态保持为LOOKING；

2.服务器2启动，再发起一次选举。服务器1和2分别投自己一票并交换选票信息：此时两台服务器的zxid相同，但是服务器1发现服务器2的myid比自己目前投票推举的（服务器1自己）大，更改选票为推举服务器2。此时服务器1票数0票，服务器2票数2票，没有半数以上（3票）结果，选举无法完成，服务器1，2状态保持LOOKING；

3.服务器3启动，发起一次选举。同理此时服务器1和2都会更改选票为服务器3。此次投票结果：服务器1为0票，服务器2为0票，服务器3为3票。此时服务器3的票数已经超过半数，服务器3当选Leader。服务器1，2更改状态为FOLLOWING，服务器3更改状态为LEADING；

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

5.服务器5启动，同服务器4一样没得选择，只能当小弟，只能说生不逢时了。

假如作为leader的服务器3在运行过程中挂了，那么就会在服务器1、2、4、5中重新选举leader，流程跟第一次选举没有太大的差异，也是比较zxid和myid，当选举出leader后，后面的zxid和myid再大也只能当follower了。

注释：zxid (ZooKeeper Transaction Id，唯一的，如果zxid a < zxid b ，那说明a一定发生在b之前)。

     LOOKING：选举中，正在寻找leader，即将进入leader选举流程中；

     LEADING：说明此节点已经是leader节点，处于领导者地位的状态；

     FOLLOWING：跟随，表示当前集群中的leader已经选举出来了。
     
     OBSERVING：OBSERVING和FOLLOWING差不多，但不参加投票和选举，接受leader选举后的结果

原文链接：https://blog.csdn.net/cvwarrior_wutu/article/details/122178897