加入收藏 | 设为首页 |

小狗视频-图解zookeeper FastLeader推举算法

海外新闻 时间: 浏览:212 次

zookeeper装备为集群形式时,在发动或异常状况时会推举出一个实例作为Leader。其默许推举算法为FastLeaderElection。

不知道zookeeper的能够考虑这样一个问题:某个服务能够装备为多个小狗视频-图解zookeeper FastLeader推举算法实例一起构成一个集群对外供给服务。其每一个实例本地都存有冗余数据,每一个实例都能够直接对外供给读写服务。在这个集群中为了确保数据的共同性,需求有一个Leader来和谐一些业务。那么问题来了:怎么确认哪一个实例是Leader呢?

问题的难点在于:

  • 没有一个仲裁者来选定Leader
  • 每一个实例本地或许现已存在数据,不确认哪个实例上的数据是最新的

分布式推举算法正是用来小狗视频-图解zookeeper FastLeader推举算法处理这个问题的。

本文根据zookeeper 3.4.6 的源码进行剖析。FastLeaderElection算法的源码悉数坐落FastLeaderElection.java文件中,其对外接口为FastLeaderElec小狗视频-图解zookeeper FastLeader推举算法tion.lookForLeader,该接口是一个同步接口,直到推举完毕才会回来。相同因为网上已有相似文章,所以我就从图示的视点来论述。

首要流程

阅览代码和以上引荐文章能够把整个流程整理清楚。完结上,包含了一个音讯处理主循环,也是推举的首要逻辑,以及一个音讯发送行列处理线程和音讯解码线程。首要流程可归纳为下图:

引荐对照着引荐的文章及代码了解,不赘述。

咱们从理性上来了解这个算法。

每一个节点,相当于一个选民,他们都有自己的引荐人,最开端他们都引荐自己。谁更适合成为Leader有一个简略的规矩,例如sid够大(装备)、持有的数据够新(zxid够大)。每个选民都告知其他选民自己现在的引荐人是谁,相似于出去搞宣扬撮合其他选民。每一个选民发现有比自己更适合的人时就转而引荐这个更适合的人。终究,大部分人意见共同时,就能够完毕推举。

就这么简略。整体上有一种不断演化迫临成果的感觉。

当然,会有些特别状况的处理。例如一共3个选民,1和2现已确认3是Leader,但3还不知情,此刻就走入LEADING/FOLLOWING的分支,选民3仅仅接纳成果。

代码中不是一切逻辑都在这个大流程中完结的。在接纳音讯线程中,还或许单独地回应某个节点(WorkerReceiver.run):

从这儿能够看出,当某个节点现已确认推举成果不再处于LOOKING状况时,其收到LOOKING音讯时都会直接回应推举的终究成果。结合上面那个比如,相当于某次推举完毕了,这个时分来了选民4又建议一次新的推举,那么其他选民就直接告知它当时的Leader状况。相当于,在这个集群主从现已安排妥当的状况下,又敞开了一个实例,这个实例就会直接运用当时的推举成果。

状况转化

每个节点上有一些要害的数据结构:

  • 当时引荐人,初始引荐自己,每次收到其他更好的引荐人时就更新
  • 其他人的投票调集,用于确认何时推举完毕

每次引荐人更新时就会进行播送,正是这个不断地播送驱动整个算法趋向于成果。假设有3个节点A/B/C,其都还没有数据,依照sid关系为C>B>A,那么依照规矩,C更或许成为Leader,其各个节点的状况转化为:

图中,v(A)表明当时引荐人为A;r[]表明收到的投票调集。

能够看看当其他节点现已确认投票成果时,即不再是LOOKING时的状况:

代码中有一个特别的投票调集outofelection,我了解为推举已完毕的那些投票,这些投票仅用于表征推举成果。

当一个新发动的节点参加集群时,它对集群内其他节点宣布投票恳求,而其他节点已不处于LOOKING状况,此刻其他节点回应推举成果,该节点搜集这些成果到outofelection中,终究在收到合法LEADER音讯且这些选票也构成推举完毕条件时,该节点就完毕自己的推商务车举行为。注意到代码中会logicalclock = n.electionEpoch;更新推举轮数

————————————————

版权声明:本文为CSDN博主「kevinlynx」的原创文章,遵从 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接及本声明。

原文链接:https://blog.csdn.net/kevinlynx/article/details/40263331