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

12 | ControllerChannelManager:Controller如何管理请求发送?

你好,我是胡夕。上节课,我们深入研究了 ControllerContext.scala 源码文件,掌握了 Kafka 集群定义的重要元数据。今天,我们来学习下 Controller 是如何给其他 Broker 发送请求的。
掌握了这部分实现原理,你就能更好地了解 Controller 究竟是如何与集群 Broker 进行交互,从而实现管理集群元数据的功能的。而且,阅读这部分源码,还能帮你定位和解决线上问题。我先跟你分享一个真实的案例。
当时还是在 Kafka 0.10.0.1 时代,我们突然发现,在线上环境中,很多元数据变更无法在集群的所有 Broker 上同步了。具体表现为,创建了主题后,有些 Broker 依然无法感知到。
我的第一感觉是 Controller 出现了问题,但又苦于无从排查和验证。后来,我想到,会不会是 Controller 端请求队列中积压的请求太多造成的呢?因为当时 Controller 所在的 Broker 本身承载着非常重的业务,这是非常有可能的原因。
在看了相关代码后,我们就在相应的源码中新加了一个监控指标,用于实时监控 Controller 的请求队列长度。当更新到生产环境后,我们很轻松地定位了问题。果然,由于 Controller 所在的 Broker 自身负载过大,导致 Controller 端的请求积压,从而造成了元数据更新的滞后。精准定位了问题之后,解决起来就很容易了。后来,社区于 0.11 版本正式引入了相关的监控指标。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文深入介绍了Kafka中ControllerChannelManager模块的工作原理和请求发送机制。通过监控Controller请求队列长度来解决元数据更新滞后的问题,并详细介绍了Controller发送的三类请求类型:LeaderAndIsrRequest、StopReplicaRequest和UpdateMetadataRequest,以及它们在代码中的定义和使用方式。文章还分析了RequestSendThread类的定义和doWork方法的执行逻辑,阐述了请求发送的阻塞队列和Response处理过程。读者可以通过本文深入了解Kafka中Controller的请求发送机制,以及掌握请求发送的原理,有助于更好地理解Controller与集群Broker的交互,从而实现管理集群元数据的功能。文章重点介绍了ControllerChannelManager类的任务和重要数据结构brokerStateInfo,以及其管理方法,如添加Broker、移除Broker等。此外,文章还详细分析了Controller向Broker发送请求机制的实现原理,包括RequestSendThread的作用和启动逻辑。整体而言,本文为读者提供了深入了解Kafka中Controller请求发送机制的重要知识,对于理解和应用该技术具有重要参考价值。

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

全部留言(6)

  • 最新
  • 精选
  • 胡夕
    置顶
    你好,我是胡夕。我来公布上节课的“课后讨论”题答案啦~ 上节课,咱们重点了解了Controller元数据类ControllerContext。课后我请你自行分析下partitionLeadershipInfo里面保存的内容。实际上,这是一个按照主题分区分组的分区详细数据容器。它保存了每个分区Leader副本位于哪个Broker、Leader Epoch值是多少、ISR集合都有哪些副本以及Controller Epoch值。其中Leader副本和ISR副本集合是分区最重要的数据。 okay,你同意这个说法吗?或者说你有其他的看法吗?我们可以一起讨论下。
    2020-05-19
  • 柠檬C
    RequestSendThread线程的doWork方法中,发送请求是同步的,如果共用一个线程,可能会因为某个broker长时间不响应,影响其他broker的请求发送,老师,是这个原因吗?

    作者回复: 嗯嗯,差不多是这个意思

    2020-09-15
  • yic
    胡老师,学到这节课,发现生产者-消费者在多线程场景确实是很好用,我想问一下,还有其他模式可以比较好的处理多线程场景吗?

    作者回复: 你指的多线程场景具体是什么场景呢?还是要具体问题具体分析下:)

    2020-08-06
  • 曾轼麟
    为每个Broker都创建一个RequestSendThread: 优点: 1、broker和broker之间有较好的隔离性,因为每个控制类请求需要等待响应后才会发送下一个,通过这种方式避免broker之间相互影响 2、可以对每个线程维护自己的队列,这样队列里面的数据本身在一个线程底下可以避免一定成都的并发 3、如果一个集群里面有多个版本的broker,也容易拓展功能,针对不同版本类型的broker执行不同的发送方式 缺点: 1、随着broker的数量增加,需要的线程数量也必然增加 2、需要监控指标需要做在每个线程内部,多线程的情况下也需要对多个线程进行监控

    作者回复: 非常好的总结。你觉得还能怎么优化下吗:)

    2020-06-05
  • 花轮君
    从另外一个角度看,如果controller只有单线程去调用所有的broker,那如果中间某一台的broker交互阻塞,势必会影响到整个集群。采用broker维护request的方案在于必须加上对应的监控

    作者回复: 很有道理:)

    2020-05-16
    2
  • kai
    请问一下,为什么社区会做出这种选择:社区越来越倾向于将重要的数据结构源代码从服务器端的 core 工程移动到客户端的 clients 工程中 ?
    2023-01-13归属地:上海
收起评论
显示
设置
留言
6
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部