Leader Election
Zookeeper的基本操作
Zookeeper虽然是分布式系统,但它并不是为文件存储而设计的,Zookeeper里存储的一般是配置信息和源信息。实际上,Zookeeper在每个节点上存储大小都在1M一下(通常是远小于1M)
基于Zookeeper的Leader Election
抢注Leader节点——非公平模式
1.创建Leader父节点,如/chroot,并将其设置为persist节点
2.各客户端通过在/chroot下创建Leader节点,如/chroot/leader,来竞争Leader。该节点应被设置为ephemeral
3.若某创建Leader节点成功,则该客户端成功竞选为Leader
4.若创建Leader节点失败,则竞选Leader失败,在/chroot/leader节点上注册exist的watch,一旦该节点被删除则获得通知
5.Leader可通过删除Leader节点来放弃Leader
6.如果Leader宕机,由于Leader节点被设置为ephemeral,leader节点会自行删除除。而其它节点由于在Leader节点上注册了watch,故可得到通知,参与下一轮竞选,从而保证总有客户端以Leader角色工作
先到先得,后则监视前者——公平模式
1.创建Leader父节点,如/chroot。并将其设置为persist节点
2.各客户端通过在/chroot下创建Leader节点,如/chroot/leader,来竞争Leader。该节点应被设置为ephemeral_sequential
3.客户端通过getChildren方法获取/chroot/下所有子节点,如果其注册的节点的id在所有子节点中最小,则当前客户端竞选Leader成功
4.否则,在前面一个节点上注册watch,一旦前者被删除,则它得到通知,返回step3
5.Leader节点可通过自行删除自己创建的节点以放弃Leader
Leader Election在Curator中实现(Curator提供2种实现)
Kafka基于Controller的Leader Election
基于Controller的Leader Election
》整个集群中选举出一个Broker作为Controller
》Controller为所有的Topic的所有Partition指定Leader及Follower
优点
》极大缓解Herd Effect问题
》减轻Zookeeper负载
》Controller与Leader及Follower间通过RPC通信,高效且实时
缺点
》引入Controller增加了复杂度
》需要考虑Controller的Failover
注:Kafka 0.8.2之前的版本Kafka的Leader Election是由每个Patition的多个Replica同时竞争Leader。
接下来我们讲讲Kafka Controller,下面是Kafka的一部分源码,主要是讲Controller
//每个server启动起来之前都要先启动kafkaController
我们进去看看
//这部分功能是监控eclectionPath,也就是Controller的Path,观察是否有数据变化
//如果有数据变化,就进入elect函数,立马做一次选举
我们看怎么选举的
//不管当前有没有Controller,先获取leader信息,再去判断Controller是否是leader
Controller Failover
Controller挂了,如果Controller是leader,那么新的Controller会告诉所有的和leader有关的follower新的leader,通过RPC的方式。