什么是网站建设最新新闻头条
日志存储机制是Kafka实现高吞吐量和持久化能力的关键。
1 文件目录布局
图 主题与日志文件的关系
Kafka中的消息持久化为日志文件。一个副本对应一个日志。日志文件在broker上是命名形式为<topic>-<partition>的文件夹。例如，主题par3第3分区在某个副本日志在broker上的文件夹名为par3-3。
为了防止Log过大，将其切分为多个LogSegment(日志分段)，以便于消息的维护和清理。每个LogSegment对应磁盘的一个日志文件和两个索引文件，以及可能的其他文件（例如.txnindex 事务索引文件）。
向Log中追加消息是顺序写入的，只有最后一个LogSegment（activeSegment,当前活跃的日志分段）才能执行写入操作。
每个LogSegment 都有一个基准偏移量baseOffset，表示当前LogSegment中第一条消息的offset。日志及两个索引文件都是根据baseOffset命名的，名称固定为20为数字（64位的长整型数）。
图 某时刻par1主题的0分区所在的broker的目录下的文件
2 日志格式
Kafka的消息格式经历了3个版本：v0、v1、v2。
2.1 v0 版本
图 v0版本的消息结构
Offset:消息在分区中的偏移量。
message size: 消息的大小。
crc32: crc32 校验值，检验范围位magic至value之间。
magic: 消息格式版本号，值为0。
attributes：消息属性，低3位表示压缩类型，其余位保留。
key lenght: 消息的key长度。如果为-1，表示key=null。
key：可选
value lenght：实际消息体的长度，如果为-1，表示value=null。
value：消息体，可以为空，为空时可以用来表示墓碑（tombstone）消息。
Offset与message size 一起被称为日志头部（LOG_OVERHEAD）。一条或多条消息组成消息集，消息集是消息存储于磁盘及在网络上传输的基本形式，还是Kafka压缩的基本单位。
2.2 v1版本
图 v1版本的消息结构
v1 比v0 多添加了个字段timestamp，用于表示消息的时间戳。
attributes字段的第4位用于表示这个时间戳的类型，0 表示CreateTime 生产者创建消息时的时间戳、1 表示 LogAppendTime 消息添加到日志时的时间戳。默认值为0，可由broker端的log.message.timestamp.type 来配置。
2.3 v2 版本
与前面两个版本最大的不同是，消息字段大量采用了Varints(变长字段)。
2.3.1 Varints 变长字段
Varints 是使用一个或多个字节来序列化整数的一种方法。数值越小，其占用的字节数越少。每个字节都有一个位于最高位的msb位，除最后一个字节外，其余msb位都设置为1。表示其后的字节是否和当前字节一起来表示同一个整数。
Varints中采用的是小端字节序。
小端字节序：用于表示多字节数据的一种字节顺序的方式。低位在前，高位在后。即从右到左来阅读数字，而大端字节序，是高位在前，低位在后，从左到右来阅读数字。
例如int类型（4个字节，32位）的数字16。大端字节序表示为：00000000 00000000 00000000 00010000，小端字节序表示为00010000 00000000 00000000 00000000。
小端字节序在处理少字节格外高效。
2.3.2 v2版本格式
图 v2版本的消息结构
v2版本中消息集称为Record Batch 而不是先前的Message Set。在消息压缩的情形下，Record Batch Header 部分（从first offset 到records count）是不被压缩的，而records字段中的所有消息会被压缩。
| first offset | 当前RecordBatch 的起始位移。 |
| length | 从partition leaderepoch字段开始到末尾的长度。 |
| partition leader epoch | 分区leader纪元（版本号或更新次数） |
| attributes | 消息属性，低3位表示压缩格式，第4位表示时间戳类型；第5位表示此RecordBatch是否处于事务中，第6位表示是否是控制消息。 |
| first timestamp | RecordBatch中第一条Record的时间戳。 |
表 Record Batch 相关字段
| length | 消息总长度 |
| attributes | 弃用，以备未来的格式扩展。 |
| timestamp delta | 时间戳增量。 |
| offset delta | 位移增量 |
表 v2版本 Record 相关字段
2.3.3 消息压缩
Kafka实现的压缩方式是将多条消息一起进行压缩。在一般情况下，生产者发送的压缩数据在broker也是保持压缩状态进行存储，消费者从服务端获取的也是压缩的消息，消费者在处理消息之前才会解压消息。
当消息压缩时，将整个消息集进行压缩作为内层消息，内层消息整体作为外层的value。外层中的key为null。内层被压缩的消息，其offset从0开始。