Zookeeper的选举制度

目录

说明

        概念

        全新集群选举

        非全新集群选举

        ​​​​​​​为什么需要leader选举

---

说明

1. 基于节点在半数以上才能正常服务的要求， Zookeeper 适合装在奇数台机器。

2. Zookeeper 没有在配置⽂件中指定 leader 和 follower ，⽽是使⽤算法 (Paxos) 在内部通过选举机制来选择⼀个节点为leader ，其他节点为 follower 。

概念

数据ID(zxid )

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

服务器ID(serverid)

比如有三台服务器，编号分别是1,2,3。

编号越大在选择算法中的权重越大。。

逻辑时钟(Epoch )

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

优先级：Epoch > zxid >serverid

选举状态

Server：选举状态

LOOKING，竞选状态。

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

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

LEADING，领导者状态，集群⼯作的核⼼

全新集群选举

        假设有五台服务器组成的 zookeeper 集群，它们的 id 从 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集群，中途有机器down掉，需要重新选举时，选举过程就需要加入数据ID、服务器ID和逻辑时钟。

数据ID：数据新的version就大，数据每次更新都会更新version。

服务器ID：就是我们配置的myid中的值，每个机器一个。

逻辑时钟：这个值从0开始递增,每次选举对应一个值。 如果在同一次选举中,这个值是一致的。

这样选举的标准就变成：

1、逻辑时钟小的选举结果被忽略，重新投票；

2、统一逻辑时钟后，数据id大的胜出；

3、数据id相同的情况下，服务器id大的胜出；

根据这个规则选出leader。

为什么需要leader选举

        Leader选举是保证分布式数据⼀致性的关键所在. 当Zookeeper集群中的⼀台服务器出现以下两种情况之⼀时，需要进⼊Leader选举。

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

        (2) 服务器运⾏期间⽆法和 Leader 保持连接。

原则 :

        默认半数以上的机器同意,当前的节点就是leader

        默认半数以上的机器存活,zookeeper 集群就能对外提供服务