zookeeper集群选举
zookeeper集群选举
转载自(https://blog.csdn.net/yinwenjie/article/details/47613309),写的很好.
咱们知道了一个zookeeper集群中，有一个处于leader身份的节点，其余的节点都是flower状态。那么一个leader是怎么产生的呢？这就是zookeeper中的选举规则，默认的选举规则称为：FastLeaderELection（网上的资料还有提到另外的选举算法，实际上它们的核心思想都是同样的）web
选举算法的中心思想
网上的资料有使用纯文字进行算法描述的，也有使用流程图进行算法描述的，可是若是读者不仔细看，仍是容易昏头转向，这里咱们使用一张过程图和文字相结合的方式对FastLeaderELection选举算法进行描述。实际上FastLeaderELection说的中心思想无外乎如下几个关键点：算法
全天下我最牛，在我没有发现比我牛的推荐人的状况下，我就一直推举我当leader。第一次投票那必须推举我本身当leader。网络
每当我接收到其它的被推举者，我都要回馈一个信息，代表我仍是不是推举我本身。若是被推举者没我大，我就一直推举我当leader，是我是我仍是我！svg
我有一个票箱， 和我属于同一轮的投票状况都在这个票箱里面。一人一票 重复的或者过时的票，我都不接受。spa
一旦我再也不推举我本身了（这时我发现别人推举的人比我推荐的更牛），我就把个人票箱清空，从新发起一轮投票（这时个人票箱必定有两票了，都是选的我认为最牛的人）。.net
一旦我发现收到的推举信息中投票轮要高于个人投票轮，我也要清空个人票箱。而且仍是投当初我以为最牛的那我的（除非当前的人比我最初的推荐牛，我就顺带更新个人推荐）。xml
不断的重复上面的过程，不断的告诉别人“个人投票是第几轮”、“我推举的人是谁”。直到个人票箱中“我推举的最牛的人”收到了很多于 N /2 + 1的推举投票。blog
这时我就能够决定我是flower仍是leader了（若是至始至终都是我最牛，那我就是leader咯，其它状况就是follower咯）。而且不论随后收到谁的投票，都向它直接反馈“个人结果”。图片
一张理想的图
那么咱们按照以上的原则，进行一次投票。这是一个比较理想的状态，咱们不考虑其中的网络延迟，不考虑启动zookeeper节点时自己的时间差，咱们假设发出包的前后顺序，就是目标节点接受这些包的前后顺序。这个理想的过程当中，咱们同时开启5个zookeeper节点，让他们进行选举：get
在第一轮中，按照“我最牛逼，我怕谁”的原则，每一个节点都推荐它本身为集群的leader节点。
按照咱们假设的理想条件，节点S1首先收到了S2发送来的推荐者“2”，节点S1发现“2”要比它以前推荐的“1”（也就是它本身）牛。根据谁牛推荐谁的原则，“S1”清空本身的票箱，从新选举“2”（注意，此时“S1”的新票箱中已经有两票选举“2”了，一票是它本身，另一票是”S2”，而且全部节点都是Looking状态）
一样的事情发生在“S2”身上：”S2”收到了”S3”发过来的推荐信息，发现“3”这个被推举者比以前本身推举的“2”要牛，因而也清空本身的票箱，发起一轮新的投票，此时“S2”选举“3”。依次类推”S3”、”S4”。
这里要注意S5这个节点，在第一轮接受到了来源于“S1”——“S4”的推举者（必定注意，每一次接受信息，都会广播一次“我坚持推举的人”），发现“仍是推荐的5最牛”，因而“我继续推举S5吧”。
以上这个过程在整个理想的网络环境上一直持续。到了第四轮，“S1”收到了“S2”发送来的推举者“5”，发现“5”要比当前“S1”推荐的“4”要牛。因此“S1”清空了本身的票箱，从新推举“5”（发送给其余全部节点）。
关键的第五轮来了，咱们再重复一下，通过以前的选举，如今“S2”——“S5”都已经推举“5”为Leader了，并且都处于第四轮。这时他们收到了”S1”发来的新的“第五轮”投票，因而都和以前同样，作相同的一件事：清空本身的票箱，从新向其余全部节点广播本身的第五轮投票“5”。
因而，节点X，收到了大于N / 2 +１的选举“5”的投票，且都是第五轮投票。这样每一个节点就都知道了本身的角色。，选举结束。全部将成为Follower状态的节点，向将要成为Leader的节点发起最后一次“工做是否正常”的询问。获得确定的ack后，整个集群的工做状态就确认了。
3.三、实际上没有那么理想
关于上节的算法或者关于上上节的白话描述，若是您一边没有看懂，请多看几遍，若是您看晕了，请休息一下，清空脑壳，再看。选举算法的整个流程第一次是很差理解，可是一旦理解了其中的关键点，它就变得很简单。
咱们在上文中介绍的选举流程是基于一个基本的考虑：理想的网络环节，理想的节点处理能力。但事实上，没有这样的环境，网络状况的多变致使了咱们须要让选举算法兼容各类的状况。
下面咱们假设在选举的过程当中，“S1”,“S2”两个节点出现了宕机的状况（或者是网络延迟，或者是网络物理层断开，无论您怎么想吧，反正其它节点再也收到”S1”，”S2”的投票信息了）。以下图所示：
上图所示，在第三轮的选举过程后，“S1”,“S2”两个节点就断开了，他们的投票信息根本没有发送出去。
这样一来，“S3”收到了“S4”,“S5”发来的投票信息，这时“S3”的票箱处于第3轮，而且发现了占大多数的投票结果：你们选举“S5”为Leader节点。
一样的事情也发生在“S4”身上。这样“S3”,“S4”两个节点率先知道了投票结果，在最后一次询问Leader节点是否能正常工做，并获得了确定的ACK以后，“S3”,“S4”两个节点变成了Follower状态。
- 以后，不管“S3”,“S4”两个节点收到了任何节点的投票信息，都直接向源节点反馈投票结果，不会再进行投票了。
这样一来，在投票完成后，“S1”,“S2”从新连入后，虽然他们发起了投票，可是不会再收到投票反馈了。直接根据“S3”或者“S4”发来的结果状态，变成Follower状态。
3.四、网上的资料
上图是网络上的一张选举过程图，步骤是怎么样的，笔者我就再也不多说了，只但愿这个能辅助你们更好的理解选举过程。
哦，如今您知道为何zookeeper在少于 N / 2 + 1的节点处于工做状态的状况下会崩溃了吧。由于，不管怎么选也没有任何节点可以得到 N / 2 + 1 的票数