leader对于消息的写入以及读取是非常关键的,此时有两个疑问:
1. Kafka如何确定某个partition是leader、哪个partition是follower呢?
2. 某个leader崩溃了,如何快速确定另外一个leader呢?因为Kafka的吞吐量很高、延迟很低,所以选举leader必须非常快。
如果leader崩溃,Kafka会如何?
使用Kafka Eagle找到某个partition的leader,再找到leader所在的broker。在Linux中强制杀掉该Kafka的进程,然后观察leader的情况。
通过观察,我们发现,leader在崩溃后,Kafka又从其他的follower中快速选举出来了leader。
Controller介绍
l Kafka启动时,会在所有的broker中选择一个controller
l 前面leader和follower是针对partition,而controller是针对broker的
l 创建topic、或者添加分区、修改副本数量之类的管理任务都是由controller完成的
l Kafka分区leader的选举,也是由controller决定的
Controller的选举
l 在Kafka集群启动的时候,每个broker都会尝试去ZooKeeper上注册成为Controller(ZK临时节点)
l 但只有一个竞争成功,其他的broker会注册该节点的监视器
l 一点该临时节点状态发生变化,就可以进行相应的处理
l Controller也是高可用的,一旦某个broker崩溃,其他的broker会重新注册为Controller
找到当前Kafka集群的controller
1. 点击Kafka Tools的「Tools」菜单,找到「ZooKeeper Brower...」
2. 点击左侧树形结构的controller节点,就可以查看到哪个broker是controller了。
测试controller选举
通过kafka tools找到controller所在的broker对应的kafka进程,杀掉该进程,重新打开ZooKeeper brower,观察kafka是否能够选举出来新的Controller。
Controller选举partition leader
l 所有Partition的leader选举都由controller决定
l controller会将leader的改变直接通过RPC的方式通知需为此作出响应的Broker
l controller读取到当前分区的ISR,只要有一个Replica还幸存,就选择其中一个作为leader否则,则任意选这个一个Replica作为leader
l 如果该partition的所有Replica都已经宕机,则新的leader为-1
为什么不能通过ZK的方式来选举partition的leader?
l Kafka集群如果业务很多的情况下,会有很多的partition
l 假设某个broker宕机,就会出现很多的partiton都需要重新选举leader
l 如果使用zookeeper选举leader,会给zookeeper带来巨大的压力。所以,kafka中leader的选举不能使用ZK来实现。
文章来源于:王晴儿网页设计博客 欢迎分享交流,转载请注明出处
本文来自投稿,不代表重蔚自留地立场,如若转载,请注明出处https://www.cwhello.com/262281.html
如有侵犯您的合法权益请发邮件951076433@qq.com联系删除