您好,登录后才能下订单哦!
本篇内容介绍了“Kafka中Controller的作用是什么”的有关知识,在实际案例的操作过程中,不少人都会遇到这样的困境,接下来就让小编带领大家学习一下如何处理这些情况吧!希望大家仔细阅读,能够学有所成!
Kafka除了状态管理以外,还主要有以下功能职责:
更新集群元数据信息
创建Topic
删除Topic
分区重分配
preferred leader副本选举
Topic分区扩展
Broker加入集群
Broker崩溃
受控关闭
controller leader选举
Client可以从任何一台broker上获取集群完整的元数据信息,这就需要controller在集群元数据信息发生变更后通知每一个broker。当有分区信息变更时,controller会将变更后的信息封装进UpdateMetadataRequest请求中,然后发送给集群中的每个Broker。
Controller启动时会创建一个Zookeeper监听器,该监听器的作用是监听/brokers/topics下子节点的变化情况。
Topic在创建时首先会在/brokers/topics节点下面创建一个子节点(znode),并且将该Topic的分区和副本情况写入这个znode中。当监听器发现/brokers/topics有新增znode时,就会立即触发controller创建Topic(为新的Topic每个分区确定Leader和ISR),然后更新集群元数据信息。
当创建完成以后,controller会创建一个新的监听器/brokers/topics/{topic_name},监听新的Topic内容的变更。这样当Topic分区发生变化时,controller能够及时收到通知。
Kafka集群删除Topic都是向Zookeeper下的/admin/deletetopics下新增一个子节点(znode)。controller在启动时会在/admin/deletetopics创建一个监听器监听该节点的子节点是否发生变更。当有新的子节点被创建时,controller立即开启删除Topic删除逻辑。主要执行两步:
停止该Topic的所有副本
删除副本日志数据
controller移除/admin/delete_topics/{待删除topic节点},topic删除完成
分区重分配主要为了对Topic下面的所有分区重新分配副本所在的broker机器,以期望实现更均匀的分配。该操作需要管理员手动定制分配方案,并按照指定格式写入Zookeeper的/admin/reassign_partitions下。
分区重分配的过程是先扩展再收缩的过程。controller首先将分区副本进行扩展,等他们全部与Leader副本同步以后将Leader设置为新分配方案中的副本,最后执行收缩,将分区副本减少为分配方案中的副本集合。
为了避免分区副本分配不均匀,引入preferred副本的概念,假设一个分区副本的列表是[1,2,3],那么broker1就是该分区的preferred leader。但是随着时间的推进,分区leader发生变化,最后preferred leader不一定就是分区leader。
broker段参数auto.leader.reblance.enable设置true,controller会定时自动调整preferred leader
通过kafka-preferred-replica-election脚本触发
上面两种方法都会往Zookeeper的/admin/preferredreplicaelection节点写入数据。controller也会注册该节点的目录监听器。一旦接收到改变通知,controller会将对应分区的leader调整回副本列表中的第一个,并且广播出去。
当前增加分区通常通过kafka-topics.sh的--alert选项,它会向Zookeeper下的/brokers/topics/{待修改的Topic}中写入新的分区目录。
由于在创建Topic以后,会注册一个监听该目录变化监听器,因此当目录发生变化时,controller会收到通知,执行分区创建任务,之后更新集群元数据信息。
每个broker创建成功后,都会在Zookeeper的/brokers/ids节点下创建一个子节点,并写入broker的信息。controller会在/brokers/ids创建一个监听该节点的子节点是否发生变化的监听器,一旦收到通知,然后就会更新集群元数据信息。
broker在加入集群时注册的节点是个临时节点,伴随broker的崩溃,临时节点消失,然后controller会收到通知,开启关闭broker逻辑,并更新集群元数据信息。
受控关闭是指的以kafka-server-stop.sh或者kill -15的方式关闭kafka broker。
受控关闭是由即将关闭的broker向controller发送ControlledShutdownRequest。当发送完请求后,broker处于阻塞状态,controller会进行leader重选举和ISR收缩调整后,会给broker发送ControlledShutdownResoponse,表示broker可以关闭。
当所有broker一起启动时,会争先在Zookeeper上创建/controller临时节点,并写入controller broker的信息,Zookeeper可以保证只有一个broker可以创建成功,创建成功的broker节点还会更新/controller_epoch的值。没有创建成功的broker监听/controller,加入controller宕机,其他broker将会收到通知,然后去竞选controller。
controller启动时会与集群中的所有broker(包括controller在的broker)建立TCP连接,并且会为每个TCP连接建立一个RequestSendThread,也就是说controller会和每个broker建立一个TCP连接,并且开启一个I/O线程。
controller目前主要有以下三种请求:
UpdateMetaRequest:更新集群元数据请求,包含了集群的元数据信息。broker接收到该请求后,会更新本地的缓存信息
LeaderAndIsrRequest:用于创建分区和副本
StopReplicaRequest:停止指定副本的数据请求操作,另外还负责删除副本数据功能。
“Kafka中Controller的作用是什么”的内容就介绍到这里了,感谢大家的阅读。如果想了解更多行业相关的知识可以关注亿速云网站,小编将为大家输出更多高质量的实用文章!
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。