Hi,大家好,我是Mic,一个工作了14年的程序员和创业者。
一个工作了7年的粉丝,最近去面试遇到Zookeeper里面的一个问题。
因为平时很少研究,所以面试的时候只能一个劲的说:不知道。
他觉得很尴尬,于是来问我,:“Zookeeper是如何实现Leader选举的”。
下面看看普通人和高手对这个问题的回答
需要高手面试文档(附赠大厂内部十万字面试文档)或者有不懂的技术面试题想咨询的小伙伴可以后台私信【Mic】或者评论区留言。
普通人:
Zookeeper里面我记得有一个epoch和myid就是它们在投票的时候,就是它们会有一个少数服从多数的一个机制。
然后去根据刚刚的什么myid和epoch去做一个比较吧,最终少数服从多数 就是去实现的。
高手:
好的。
首先,Zookeeper集群节点由三种角色组成,分别是
-
Leader,负责所有事务请求的处理,以及过半提交的投票发起和决策。
-
Follower,负责接收客户端的非事务请求,而事务请求会转发给Leader节点来处理,
另外,Follower节点还会参与Leader选举的投票。
-
Observer,负责接收客户端的非事务请求,事务请求会转发给Leader节点来处理,
另外Observer节点不参与任何投票,
只是为了扩展Zookeeper集群来分担读操作的压力。
其次,Zookeeper集群是一种典型的中心化架构,也就是会有一个Leader作为决策节点,
专门负责事务请求的处理和数据的同步。
这种架构的好处是可以减少集群架构里面数据同步的复杂度,集群管理会更加简单和稳定。
但是,会带来Leader选举的一个问题,也就是说,(如图)如果Leader节点宕机了,为了保证集群继续提供可靠的服务,
Zookeeper需要从剩下的Follower节点里面去选举一个新的节点作为Leader,也就是所谓的Leader选举!
[备注: 下面这个图,做成动画形式,设计的时候找Mic讨论一下]
具体的实现是,
每一个节点都会向集群里面的其他节点发送一个票据Vote,这个票据包括三个属性。
-
epoch, 逻辑时钟,用来表示当前票据是否过期。
-
zxid,事务id,表示当前节点最新存储的数据的事务编号
-
myid,服务器id,在myid文件里面填写的数字。
每个节点都会选自己当Leader,所以第一次投票的时候携带的是当前节点的信息。
接下来每个节点用收到的票据和自己节点的票据做比较,根据epoch、zxid、myid的顺序逐一比较,
以值最大的一方获胜。比较结束以后这个节点下次再投票的时候,发送的投票请求就是获胜的Vote信息。
然后通过多轮投票以后,每个节点都会去统计当前达成一致的票据,以少数服从多数的方式,最终
获得票据最多的节点成为Leader。
以上就是我对这个问题的理解。
最后我再补充一下,选择epoch/zxid/myid作为投票评判依据的原因,我是这么理解的。
epoch ,因为网络通信延迟的可能性,有可能在新一轮的投票里面收到上一轮投票的票据,这种数据应该丢弃,否则会影响投票的结果和效率。
zxid, zxid越大,说明这个节点的数据越接近leader,所以用zxid做判断条件是为了避免数据丢失的问题
myid, 服务器id,这个是避免投票时间过长,直接用myid最大值作为快速终结投票的属性。
嗯!
总结
Leader选举是一个比较复杂的问题,它涉及到集群节点的数据一致性算法。
在很多中间件里面都有涉及到类似的问题,这个思想其实还是很有研究价值的。
除此之外,还有Paxos、raft、等一致性算法。
大家记得点赞收藏加关注。