Kafka日志清理

前言

Kafka将消息存储在磁盘中，为了控制磁盘占用空间。kafka中每个分区副本都对应一个Log，而Log对应多个日志分段，这样有利日志清理操作。Kafka提供两种日志清理策略：

• 日志删除（Log retention）：按一定的保留的策略直接删除不符条件的日志分段；
• 日志压缩（Log compation）：针对每个消息的Key对行整合，对于相同Key的不同value值，只保留最后一个版本；

Broker端参数log.cleanup.policy来设置日志清理策略，此参数默认为delete，也可以设置成compact，还可以设置成delete,compact；

日志删除

Kafka日志管理器中会有一个专门的日志删除任务来周期性检测和删除不符合保留条件的日志分段文件，在Broker端参数：log.retention.check.interval.ms默认值：3000，当前日志分段有三种保留策略：基于时间、日志大小和起始偏移量。

基于时间策略

日志删除任务会检查当前日志文件中是否有保留时间超过设定的阈值来删除日志分段文件集合。

Broker端log.retention.hours（168小时） < log.retention.minutes < log.retention.ms来配置；

查找过期的日志分段文件，并不是简单地根据日志分段的最近修改时间lastModifiedTime来计算的，而是根据日志中分段中的最大的时间戳largestTimeStamp来计算的。

删除日志分段时，首先会从Log对象中所维护日志分段的跳跃表中移除待删除的日志分段，以保证没有纯种对这些日志分段进行读取操作；然后将日志分段所对应的文件添上".deleted"的后缀，最后交由一个以"delete-file"命名的延迟任务来删除这些以".deleted"为后缀的文件，这个延迟任务通过file.delete.delay.ms参数来调配，默认值60000（一分钟）。

基于日志大小策略

日志删除任务会检查当前日志大小是否超过阈值来寻找可删除的日志分段文件集合，可以通过Broker端参数log.retention.bytes来配置，默认值为1G 。

首先计算日志文件的总大小size和retention的差值diff，然后从日志文件中的第一个日志分段开始进行查找可删除的日志分段的文件集合deletableSegments，查出之前就执行删除操作，这个删除操作跟基于时间的一样。 

基于起始偏量策略

一般情况下，日志文件的起始偏移量logStartOffset等于第一个日志分段的baseOffset； 

日志压缩

log Compaction对于有相同Key的不同value值，只保留最后一个版本。

每个日志目录下有个"cleaner-offset-checkpoint" 的文件，这个文件就是清理检查点文件，用来记录每个分区中已清理的偏移量。

待完成