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

09 | SocketServer(下):请求处理全流程源码分析

你好,我是胡夕。前几节课,我们花了很多时间学习 SocketServer 核心组件的源代码,包括 Acceptor 线程、Processor 线程,也研究了 Data plane 和 Control plane 针对不同类型请求的处理方案。
今天,我带你完整地梳理一下 Kafka 请求处理的全流程。这个全流程涉及到多个源码文件,为了弄懂其中的原理,我们必须在不同的方法间“跳来跳去”。比起学习单个源码文件,将多个文件中的方法组合在一起串成完整流程要难得多,因此,你最好多花一些时间,仔细研读一下跟这套流程相关的所有方法。
当然了,你可能有这样的疑问:“我为什么要关心请求被处理的流程呢?阅读这部分源码的意义是什么呢?”其实,弄明白这部分原理,非常有助于我们有针对性地调优 Broker 端请求处理的性能
举个例子,Broker 端有两个参数与这个流程相关,分别是 num.network.threads 和 num.io.threads。如果我们不掌握请求被处理的流程,是没有办法有的放矢地调整这些参数的。
要知道,Kafka 官网可没有告诉我们,什么是网络线程和 I/O 线程。如果不明白“请求是被网络线程接收并放入请求队列的”这件事,我们就很可能犯这样的错误——当请求队列快满了的时候,我们会以为是网络线程处理能力不够,进而盲目地增加 num.network.threads 值,但最终效果很可能是适得其反的。我相信,在今天的课程结束之后,你就会知道,碰到这种情况的时候,我们更应该增加的是 num.io.threads 的值。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文深入介绍了Kafka请求处理的全流程,包括KafkaRequestHandlerPool的源码分析和KafkaRequestHandler的定义及运行逻辑。文章首先强调了理解请求处理流程对于调优Broker端请求处理性能的重要性,然后重点介绍了KafkaRequestHandlerPool中的组件,包括KafkaRequestHandler、BrokerTopicMetrics等。接着对KafkaRequestHandler进行了详细解析,包括其定义和运行逻辑,以及在处理普通请求和关闭请求时的操作。通过对KafkaRequestHandler的运行逻辑进行分析,文章展现了其在处理请求时的关键步骤和流程。此外,还介绍了KafkaRequestHandlerPool线程池的实现,包括创建线程和调整线程池大小的方法。整体而言,本文通过深入的源码分析,帮助读者全面了解了Kafka请求处理的全流程,为读者深入理解Kafka的请求处理机制提供了重要参考。 文章还介绍了KafkaRequestHandlerPool线程池及其下辖的KafkaRequestHandler线程,该线程就是Kafka社区所称的I/O线程。另外,结合源代码串讲了Kafka的请求处理流程,总共分为6步:客户端或其他Broker通过Selector机制发起创建连接请求,Processor线程接收请求并转换成可处理的Request对象,将Request对象放入Request队列,KafkaRequestHandler线程处理请求并将Response放回对应Processor线程的Response队列,最后Processor线程发送Response给Request发送方。此外,下节课将重点讲解KafkaApis类,该类是查看所有Kafka源码的首要入口类,值得深入学习。 在课后讨论中,读者被邀请思考哪些部分的请求处理流程应用了经典的“生产者-消费者”模式。整体而言,本文通过深入的源码分析和清晰的步骤讲解,为读者提供了全面了解Kafka请求处理机制的重要参考。

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

全部留言(10)

  • 最新
  • 精选
  • 胡夕
    置顶
    你好,我是胡夕。我来公布上节课的“课后讨论”题答案啦~ 上节课,咱们重点了解了Kafka请求区分优先级的方案。课后,我请你思考排除多套资源之外的替代方案,比如将请求队列改造成支持优先级队列。下面我说说这个方案的特点。这个方案的好处在于源码不用做这么大的变动。多套资源的方案对源码的改动程度很大,且不说新增了一些参数,很多处理逻辑几乎原封不动地copy了一组。但这个方案的一个弊端在于它依然无法解决队列已满的场景。如果大量队列堆积在优先级队列后,新入场的控制类请求只能等待,依然无法得到快速处理。 okay,你同意这个说法吗?或者说你有其他的看法吗?我们可以一起讨论下。
    2020-05-19
    2
    4
  • 伯安知心
    1,acceptor和processor之间缓存SocketChannel队列,线程安全顺序。 2,processor和handle之间缓存阻塞队列requestChannel的request全局队列和response局部队列,

    作者回复: 👍

    2020-05-07
    2
    5
  • 曾轼麟
    从Acceptor 到 Processor newConnections 队列,从 Processor 到 KafkaRequestHandler RequestChannel队列。其实目前我在公司也有使用生成者消费者模型,使用的是 Disruptor作为队列

    作者回复: 嗯,很多思想都是相同的~

    2020-05-27
    1
  • 二进制傻瓜
    胡大您好!我们生产上用k8s云化的kafka写数据时偶尔会报“the server disconnected before a response was received”,发送时ack=1,这可能是什么原因导致的

    作者回复: 可能的原因是某个TCP通道长时间没有请求流过被单方面关闭了,之后对端再起启用时发现连接已经中断。偶发的错误没事

    2020-07-06
  • 吃饭饭
    这里不太明白:【kafka.network.Processor#run】这个方法内部执行的方法 processNewResponses() 和 processCompletedReceives() 不能调换位置吗?先调用 processCompletedReceives(), 我理解的是肯定是请求先到,才会有 Response 啊

    作者回复: 个人感觉顺序不是很重要,毕竟都是循环执行

    2020-06-17
  • LEO
    老师,kafka底层也是通过NIO进行通信,请问是如何解决 epoll空轮询bug的,这块代码我一直没找到

    作者回复: Kafka不像Netty那样有相应的处理措施,毕竟属于JDK bug,不属于Kafka操心的事情:)

    2020-05-07
    3
  • 张三丰
    是不是一个生产者只需要一个process线程?因为只有一个连接,一个连接对应一个channel,一个channel对应一个process,这个process和netty的eventloop是一个概念?
    2022-05-21
  • Z宇锤锤
    requestChannel中的请求队列。Response队列。这两个数据结构有对应的生产者和消费者。
    2022-01-23
  • ahu0605
    这个线程从哪里阻塞?requestChannel?
    2022-01-18
  • 南琛一梦
    因为之前对netty有过深入研究,因此对于请求处理模块理解起来感觉轻松很多,对于该课程的学习也渐入佳境了。继续加油!!!
    2021-12-23
收起评论
显示
设置
留言
10
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部