Log管理机制

Kafka的消息在broker上都是以log的形式进行储存管理的，本篇主要介绍log的管理，包括log结构、创建、读写、分段、清理等。

1 前言

Kafka中的Message是以topic为基本单位组织的，不同的topic之间是相互独立的。每个partition存储一部分Message。引用官方的一张图，可以直观地看到topic和partition的关系。

2 Kakfa的日志格式

2.1Partition的数据文件

Partition中的每条Message由offset来表示它在这个partition中的偏移量，这个offset不是该Message在partition数据文件中的实际存储位置，而是逻辑上一个值，它唯一确定了partition中的一条Message。因此，可以认为offset是partition中Message的id。partition中的每条Message包含了以下三个属性：

l offset
l MessageSize
l Record
l 其中offset为long型，MessageSize为int32，表示Record中data

有多大，data为message的具体内容。

在v0版本中，kafka的消息格式如下图所示：

在V1版本中，kakfa的消息格式如下图所示：

V2版本

具体可以参考下文

http://www.uml.org.cn/bigdata/2018051731.asp

2.2 Log的分段和索引

数据文件的分段

Kafka解决查询效率的手段之一是将数据文件分段，比如有100条Message，它们的offset是从0到99。假设将数据文件分成5段，第一段为0-19，第二段为20-39，以此类推，每段放在一个单独的数据文件里面，数据文件以该段中最小的offset命名。这样在查找指定offset的Message的时候，用二分查找就可以定位到该Message在哪个段中。

为数据文件建索引

数据文件分段使得可以在一个较小的数据文件中查找对应offset的Message了，但是这依然需要顺序扫描才能找到对应offset的Message。为了进一步提高查找的效率，Kafka为每个分段后的数据文件建立了索引文件，文件名与数据文件的名字是一样的，只是文件扩展名为.index。

索引文件中包含若干个索引条目，每个条目表示数据文件中一条Message的索引。索引包含两个部分（均为4个字节的数字），分别为相对offset和position。

相对offset：因为数据文件分段以后，每个数据文件的起始offset不为0，相对offset表示这条Message相对于其所属数据文件中最小的offset的大小。举例，分段后的一个数据文件的offset是从20开始，那么offset为25的Message在index文件中的相对offset就是25-20 = 5。存储相对offset可以减小索引文件占用的空间。

position，表示该条Message在数据文件中的绝对位置。只要打开文件并移动文件指针到这个position就可以读取对应的Message了。

index文件中并没有为数据文件中的每条Message建立索引，而是采用了稀疏存储的方式，每隔一定字节的数据建立一条索引。这样避免了索引文件占用过多的空间，从而可以将索引文件保留在内存中。但缺点是没有建立索引的Message也不能一次定位到其在数据文件的位置，从而需要做一次顺序扫描，但是这次顺序扫描的范围就很小了。

2.3 log的逻辑结构

l 一个Partition Log由多个LogSegment组成
l 一个LogSegment代表了整个Partition Log中的某一段，它是由一个FileMessageSet和一个OffsetIndex组成
l FileMessageSet：顾名思义，它代表了一个基于文件的消息集合。内部采用channel方式访问物理文件。
l OffsetIndex：可以将其看做一个index table, 每一项代表了一个offset 与物理文件（.log 文件）position的映射。此外它会与实际的物理文件(.index) 之间是建立的 mmap。
l 每一个Partition Log有一个nextOffsetMetadata 记录，用于记录下一个要添加的messageset的offset
l 每一个Log都有一个recoverypoint，用于记录真正flush到磁盘的消息的最后一个offset

2.4 log的物理结构

下面是一个kafka log dir下的文件分布：

1）一个Partition Log 对应于一个kafka broker 的log dir下面的一个分区目录。

2）一个LogSegment对应了partition log directoy下的两个文件：一个.log文件，一个.index文件。

3 kafka 的日志管理

在一个broker上的log都是通过LogManger来管理的，Kafka 的日志管理（LogManager）主要的作用是负责日志的创建、检索、清理，日志相关的读写操作实际上是由日志实例对象（Log）来处理的。

3.1 LogManger启动过程

LogManager 线程是在节点的 Kafka 服务启动时启动的，相关代码如下：

初始化 LogManger 主要有两个步骤：

加载所有的日志分区，而每个日志也会加载该分区所有的 segment 文件，过程比较慢，所以 LogManager 使用线程池的方式，为每个日志的加载都会创建一个单独的线程。

虽然使用的是线程池提交任务，并发进行 load 分区日志，但这个任务本身是阻塞式的，只有当所有的分区日志加载完成，才能调用 startup() 启动 LogManager 线程。

KafkaServer 调用 startup() 方法启动 LogManager 线程，LogManager 启动后，后台会运行四个定时任务，代码实现如下：

四个后台定时线程的作用：

l cleanupLogs：定时清理过期的日志 segment，并维护日志的大小（默认5min）；
l flushDirtyLogs：定时刷新将还没有写到磁盘上日志刷新到磁盘（默认无限大）；
l checkpointRecoveryPointOffsets：定时将所有数据目录所有日志的检查点写到检查点文件中（默认 60s）；
l deleteLogs：定时删除标记为 delete 的日志文件（默认 30s）。

3.2 日志压缩

第一种：delete，即如果LogSegment到期了删除之，或者LogSegment+这次要添加的消息 > LogSegment的最大容量则删除最老的的LogSegment

第二种：compact，进行log压缩，也可以有效减少日志文件文件大小，缓解磁盘紧张情况。

在有些场景中，key和对应的value的值是不断变化的，就像数据库的记录一样，可以对同一条记录进行修改，在kafka中表现就是在某一时刻key=value1,可能在后续某一时刻，添加了一个key=value2的消息，如果消费者只关心最新的值，那么日志压缩就显得很有用，如下图所示：

l # 如果启用日志压缩，并不会针对active log segment，即active log segment不会参加日志压缩，只是针对只读的log segment，避免active log segment成为热点，既要读写还要压缩
l # 日志压缩的过程是通过多个cleaner线程来完成的，所以我们可以通过调整cleaner线程数来并发压缩性能，减少对整个服务器端的影响
l # 一般情况下，Log数据量很大，为了避免cleaner线程和其他业务线程长时间竞争CPU，并不会将active log segment之外的其他可读LogSegment在一次压缩中全部处理掉，而是将这些LogSegment分批处理
l 每一个log都会被cleanercheckpoint分成clean和dirty2部分，如下图所示：

clean: 表示已经压缩的部分，压缩之后，offset是断断续续的，不是增量递增的

dirty: 表示未压缩部分，offset依然是连续递增的

l # 每一个clean线程根据日志文件cleanableRatio值来优先压缩该值较效的log，也就说dirty占整个日志的比率越大优先级越高。
l # clean线程在选定需要清理的log后，首先为dirty部分消息建立一个<key,key对应的last offset>的映射关系，该映射通过SkimpyOffsetMap维护，然后重新复制LogSegment，只保留SkimpyOffsetMap中记录的消息，抛弃掉其他消息
l # 经过日志压缩后，日志文件和索引文件会不断减小，cleaner线程还会对相邻的LogSegmeng进行合并，避免出现过小的日志和索引文件