Kafka核心源码解读
胡夕
Apache Kafka Committer,老虎证券技术总监
新⼈⾸单¥19.9
3969 人已学习
课程目录
已完结 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
登录|注册

29 | GroupMetadataManager:组元数据管理器是个什么东西?

胡夕 2020-07-04
你好,我是胡夕。今天,我们学习 GroupMetadataManager 类的源码。从名字上来看,它是组元数据管理器,但是,从它提供的功能来看,我更愿意将它称作消费者组管理器,因为它定义的方法,提供的都是添加消费者组、移除组、查询组这样组级别的基础功能。
不过,这个类的知名度不像 KafkaController、GroupCoordinator 那么高,你之前可能都没有听说过它。但是,它其实是非常重要的消费者组管理类。
GroupMetadataManager 类是在消费者组 Coordinator 组件被创建时被实例化的。这就是说,每个 Broker 在启动过程中,都会创建并维持一个 GroupMetadataManager 实例,以实现对该 Broker 负责的消费者组进行管理。更重要的是,生产环境输出日志中的与消费者组相关的大多数信息,都和它息息相关。
我举一个简单的例子。你应该见过这样的日志输出:
Removed ××× expired offsets in ××× milliseconds.
这条日志每 10 分钟打印一次。你有没有想过,它为什么要这么操作呢?其实,这是由 GroupMetadataManager 类创建的定时任务引发的。如果你不清楚 GroupMetadataManager 的原理,虽然暂时不会影响你使用,但是,一旦你在实际环境中看到了有关消费者组的错误日志,仅凭日志输出,你是无法定位错误原因的。要解决这个问题,就只有一个办法:通过阅读源码,彻底搞懂底层实现原理,做到以不变应万变
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《Kafka核心源码解读》,如需阅读全部文章,
请订阅文章所属专栏新⼈⾸单¥19.9
立即订阅
登录 后留言

精选留言(3)

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

    上节课,我们重点学习了Kafka如何管理消费者组元数据。课后我请你思考Kafka是怎么确认消费者组使用哪个成员的超时时间作为整个组的超时时间。实际上,Kafka取消费者组下所有成员的最大超时时间作为整个组的超时时间。具体代码可以看下GroupMetadata的rebalanceTimeoutMs方法。

    okay,你同意这个说法吗?或者说你有其他的看法吗?我们可以一起讨论下。
    2020-07-07
  • 伯安知心
    从代码看,删除消费组的位移方法是removeGroupsForPartition,只有在处理身份或者位移变动调用handleGroupEmigration,请求这个方法的有2个调用。第一个方法handleLeaderAndIsrRequest判断就是新选择的broker重启太快导致leaderandisr请求变化,收到之前的请求也需要清理组的缓存记录,并且变动的topic是GROUP_METADATA_TOPIC_NAME的就需要删除消费组位移记录,第二个 方法handleStopReplicaRequest判断就是新选择的broker重启太快收到之前的请求也需要清理组的缓存记录。总之就是GROUP_METADATA_TOPIC_NAME变化在handleStopReplicaRequest请求和handleLeaderAndIsrRequest请求中就会有清除消费组位移记录的变化。
    2020-07-06
  • 刘飞
    胡大您好!单个kafka集群broker数,topic数以及partition数是否有上限?broker数或者topic 数以及partition太多会不会影响kafka的性能?这方面是否有最佳实践?

    作者回复: 最佳实践是单台broker上分区数最好不超过2000

    2020-07-05
    1
收起评论
3
返回
顶部