zookeeper配置为集群模式时,在启动或异常情况时会选举出一个实例作为Leader。其默认选举算法为FastLeaderElection
。
不知道zookeeper的可以考虑这样一个问题:某个服务可以配置为多个实例共同构成一个集群对外提供服务。其每一个实例本地都存有冗余数据,每一个实例都可以直接对外提供读写服务。在这个集群中为了保证数据的一致性,需要有一个Leader来协调一些事务。那么问题来了:如何确定哪一个实例是Leader呢?
问题的难点在于:
- 没有一个仲裁者来选定Leader
- 每一个实例本地可能已经存在数据,不确定哪个实例上的数据是最新的
分布式选举算法正是用来解决这个问题的。
本文基于zookeeper 3.4.6 的源码进行分析。FastLeaderElection算法的源码全部位于FastLeaderElection.java
文件中,其对外接口为FastLeaderElection.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[]表示收到的投票集合。需要注意一个细节,初始投票集合里包含了自己的投票,代码中自己会将推荐人推荐给自己,网络模块(QuorumCnxManager
)直接将该消息放入接收队列。
可以看看当其他节点已经确定投票结果时,即不再是LOOKING
时的状态:
代码中有一个特殊的投票集合outofelection
,我理解为选举已结束的那些投票,这些投票仅用于表征选举结果。
当一个新启动的节点加入集群时,它对集群内其他节点发出投票请求,而其他节点已不处于LOOKING
状态,此时其他节点回应选举结果,该节点收集这些结果到outofelection
中,最终在收到合法LEADER消息且这些选票也构成选举结束条件时,该节点就结束自己的选举行为。注意到代码中会logicalclock = n.electionEpoch;
更新选举轮数
相关推荐
zookeeper选举机制图,内讲述了zookeeper是如何选举出leader、fllower的
C# 关于zookeeper主从选举的源码,有需要的同学修改一下可以用
zookeeper源码分析(一)工作原理概述 zookeeper源码分析(二)FastLeader选举算法 Zookeeper源码分析之Paxos算法之旅
改代码主要功能能是完成通过zookeeper同步mysql数据,具体的介绍可以参考博文zookeeperMaster选举以及数据同步
3、zookeeper的选举----经验证符合事实,网上很多都是错误的 网址:https://blog.csdn.net/chenwewi520feng/article/details/130287503 Leader 选举是保证分布式数据一致性的关键所在。 Leader 选举分为 Zookeeper ...
fast paxos算法与zookeeper leader选举源代码分析.doc
详细可以参见reademe.txt和博客
zookeeper安装和选举说明
zookeeper是一款高性能的分布式协调服务,其基于paxos算法来做集群,并产生出Leader和Follower。这两个都是英文的,有兴趣的童鞋可以看下。
该项目通过zookeeper三个节点Node服务客户端代码,实现zookeeper集群管理与Master选举功能示例,项目结构如下图所示,其中依赖包包含:log4j-1.2.14.jar、slf4j-api-1.7.2.jar、slf4j-log4j12-1.7.2.jar、zookeeper-...
idworker是一个基于zookeeper和snowflake算法的分布式统一ID生成工具,通过zookeeper自动注册机器(最多1024台),无需手动指定workerId和dataCenterId 怎么用 Maven < groupId>com.imadcn.framework</ groupId> ...
《Paxos到Zookeeper:分布式一致性原理与实践》从分布式一致性的理论出发,向读者简要介绍几种...第四部分(第7章)对ZooKeeper的架构设计和实现原理进行了深入分析,包含系统模型、Leader选举、客户端与服务端的工作原
【目录】 背景 基于zk的分布式选举 切换的数据一致性保证 zk的监控 效果页面 总结
第6章 Zookeeper 2 6.1. Zookeeper入门 2 6.1.1. 概述 2 6.1.2. 特点 3 ...6.5.1. 请简述ZooKeeper的选举机制 37 6.5.2. ZooKeeper的监听原理是什么 37 6.5.3. ZooKeeper的部署方式有哪几种?集群中的角
ZooKeeper是以Fast Paxos算法为基础的,Paxos 算法存在活锁的问题,即当有多个proposer交错提交时,有可能互相排斥导致没有一个proposer能提交成功,而Fast Paxos作了一些优化,通过选举产生一个leader,只有leader...
该资源内有三个xmind脑图文件,分别为Hadoop,hbase ,以及分布式协调zookeeper选举的基础知识内容。该脑图内容并不是非常详细,而是大体罗列了这三个技术的框架,适合初学者以及将要面试,复习的同学。通过脑图,...
面试官:说一说Zookeeper中Leader选举机制.doc
ZooKeeper采用一种称为Leader election的选举算法。在整个集群运行过程中,只有一个Leader,其他的都是Follower,如果ZooKeeper集群在运行过程中 Leader出了问题,系统会采用该算法重新选出一个Leader。因此,各个...
一、实验要求 完成Zookeeper的完全分布模式的安装 Zookeeper服务能够正常... Zookeeper采用的投票算法要求至少有3个及其以上的服务节点,且服务节点为奇数时为最有效的配置,所以将集群的五台主机全部作为服务节点。
本文详细分析了Zookeeper的源码,特别是Leader选举过程的实现。首先,介绍了阅读源码的意义,包括技术提升、框架掌握、问题定位、面试准备、深入理解技术以及参与开源社区。接着,提供了一系列高效阅读源码的方法,...