作者简介:大家好,我是smart哥,前中兴通讯、美团架构师,现某互联网公司CTO
联系qq:184480602,加我进群,大家一起学习,一起进步,一起对抗互联网寒冬
学习必须往深处挖,挖的越深,基础越扎实!
阶段1、深入多线程
阶段2、深入多线程设计模式
阶段3、深入juc源码解析
码哥源码部分
码哥讲源码-原理源码篇【2024年最新大厂关于线程池使用的场景题】
码哥讲源码-原理源码篇【揭秘join方法的唤醒本质上决定于jvm的底层析构函数】
码哥源码-原理源码篇【Doug Lea为什么要将成员变量赋值给局部变量后再操作?】
码哥讲源码【谁再说Spring不支持多线程事务,你给我抽他!】
打脸系列【020-3小时讲解MESI协议和volatile之间的关系,那些将x86下的验证结果当作最终结果的水货们请闭嘴】
上一章,我讲到KafkaRequestHandlerPool最终会将请求交给API层的KafkaApis处理。本章,我们就来看下KafkaApis的整体架构。
KafkaApis 类定义在源码文件 KafkaApis.scala
中:
class KafkaApis(val requestChannel: RequestChannel,
val replicaManager: ReplicaManager,
val adminManager: AdminManager,
val coordinator: GroupCoordinator,
val controller: KafkaController,
val zkUtils: ZkUtils,
val brokerId: Int,
val config: KafkaConfig,
val metadataCache: MetadataCache,
val metrics: Metrics,
val authorizer: Option[Authorizer],
val quotas: QuotaManagers,
val clusterId: String,
time: Time) extends Logging {
//...
}
它的内部封装了许多核心组件:
一、整体架构
KafkaApis 可以看成是一个门面类,是 Broker 端所有功能的入口,同时关联了超多的 Kafka 组件。如果你翻开 KafkaApis 类的代码,你会发现,它封装了很多以 handle 开头的方法。每一个这样的方法都对应于一类请求类型,而它们的总方法入口就是 handle 方法。
实际上,你完全可以在 handle 方法间不断跳转,去到任意一类请求被处理的实际代码中。
我们总结一下 KafkaApis 类的要点。
- handle 方法封装了所有 RPC 请求的具体处理逻辑。每当社区新增 RPC 协议时,增加对应的 handle×××Request 方法和 case 分支都是首要的;
- sendResponse 系列方法负责发送 Response 给请求发送方。发送 Response 的逻辑是将 Response 对象放置在 Processor 线程的 Response 队列中,然后交由 Processor 线程实现网络发送;
- authorize 方法是请求处理前权限校验层的主要逻辑实现。你可以查看一下官方文档,了解一下当前都有哪些权限,然后对照着具体的方法,找出每类 RPC 协议都要求 Clients 端具备什么权限。
二、总结
KafkaApis的整体结构是非常清晰的,本章我就不过多展开了,读者完全可以自己打开KafkaApis.scala的源码去看下它的具体功能。