管理メカニズムをログに記録

カフカメッセージブローカは、この部分は、セグメント、洗浄などを作成、読み取り、構成ログを含むログ管理を記述するログ・ストレージ管理の形で行われます。

1はじめに

カフカは、異なるトピックの間の組織の基本単位であるが、互いに独立しているメッセージの話題です。各パーティションメッセージの部分を記憶します。公式には、我々は視覚的に話題とパーティションの関係を見ることができ、マップを引用しました。

2 Kakfaログ形式

2.1Partitionデータファイル

各メッセージのパーティションは、そのパーティションのオフセットは、オフセット位置が実際のメッセージ・パーティション・データ・ファイルに格納されていないが、一意のパーティションを識別する論理値のオフセットで表されますメッセージ。したがって、仕切りは、IDのメッセージをオフセットすることが考えられます。メッセージ内の各パーティションには、次の3つのプロパティが含まれています。

リットルオフセット
MESSAGESIZE
録音
ここで、Lオフセット型長い、MESSAGESIZEは、記録を示すデータであるINT32

どのように、メッセージの具体的な内容についてのデータ。

V0バージョンでは、カフカメッセージフォーマット以下に示すように：

以下に示すようにバージョンV1、kakfaメッセージ形式：

V2バージョン

以下に具体的な言及

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

2.2ログのセグメントインデックス

セグメントデータファイル

クエリ効率を解決するための手段のカフカ一つのセグメントに例えば100メッセージとして、それらは0-99からオフセットされているデータファイルです。データファイルは5つのセグメント、0~19の最初のセグメント、第二セグメントの20-39、に分割されているものとするように、オフセットを最小にこの段落でデータファイル名内の別のデータファイル内の各。その時のオフセットを指定されたメッセージを検索し、あなたはどのセグメントでメッセージを見つけるためにバイナリ検索を使用することができます。

インデックス付きデータファイル

数据文件分段使得可以在一个较小的数据文件中查找对应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进行合并，避免出现过小的日志和索引文件