面试官:你对Kafka比较熟? 那说说kafka日志段如何读写的吧?

开发 开发工具 Kafka
之所以写这篇文章是因为之前面试时候被面试官问到(倒)了,面试官说:“你说你对Kafka比较熟?看过源码? 那说说kafka日志段如何读写的吧?”

 [[332223]]

之所以写这篇文章是因为之前面试时候被面试官问到(倒)了,面试官说:“你说你对Kafka比较熟?看过源码? 那说说kafka日志段如何读写的吧?”

我心里默默的说了句 “擦…我说看过一点点源码,不是亿点点。早知道不提这句了!”,那怎么办呢,只能回家等通知了啊。

 

但是为了以后找回场子,咱也不能坐以待毙,日拱一卒从一点点到亿点点。今天我们就来看看源码层面来Kafka日志段的是如何读写的。

Kafka的存储结构

总所周知,Kafka的Topic可以有多个分区,分区其实就是最小的读取和存储结构,即Consumer看似订阅的是Topic,实则是从Topic下的某个分区获得消息,Producer也是发送消息也是如此。

 

topic-partition关系

上图是总体逻辑上的关系,映射到实际代码中在磁盘上的关系则是如下图所示:

 

每个分区对应一个Log对象,在磁盘中就是一个子目录,子目录下面会有多组日志段即多Log Segment,每组日志段包含:消息日志文件(以log结尾)、位移索引文件(以index结尾)、时间戳索引文件(以timeindex结尾)。其实还有其它后缀的文件,例如.txnindex、.deleted等等。篇幅有限,暂不提起。

以下为日志的定义

 

以下为日志段的定义

 

indexIntervalBytes可以理解为插了多少消息之后再建一个索引,由此可以看出Kafka的索引其实是稀疏索引,这样可以避免索引文件占用过多的内存,从而可以在内存中保存更多的索引。对应的就是Broker 端参数log.index.interval.bytes 值,默认4KB。

实际的通过索引查找消息过程是先通过offset找到索引所在的文件,然后通过二分法找到离目标最近的索引,再顺序遍历消息文件找到目标文件。这波操作时间复杂度为O(log2n)+O(m),n是索引文件里索引的个数,m为稀疏程度。

这就是空间和时间的互换,又经过数据结构与算法的平衡,妙啊!

再说下rollJitterMs,这其实是个扰动值,对应的参数是log.roll.jitter.ms,这其实就要说到日志段的切分了,log.segment.bytes,这个参数控制着日志段文件的大小,默认是1G,即当文件存储超过1G之后就新起一个文件写入。这是以大小为维度的,还有一个参数是log.segment.ms,以时间为维度切分。

那配置了这个参数之后如果有很多很多分区,然后因为这个参数是全局的,因此同一时刻需要做很多文件的切分,这磁盘IO就顶不住了啊,因此需要设置个rollJitterMs,来岔开它们。

怎么样有没有联想到redis缓存的过期时间?过期时间加个随机数,防止同一时刻大量缓存过期导致缓存击穿数据库。看看知识都是通的啊!

日志段的写入

 

1、判断下当前日志段是否为空,空的话记录下时间,来作为之后日志段的切分依据

2、确保位移值合法,最终调用的是AbstractIndex.toRelative(..)方法,即使判断offset是否小于0,是否大于int最大值。

3、append消息,实际上就是通过FileChannel将消息写入,当然只是写入内存中及页缓存,是否刷盘看配置。

4、更新日志段最大时间戳和最大时间戳对应的位移值。这个时间戳其实用来作为定期删除日志的依据

5、更新索引项,如果需要的话(bytesSinceLastIndexEntry > indexIntervalBytes)

最后再来个流程图

 

消息写入流程

日志段的读取

 

1、根据第一条消息的offset,通过OffsetIndex找到对应的消息所在的物理位置和大小。

2、获取LogOffsetMetadata,元数据包含消息的offset、消息所在segment的起始offset和物理位置

3、判断minOneMessage是否为true,若是则调整为必定返回一条消息大小,其实就是在单条消息大于maxSize的情况下得以返回,防止消费者饿死

4、再计算最大的fetchSize,即(最大物理位移-此消息起始物理位移)和adjustedMaxSize的最小值(这波我不是很懂,因为以上一波操作adjustedMaxSize已经最小为一条消息的大小了)

5、调用 FileRecords 的 slice 方法从指定位置读取指定大小的消息集合,并且构造FetchDataInfo返回

再来个流程图:

 

消息读取流程

小结

从哪里跌倒就从哪里爬起来对吧,这波操作下来咱也不怕下次遇到面试官问了。

区区源码不过尔尔,哈哈哈哈(首先得要有气势)

实际上这只是Kafka源码的冰山一角,长路漫漫。虽说Kafka Broker都是由Scala写的,不过语言不是问题,这不看下来也没什么难点,注释也很丰富。遇到不知道的语法小查一下搞定。

所以强烈建议大家入手源码,从源码上理解。今天说的 append 和 read 是很核心的功能,但一看也并不复杂,所以不要被源码这两个字吓到了。

看源码可以让我们深入的理解内部的设计原理,精进我们的代码功力(经常看着看着,我擦还能这么写)。当然还有系统架构能力。

然后对我而言最重要的是可以装逼了(哈哈哈)。

情景剧

老白正目不转睛盯着监控大屏,“为什么?为什么Kafka Broker物理磁盘 I/O 负载突然这么高?”。寥寥无几的秀发矗立在老白的头上,显得如此的无助。

“是不是设置了 log.segment.ms参数 ?试试 log.roll.jitter.ms吧”,老白抬头间我已走出了办公室,留下了一个伟岸的背影和一颗锃亮的光头!

“我变秃了,也变强了”

责任编辑:武晓燕 来源: 51CTO专栏
相关推荐

2021-08-09 07:47:40

Git面试版本

2021-11-25 10:18:42

RESTfulJava互联网

2020-12-01 08:47:36

Java异常开发

2020-06-12 15:50:56

options前端服务器

2022-03-21 09:05:18

volatileCPUJava

2021-11-02 22:04:58

模式

2024-08-12 17:36:54

2021-09-29 07:24:20

场景数据

2021-09-16 07:52:18

算法应用场景

2021-09-28 07:12:09

测试路径

2023-12-19 09:24:22

LinuxBIOSUEFI

2019-05-10 10:50:04

Spring AOPJDK动态代理CGLIB动态代理

2021-10-09 10:25:41

排序应用场景

2021-11-09 14:08:45

DockerDockerfileJava

2021-12-13 11:54:13

SetEs6接口

2021-11-10 07:47:49

组合模式场景

2022-02-21 17:24:18

序列化对象存储

2021-08-16 08:33:26

git

2021-11-03 14:10:28

工厂模式场景

2021-10-08 09:59:32

冒泡排序场景
点赞
收藏

51CTO技术栈公众号