Kafka日志段类LogSegment源码解析

设为“星标”，好文章不错过！

1 Kafka日志结构概览

Kafka日志在磁盘上的组织架构

如上图可见，Kafka日志对象由多个日志段对象组成，而每个日志段对象会在磁盘上创建一组文件，包括不止如下：

消息日志文件（.log）位移索引文件（.index）时间戳索引文件（.timeindex）已中止（Aborted）事务的索引文件（.txnindex）

若没有使用Kafka事务，已中止事务的索引文件不会被创建。图中的一串数字0是该日志段的起始位移值（Base Offset），即该日志段中所存的第一条消息的位移值。

一般一个Kafka主题有很多分区，每个分区就对应一个Log对象，在物理磁盘上则对应一个子目录。比如创建一个双分区的主题test-topic，那么，Kafka在磁盘上会创建两个子目录：

test-topic-0test-topic-1

而在服务器端，这就是两个Log对象。每个子目录下存在多组日志段，即多组.log、.index、.timeindex文件组合，只不过文件名不同（因每个日志段的起始位移不同）

2 日志段代码解析

日志段是Kafka保存消息的最小载体。Kafka 的消息就是保存在日志段。

2.1 案例

大面积日志段同时间切分，导致瞬时打满磁盘I/O带宽。最后在LogSegment的shouldRoll方法找到解决方案：设置Broker端参数log.roll.jitter.ms值大于0，即通过给日志段切分执行时间加一个扰动值的方式，来避免大量日志段在同一时刻执行切分动作，从而显著降低磁盘I/O。

所以，阅读源码很重要。毕竟单纯查看官网对该参数的说明，不一定能够全面了解它的作用。

日志段源码位 core 工程下的LogSegment.scala

该文件下定义了三个 Scala 对象：

主要关心前两者。

2.2 日志段类解析

类综述

LogSegment 类定义

核心 API

读写日志是Kafka最常用的操作，而日志读取底层调用的就是日志段的这两个方法。

append（写消息）

重点关注一下写操作过程中更新索引的时机是如何设定的。

执行流程

step1

先判断该日志段是否为空，若为空，则Kafka需记录要写入消息集的最大时间戳，并将其作为后面新增日志段倒计时的依据。

step2

step3

step4

每个日志段都要保存当前最大时间戳和所属消息的偏移信息。

Broker 端提供有定期删除日志的功能。比如我只想保留最近 7 天日志，就是基于当前最大时间戳值。而最大时间戳对应的消息的偏移值则用于时间戳索引项。时间戳索引项保存时间戳与消息偏移的对应关系。该步骤中，Kafka更新并保存这组对应关系。

step5

read（读消息）

关注下Kafka计算待读取消息字节数的逻辑，也就是maxSize、maxPosition和startOffset是如何共同影响read方法的。

方法签名

执行流程

step1

step2

待确定了读取起始位置，日志段代码需要根据这部分信息以及 maxSize 和 maxPosition 参数共同计算要读取的总字节数。举个例子，假设 maxSize=100，maxPosition=300，startPosition=250，那么 read 方法只能读取 50 字节，因为 maxPosition - startPosition = 50。我们把它和maxSize参数相比较，其中的最小值就是最终能够读取的总字节数。

step3

recover（恢复日志段）

什么是恢复日志段？Broker 在启动时会从磁盘上加载所有日志段信息到内存中，并创建相应的 LogSegment 对象实例。是Broker重启后恢复日志段的操作逻辑。执行流程

step1

step2

step3

注意该操作在执行过程中要读取日志段文件。因此，若你的环境有很多日志段文件，你又发现Broker重启很慢，那你现在就知道了，这是因为Kafka在执行recover的过程中需要读取大量磁盘文件。

参考

https://tech.meituan.com/2015/01/13/kafka-fs-design-theory.html