Kafka核心源码解读
胡夕
Apache Kafka Committer,老虎证券技术总监
立即订阅
3904 人已学习
课程目录
已完结 44 讲
0/4登录后,你可以任选4讲全文学习。
课前必学 (3讲)
开篇词 | 阅读源码,逐渐成了职业进阶道路上的“必选项”
免费
导读 | 构建Kafka工程和源码阅读环境、Scala语言热身
重磅加餐 | 带你快速入门Scala语言
日志模块 (5讲)
01 | 日志段:保存消息文件的对象是怎么实现的?
02 | 日志(上):日志究竟是如何加载日志段的?
03 | 日志(下):彻底搞懂Log对象的常见操作
04 | 索引(上):改进的二分查找算法在Kafka索引的应用
05 | 索引(下):位移索引和时间戳索引的区别是什么?
请求处理模块 (5讲)
06 | 请求通道:如何实现Kafka请求队列?
07 | SocketServer(上):Kafka到底是怎么应用NIO实现网络通信的?
08 | SocketServer(中):请求还要区分优先级?
09 | SocketServer(下):请求处理全流程源码分析
10 | KafkaApis:Kafka最重要的源码入口,没有之一
Controller模块 (5讲)
11 | Controller元数据:Controller都保存有哪些东西?有几种状态?
12 | ControllerChannelManager:Controller如何管理请求发送?
13 | ControllerEventManager:变身单线程后的Controller如何处理事件?
14 | Controller选举是怎么实现的?
15 | 如何理解Controller在Kafka集群中的作用?
状态机模块 (3讲)
16 | TopicDeletionManager: Topic是怎么被删除的?
17 | ReplicaStateMachine:揭秘副本状态机实现原理
18 | PartitionStateMachine:分区状态转换如何实现?
延迟操作模块 (2讲)
19 | TimingWheel:探究Kafka定时器背后的高效时间轮算法
20 | DelayedOperation:Broker是怎么延时处理请求的?
副本管理模块 (6讲)
21 | AbstractFetcherThread:拉取消息分几步?
22 | ReplicaFetcherThread:Follower拉取Leader消息是如何实现的?
23 | ReplicaManager(上):必须要掌握的副本管理类定义和核心字段
24 | ReplicaManager(中):副本管理器是如何读写副本的?
25 | ReplicaManager(下):副本管理器是如何管理副本的?
26 | MetadataCache:Broker是怎么异步更新元数据缓存的?
消费者组管理模块 (7讲)
27 | 消费者组元数据(上):消费者组都有哪些元数据?
28 | 消费者组元数据(下):Kafka如何管理这些元数据?
29 | GroupMetadataManager:组元数据管理器是个什么东西?
30 | GroupMetadataManager:位移主题保存的只是位移吗?
31 | GroupMetadataManager:查询位移时,不用读取位移主题?
32 | GroupCoordinator:在Rebalance中,Coordinator如何处理成员入组?
33 | GroupCoordinator:在Rebalance中,如何进行组同步?
特别放送 (5讲)
特别放送(一)| 经典的Kafka学习资料有哪些?
特别放送(二)| 一篇文章带你了解参与开源社区的全部流程
特别放送(三)| 我是怎么度过日常一天的?
特别放送(四)| 20道经典的Kafka面试题详解
特别放送(五) | Kafka 社区的重磅功能:移除 ZooKeeper 依赖
期中、期末测试 (2讲)
期中测试 | 这些源码知识,你都掌握了吗?
期末测试 | 一套习题,测试你的掌握程度
结束语 (1讲)
结束语 | 源码学习,我们才刚上路呢
Kafka核心源码解读
15
15
1.0x
00:00/00:00
登录|注册

26 | MetadataCache:Broker是怎么异步更新元数据缓存的?

胡夕 2020-06-25
你好,我是胡夕。今天,我们学习 Broker 上的元数据缓存(MetadataCache)。
你肯定很好奇,前面我们不是学过 Controller 端的元数据缓存了吗?这里的元数据缓存又是啥呢?其实,这里的 MetadataCache 是指 Broker 上的元数据缓存,这些数据是 Controller 通过 UpdateMetadataRequest 请求发送给 Broker 的。换句话说,Controller 实现了一个异步更新机制,能够将最新的集群信息广播给所有 Broker。
那么,为什么每台 Broker 上都要保存这份相同的数据呢?这里有两个原因。
第一个,也是最重要的原因,就是保存了这部分数据,Broker 就能够及时响应客户端发送的元数据请求,也就是处理 Metadata 请求。Metadata 请求是为数不多的能够被集群任意 Broker 处理的请求类型之一,也就是说,客户端程序能够随意地向任何一个 Broker 发送 Metadata 请求,去获取集群的元数据信息,这完全得益于 MetadataCache 的存在。
第二个原因是,Kafka 的一些重要组件会用到这部分数据。比如副本管理器会使用它来获取 Broker 的节点信息,事务管理器会使用它来获取分区 Leader 副本的信息,等等。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《Kafka核心源码解读》,如需阅读全部文章,
请订阅文章所属专栏新⼈⾸单¥19.9
立即订阅
登录 后留言

精选留言(2)

  • 胡夕 置顶
    你好,我是胡夕。我来公布上节课的“课后讨论”题答案啦~

    上节课,我们重点学习了副本管理器是管理副本的。课后我请你去研究下maybePropagateIsrChanges源码中isrChangeSet字段在哪里被更新的。实际上,该字段被更新的时机有两个:ISR扩容和ISR收缩时。

    ReplicaManager启动时会创建一个异步线程isr-expiration,定期去查看是否需要为集群中所有online分区执行ISR收缩。一旦成功执行了收缩,那么代码就会调用ReplicaManager.recordIsrChange方法将相应分区加入到isrChangeSet中。

    Follower副本从Leader副本拉取消息后会尝试将自己加入到ISR中,此时可能执行ISR扩容操作。代码同样会调用ReplicaManager.recordIsrChange方法将相应分区加入到isrChangeSet中。

    okay,你同意这个说法吗?或者说你有其他的看法吗?我们可以一起讨论下。
    2020-06-29
  • 伯安知心
    Controller要更新metadataCache缓存,肯定通过远程调用事件,也就是之前讲解controller中controllerChannelManager发送请求,严格来说就是ControllerBrokerRequestBatch定义了updateMetadataRequestBrokerSet和updateMetadataRequestPartitionInfoMap两个集合,在controller中通过分区状态机和副本状态机注册ControllerBrokerRequestBatch类,通过controllerChannelManager.sendRequest更新metadatacache请求。有些乱,请作者原谅~

    作者回复: 嗯,没问题的,哈哈哈:)

    2020-06-26
收起评论
2
返回
顶部