理解zookeeper选举机制
一、zookeeper集群
配置多个实例共同构成一个集群对外提供服务以达到水平扩展的目的,每个服务器上的数据是相同的,每一个服务器均可以对外提供读和写的服务,这点和redis是相同的,即对客户端来讲每个服务器都是平等的。

这篇主要分析leader的选择机制,zookeeper提供了三种方式:
LeaderElection
AuthFastLeaderElection
FastLeaderElection (最新默认)
默认的算法是FastLeaderElection,所以这篇主要分析它的选举机制。
二、选举流程简述
目前有5台服务器,每台服务器均没有数据,它们的编号分别是1,2,3,4,5,按编号依次启动,它们的选择举过程如下:
服务器1启动,给自己投票,然后发投票信息,由于其它机器还没有启动所以它收不到反馈信息,服务器1的状态一直属于Looking(选举状态)。
服务器2启动,给自己投票,同时与之前启动的服务器1交换结果,由于服务器2的编号大所以服务器2胜出,但此时投票数没有大于半数,所以两个服务器的状态依然是LOOKING。
服务器3启动,给自己投票,同时与之前启动的服务器1,2交换信息,由于服务器3的编号最大所以服务器3胜出,此时投票数正好大于半数,所以服务器3成为领导者,服务器1,2成为小弟。
服务器4启动,给自己投票,同时与之前启动的服务器1,2,3交换信息,尽管服
Zookeeper选举机制详解
本文深入探讨了Zookeeper集群的选举机制,详细介绍了Serverid、Zxid、Epoch等关键概念,以及选举流程和判断胜出的逻辑。通过具体例子阐述了选举过程,包括服务器启动顺序对选举的影响,以及不同服务器状态的转变。最后,解释了如何判断选举是否已经胜出,强调了服务器数量为奇数对选举的重要性。
订阅专栏 解锁全文

被折叠的 条评论
为什么被折叠?



