kafka日志文件体系梳理

一些必须提前知道的概念

patition

kafka日志文件是以patition在物理存储上分割的

是topic物理上的分组，一个topic可以分为多个partition，每个partition是一个有序的队列

是以文件夹的形式存储在具体Broker本机上

LEO

表示每个partition的log最后一条Message的位置

HW（HighWatermark）

表示partition各个replicas（用于分布式存储的副本分片）数据间同步且一致的offset位置，即表示all replicas已经commit的位置

HW之前的数据才是Commit后的，对消费者才可见

 

 

Segment

每个partition又由多个segment file组成

我们说的kafka日志文件就是说的segment，下面我们主要讨论一下segment文件的结构

 

Segment

日志目录以及文件组成

每个partition又由多个segment file组成

segment file 由2种文件组成组成，分别为index file（索引文件）和log file（日志文件）

 

日志文件的文件后缀为 *.log

索引文件的文件后缀为 *.index、*.timeindex

 

命名规则：partition的第一个segment从0开始，后续每个segment文件名为上一个segment文件最后一条消息的offset+1 （offset后文会提到）

 

下图能比较清晰的反应出来partition、segment、和文件的关系，以及在分布式系统中是如何体现的

 

从微观即一个partition看：

消息主题是ZXP-TEST

此消息有3个partition（创建主题时指定），每个partition会有一个自己的目录

每个partion的目录下都会有segment文件，比如第一个segment文件由三个文件组成：00000000000000000000.log、00000000000000000000.index、00000000000000000000.timeindex

三个文件的作用如上图，其中当log文件达到最大值，会新生成一套segment文件，文件都是追加写，所以写性能会比较高

我们再来从宏观即3台broker看：

broker1中partion ZXP-TEST-0是leader
broker1中partion ZXP-TEST-1是follower
broker1中partion ZXP-TEST-2是follower

那么ZXP-TEST-0对应的follower在broker2、broker3（副本数由启动参数offsets.topic.replication.factor决定）

ZXP-TEST-1对应的leader在broker2

注意：同一台broker中不能存放同一个partition的主从分片，这点很多分布式系统都有此设计

 

offset与position

offset偏移量：代表第几个消息

position位置：代表消息在磁盘的物理位置

其中日志文件命名中的偏移量是offset不是position，否则无法根据offset轻松找到在哪个日志文件中

 

 

日志文件内部数据结构

日志索引文件

由offset、position组成

bin/kafka-run-class.sh kafka.tools.DumpLogSegments --files 00000000000000000000.index
# 也能印证日志文件命名中的偏移量是offset不是position
offset:5083  position:1072592768 

索引文件是有序的，可以快速根据offset寻找position，position可以快速从log文件定位消息体

时间索引文件

 由timestamp、offset组成

bin/kafka-run-class.sh kafka.tools.DumpLogSegments --files 00000000000000000000.timeindex
timestamp: 1603703296169 offset: 5083

时间索引文件也是有序的

日志文件

组成如下

X byte size	描述
8	POSITION
4	消息大小
4	CRC32 校验值
1	magic kafka服务程序协议版本号
1	attributes 独立版本或均表示压缩类型、编码类型
4	ley lenght key的长度，-1时key不存在
M	key key的内容，可选
4	payload length 消息体的长度
N	payload 消息数据

 

bin/kafka-run-class.sh kafka.tools.DumpLogSegments --files 00000000000000000000.log
baseoffset:5083  position: 1072592768  CreateTime: 1603703296169

 

 如何通过索引定位消息

 

找offset为7的消息

1、首先是用二分查找确定它是在哪个LogSegment中，自然是在第一个Segment中（日志文件命名中的偏移量是offset不是position）

2、打开这个Segment的index文件，也是用二分查找找到offset小于或者等于指定offset的索引条目中最大的那个offset。自然offset为6的那个索引是我们要找的，通过索引文件我们知道offset为6的Message在数据文件中的位置为9807。（Kafka 中的索引文件，以稀疏索引(sparse index)的方式构造消息的索引，它并不保证每个消息在索引文件中都有对应的索引项）

3、打开数据文件，从位置为9807的那个地方开始顺序扫描直到找到offset为7的那条Message（找到第6个消息后根据position+消息大小向后找直到找到）

 

与rocketMQ的对比

	rocketmq	kafka
消费的offset记录	第几个消息，保存于offsetTable.offset json文件	第几个消息，保存于__consumer_offsets内置主题中
索引文件	ConsumeQueue、（数组、下标就是offset，每行的offset其实是position） indexFile	index文件、（追加的，每条定长，offset、position） timeindex
日志文件	CommitLog（未具体研究，应该差不多）	log文件结构见上文

 

关于rocketmq的日志存储可以参考我的另一篇文章《快速弄明白RocketMQ的CommitLog、ConsumeQueue、indexFile、offsetTable 以及多种偏移量对比》

 

 

日志文件清理

Kafka将数据持久化到了硬盘上，为了控制磁盘容量，需要对过去的消息进行清理（segment文件）

清理策略

1、内部有个定时任务检测删除日志，默认是5分钟 log.retention.check.interval.ms

2、支持配置策略对数据清理

3、根据segment单位进行定期清理

log.cleaner.enable=true
log.cleaner.threads = 2 (清理线程数配置)
log.cleanup.policy=delete

#清理超过指定时间的消息,默认是168小时，7天，
#还有log.retention.ms, log.retention.minutes, log.retention.hours，优先级高到低
log.retention.hours=168​
#超过指定大小后，删除旧的消息，下面是1G的字节数，-1就是没限制
log.retention.bytes=1073741824

　　

基于【时间删除】 日志说明

每个日志段文件都维护一个最大时间戳字段，每次日志段写入新的消息时，都会更新该字段

一个日志段segment写满了被切分之后，就不再接收任何新的消息，最大时间戳字段的值也将保持不变

kafka通过将当前时间与该最大时间戳字段进行比较，从而来判定是否过期

基于【大小超过阈值】 删除日志 说明

假设日志段大小是500MB，当前分区共有4个日志段文件，大小分别是500MB，500MB，500MB和10MB

10MB那个文件就是active日志段。

此时该分区总的日志大小是3*500MB+10MB=1500MB+10MB

如果阈值设置为1500MB，那么超出阈值的部分就是10MB，小于日志段大小500MB，故Kafka不会执行任何删除操作，即使总大小已经超过了阈值；

如果阈值设置为1000MB，那么超过阈值的部分就是500MB+10MB > 500MB，此时Kafka会删除最老的那个日志段文件

注意：超过阈值的部分必须要大于一个日志段的大小才会删除

 

删除日志时不考虑，是不是还有未消费的数据，对于一个topic随时也有可能增加新的消费者