Kafka 核心源码解读
胡夕
Apache Kafka Committer,老虎证券技术总监
19216 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 44 讲
结束语 (1讲)
Kafka 核心源码解读
15
15
1.0x
00:00/00:00
登录|注册

11 | Controller元数据:Controller都保存有哪些东西?有几种状态?

你好,我是胡夕。从今天开始,我们正式进入到第三大模块的学习:控制器(Controller)模块 。
提起 Kafka 中的 Controller 组件,我相信你一定不陌生。从某种意义上说,它是 Kafka 最核心的组件。一方面,它要为集群中的所有主题分区选举领导者副本;另一方面,它还承载着集群的全部元数据信息,并负责将这些元数据信息同步到其他 Broker 上。既然我们是 Kafka 源码解读课,那就绝对不能错过这么重量级的组件。
我画了一张图片,希望借助它帮你建立起对这个模块的整体认知。今天,我们先学习下 Controller 元数据。

案例分享

在正式学习源码之前,我想向你分享一个真实的案例。
在我们公司的 Kafka 集群环境上,曾经出现了一个比较“诡异”的问题:某些核心业务的主题分区一直处于“不可用”状态。
通过使用“kafka-topics”命令查询,我们发现,这些分区的 Leader 显示是 -1。之前,这些 Leader 所在的 Broker 机器因为负载高宕机了,当 Broker 重启回来后,Controller 竟然无法成功地为这些分区选举 Leader,因此,它们一直处于“不可用”状态。
由于是生产环境,我们的当务之急是马上恢复受损分区,然后才能调研问题的原因。有人提出,重启这些分区旧 Leader 所在的所有 Broker 机器——这很容易想到,毕竟“重启大法”一直很好用。但是,这一次竟然没有任何作用。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

Kafka的Controller组件是整个集群中最核心的部分之一,负责领导者副本的选举和元数据信息的同步。本文深入解析了Controller元数据和相关类的定义,为读者提供了深入了解Kafka Controller组件的基础知识。文章介绍了ControllerContext类中的重要元数据,如ControllerStats类的统计信息,以及掌握这些元数据有助于理解元数据缓存。此外,还介绍了Controller事件状态的执行速率与时间的统计信息,强调了对一些Controller事件的额外关注的重要性。文章还详细解释了Controller元数据中的重要字段,如offlinePartitionCount、shuttingDownBrokerIds、liveBrokers等,以及它们在Controller操作中的作用和实际应用。通过对Controller元数据的深入了解,读者可以更清晰地理解Controller在Kafka集群中的作用和重要性。同时,文章还提供了一些源码示例,帮助读者更好地理解Controller元数据的实际应用和操作方法。总的来说,本文为读者提供了一个全面的Kafka Controller组件概览,使他们能够快速了解并掌握这一关键组件的核心知识。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《Kafka 核心源码解读》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(10)

  • 最新
  • 精选
  • 胡夕
    置顶
    你好,我是胡夕。我来公布上节课的“课后讨论”题答案啦~ 上节课,咱们重点了解了Kafka中重要的源码入口类KafkaApis。课后我请你思考如果一个Consumer要向Broker提交位移,它应该具备什么权限以及声明权限的具体代码位置哪段代码。下面我给出我的答案:消费者要具有GROUP的READ权限和TOPIC的READ权限才能提交位移。具体代码位置在handleOffsetCommitRequest方法的这两行中: if (!authorize(request.context, READ, GROUP, offsetCommitRequest.data.groupId)) { ...... } else { ...... val authorizedTopics = filterByAuthorized(request.context, READ, TOPIC, topics)(_.name) ...... } okay,你同意这个说法吗?或者说你有其他的看法吗?我们可以一起讨论下。
    2020-05-19
    1
  • 曾轼麟
    我个人比较期待kafka摆脱zookeeper的时候,之前看过一篇文章,对比kafka和RocketMQ的性能对比,其中总结出,kafka的性能会受到topic数量的增加而下降,看了源码后才逐渐明白其实制约kafka的正是zookeeper

    作者回复: 个人感觉性能的那个问题和ZooKeeper关系不大。主要还是分区路径太分散导致顺序IO变为随机IO

    2020-05-31
    4
    6
  • 曾轼麟
    partitionLeadershipInfo存储的主要是leader,leaderEpoch,isr集合,zkVersion,这些都定义在LeaderAndIsr这个类里面

    作者回复: 👍

    2020-05-31
    1
  • 伯安知心
    partitionLeadershipInfo总的来说每个分区对应的分区主副本,isr集合,还有controller的epoch数,

    作者回复: 嗯,是的

    2020-05-15
    1
  • 吃饭饭
    z这里怎么理解【将集群上所有新分区和 Offline 分区状态变更为 Online 状态;】直接把 deadBrokers 标记为 Offline 不就可以了吗?

    作者回复: 没太明白这个问题。到底是online还是offline的问题?

    2021-08-05
  • 曾轼麟
    在kafka中我发现经常使用epoch的方式来判断版本新旧,其实epoch这种设计思想类似于乐观锁的方式

    作者回复: 应该算是token机制的一种

    2020-05-31
  • 伯安知心
    您说删除的watcher,oncontrollerfailover重新初始化上下文,我感觉代价昂贵了些,就应该做这么多事吗?

    作者回复: 可以具体说说哪一步在您看来是多余的,也许是个优化的方向:)

    2020-05-15
    2
  • 伯安知心
    还有请问partitionLeadershipInfo中controller的epoch是干吗的呢?

    作者回复: 你可以认为是controller换了多少次。比如epoch = 5,说明controller前前后后更换过6次

    2020-05-15
    2
  • 鸣己
    我有遇到过一个集群有三个controller;它们好像谁也不服谁,导致好多topic没leader
    2021-03-25
    1
  • 张子涵
    val partitionLeadershipInfo = mutable.Map.empty[TopicPartition, LeaderIsrAndControllerEpoch] def removeTopic(topic: String): Unit = { allTopics -= topic partitionAssignments.remove(topic) partitionLeadershipInfo.foreach { case (topicPartition, _) if topicPartition.topic == topic => partitionLeadershipInfo.remove(topicPartition) case _ => } } 根据partitionLeadershipInfo定义,以及在removeTopic方法中partitionLeadershipInfo的应用,可大概理解partitionLeadershipInfo中存储的是分区以及leader epoch 类似变更版本信息
    2020-08-24
收起评论
显示
设置
留言
10
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部