KAFKA日志存储、日志清理

1. 日志存储

kafka的消息是以topic为单位进行归类的，各个topic之间互相独立，互不影响。每个主题拥有分为一个或者多个partition（分区），每个 partition 对应于一个 log 文 件，该 log 文件中存储的就是 producer 生产的数据。Producer 生产的数据会被不断追加到该 log 文件末端，且每条数据都有自己的 offset

 

 上图中，topic主题共有三个分区，每个分区存在一个以topic-partition命名的目录，目录下的文件结构如下表

文件类别	作用
.index	消息的物理地址的偏移量索引文件
.timeindex	映射时间戳和相对offset
.log	日志文件(消息存储文件)
.snapshot	对幂等型或者事务性producer所生成的快照文件
leader-epoch-checkpoint	保存了每一任leader开始写入消息时的offset,会定时更新

 

kafk日志追加是顺序写入的，.index 和 .log 文件以当前 segment 的第一条消息的偏移量命名,偏移量是一个64位的长整型数值，固定是20位数字，长度未达到，用0进行填补。

 

1.1. index文件

index文件和timeindex文件是一一对应的，index中的索引条数，由参数log.segment.bytes和log.index.interval.bytes共同决定。

kafka的index采用的是稀疏索引，索引文件大小默认为10M，由参数log.index.size.max.bytes控制，Kafka在创建索引文件的时候会为其预分配log.index.size.max.bytes大小的空间，注意这一点与日志分段文件不同，只有当索引文件进行切分的时候，Kafka才会把该索引文件裁剪到实际的数据大小。也就是说，与当前活跃的日志分段对应的索引文件的大小固定为log.index.size.max.bytes，而其余日志分段对应的索引文件的大小为实际的占用空间。

配置项	作用	默认值
log.index.size.max.bytes	index文件最大大小
log.segment.bytes	分段日志文件大小	默认1G
log.index.interval.bytes	索引间隔	默认4K

查看.index文件命令：

kafka-dump-log.sh --files ./00000000000000000000.index

index文件中的内容如下：

 

offset与position都是维护的对应片段文件的offset以及position，这里采取的是稀疏存储也就是选取一些消息的offset以及position进行存储，因为如果把对应片段的所有消息的索引都存储，那么必然会占用大量的内存。

如果要查找offset为4031802的消息，首先会通过二分找到对应的segment，然后去对应的index文件通过二分找到不大于4031802的最大索引项，也就是[offset: 4031789 position: 16906]，之后进行顺序扫描。即先通过二分法在.index文件找到offset为4031789 的那条，再从log文件中的物理偏移量为12605的位置开始顺序查找偏移量为4031802的消息

 

1.2. timeindex文件

查看.timeindex文件命令

kafka-dump-log.sh --files ./00000000000000000000.timeindex

timeindex文件中的内容如下

如果要查找timstamp为1663899378988开始的消息，首先将时间戳和每个log文件中最大的时间戳largestTimeStamp进行逐一对比，直到找到不小于1663899378988所对应的segment。找到log文件后，使用二分法定位，找到不大于1663899378988的最大索引项，也就是[timestamp: 1663899378338 offset: 4031789]，拿着偏移量是4031789的offset值去偏移量索引文件找到不大于4031789的最大索引项，也就是[offset: 4031789 position: 16906]，之后从偏移量为16906的位置开始顺序查找，找到timestamp不小于1663899378988的消息。

 

1.3. log文件

查看log文件命令：

bin/kafka-run-class.sh kafka.tools.DumpLogSegments --files ./00000000000000000000.log --print-data-log

log文件内容如下：

 

	含义
offset	表示该分区的记录偏移量，指的是第几条记录
position	表示该记录在当前片段文件的文件偏移量
CreateTime	记录创建的时间
isValid	记录是否有效
keysize	表示key的长度
valuesize	表示value的长度
magic	表示本次发布kafka服务程序协议的版本号
compresscodec	压缩工具
sequence	消息的序列号
payload	表示具体的消息

 

1.4. leader-epoch-checpoint文件

leader-epoch-checkpoint文件的内容如下：

0 #版本号
7                #下面的记录数
1 0              #[epoch  offset]
4 581611         #[epoch  offset]
5 581726         #[epoch  offset]
6 581975         #[epoch  offset]
7 1616781        #[epoch  offset]
8 1616782        #[epoch  offset]
10 4031620       #[epoch  offset]

说明：

epoch表示leader的版本号，从0开始，leader每变更一次epoch就会加1

offset表示对应该epoch版本的leader写入第一条消息的offset

 

2.日志清理

kafka提供了两种清理策略：日志删除和日志压缩，可以通过参数log.cleaner.policy进行配置，参数可选[compact,delete]，默认值是delete

 

2.1.日志删除[delete]

按照一定的策略，将不满足条件的日志分段文件进行删除。日志删除的配置如下：

配置	默认值	说明
log.retension.check.interval.ms	300000(毫秒)	日志清理器检查日志是否符合删除条件的频率(毫秒)
log.retension.bytes	-1	保留日志文件的最大值
log.segment.bytes	1073741824	单个日志文件的最大大小
log.retention.hours	168(小时)	日志保留时间(小时)
log.retention.minutes		日志保留时间(分组)
log.retention.ms		日志保留时间(毫秒)
file.delete.delay.ms	60000(毫秒)	从磁盘中删除的延迟时间(毫秒)

 

若待删除的日志分段的总数等于该日志文件中所有的日志分段的数量，那么说明所有的日志分段都已过期，但是该日志文件中还要有一个日志分段来用于接收消息的写入，即必须要保证有一个活跃的日志分段文件activeSegment,在此种情况下，会先切分出一个新的日志分段作为activeSegment,然后再执行删除操作。

 

2.2.日志压缩[compact]

属于细粒度的压缩，以key为粒度的清理。针对每个消息的key进行整合，对于有相同key的不同的value值，只保留最后一个版本。也支持对单个的topic进行配置清理策略，参数cleaner.policy，压缩策略通过compression.type进行指定，可选值为['none', 'gzip', 'snappy', 'lz4', 'zstd']。

 

2.2.1效果

根据key只保留最新的value,如果value为null,该key一段时间后会被清理

 

2.2.2选择合适的文件

根据日志污浊率限定清理范围

log.cleaner.min.cleanable.ratio（默认值为0.5）

dirtyRatio=dirtyBytes/(cleanBytes + dirtyBytes)

日志污浊率=dirty部分的日志占用大小/(clean部分的日志占用大小+dirty部分日志占用大小)

 

2.2.3流程

• 压缩过程中将需要保留的消息拷贝到一个.clean为后缀的临时文件中(xxxx.log.clean)
• 压缩后将.clean文件修改为.swap文件(xxxx.log.clean->xxxx.log.swap)
• 删除原有log文件，将.swap后缀删除(xxxx.log.swap->xxxx.log)

这里只以log为例，压缩方式是针对整个segment（.index，.timeindex，.log）

 

2.2.4重新分组

因为压缩后的各个segment都会变小，需要重新分组来写log和index

将多个小的文件进行合并（log大小之和为1G，index文件之和为10m（默认情况））