【Java面试】Zookeeper如何实现Leader选举

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、等一致性算法。

大家记得点赞收藏加关注。