当前位置：首页 > news >正文

Kafka 日志存储 — 文件目录及日志格式

news 2025/7/27 21:27:28

日志存储机制是Kafka实现高吞吐量和持久化能力的关键。

1 文件目录布局

图主题与日志文件的关系

Kafka中的消息持久化为日志文件。一个副本对应一个日志。日志文件在broker上是命名形式为<topic>-<partition>的文件夹。例如，主题par3第3分区在某个副本日志在broker上的文件夹名为par3-3。

为了防止Log过大，将其切分为多个LogSegment(日志分段)，以便于消息的维护和清理。每个LogSegment对应磁盘的一个日志文件和两个索引文件，以及可能的其他文件（例如.txnindex 事务索引文件）。

向Log中追加消息是顺序写入的，只有最后一个LogSegment（activeSegment,当前活跃的日志分段）才能执行写入操作。

每个LogSegment 都有一个基准偏移量baseOffset，表示当前LogSegment中第一条消息的offset。日志及两个索引文件都是根据baseOffset命名的，名称固定为20为数字（64位的长整型数）。

图某时刻par1主题的0分区所在的broker的目录下的文件

Kafka的消息格式经历了3个版本：v0、v1、v2。

图 v0版本的消息结构

Offset:消息在分区中的偏移量。

message size: 消息的大小。

crc32: crc32 校验值，检验范围位magic至value之间。

magic: 消息格式版本号，值为0。

attributes：消息属性，低3位表示压缩类型，其余位保留。

key lenght: 消息的key长度。如果为-1，表示key=null。

key：可选

value lenght：实际消息体的长度，如果为-1，表示value=null。

value：消息体，可以为空，为空时可以用来表示墓碑（tombstone）消息。

Offset与message size 一起被称为日志头部（LOG_OVERHEAD）。一条或多条消息组成消息集，消息集是消息存储于磁盘及在网络上传输的基本形式，还是Kafka压缩的基本单位。

图 v1版本的消息结构

v1 比v0 多添加了个字段timestamp，用于表示消息的时间戳。

attributes字段的第4位用于表示这个时间戳的类型，0 表示CreateTime 生产者创建消息时的时间戳、1 表示 LogAppendTime 消息添加到日志时的时间戳。默认值为0，可由broker端的log.message.timestamp.type 来配置。

与前面两个版本最大的不同是，消息字段大量采用了Varints(变长字段)。

Varints 是使用一个或多个字节来序列化整数的一种方法。数值越小，其占用的字节数越少。每个字节都有一个位于最高位的msb位，除最后一个字节外，其余msb位都设置为1。表示其后的字节是否和当前字节一起来表示同一个整数。

Varints中采用的是小端字节序。

小端字节序：用于表示多字节数据的一种字节顺序的方式。低位在前，高位在后。即从右到左来阅读数字，而大端字节序，是高位在前，低位在后，从左到右来阅读数字。

例如int类型（4个字节，32位）的数字16。大端字节序表示为：00000000 00000000 00000000 00010000，小端字节序表示为00010000 00000000 00000000 00000000。

小端字节序在处理少字节格外高效。

图 v2版本的消息结构

v2版本中消息集称为Record Batch 而不是先前的Message Set。在消息压缩的情形下，Record Batch Header 部分（从first offset 到records count）是不被压缩的，而records字段中的所有消息会被压缩。

first offset	当前RecordBatch 的起始位移。
length	从partition leaderepoch字段开始到末尾的长度。
partition leader epoch	分区leader纪元（版本号或更新次数）
attributes	消息属性，低3位表示压缩格式，第4位表示时间戳类型；第5位表示此RecordBatch是否处于事务中，第6位表示是否是控制消息。
first timestamp	RecordBatch中第一条Record的时间戳。