kafka 系列 -- 7.一、日志存储

一、日志文件布局

__consumer_offset 存储着消费者提交的消费位移

二、日志存储格式

V0

消息格式

• offset:

每一条消息都有一个 offset 用来标志它在分区中的偏移量，offset 是逻辑值，而非实际物理偏移量

• message_size:

表示消息的大小

• crc32(4B):

crc32 校验值。校验范围为 magic 至 value 之间

• magic(1B):

消息格式版本号，V0 固定为 0

• attributes(1B):

消息的属性。总共占1个字节，低 3 位表示压缩类型。
0：NONE、1：GZIP、2：SNAPPY；3：LZ4. 其他位保留

• key length(4B):

-1,表示没有设置 key

• key:

可选

• value lengtj(4B):

消息体的长度，-1，表示为空

• value:

消息体

V1

kafka 从 0.10.0 版本至 0.11.0 版本以前所使用的消息格式版本为 v1, 比 v0 多了一个 timestamp 字段

消息格式

• magic(1B):

消息格式版本号，V0 固定为 1

• attributes(1B):

前三位一样表示压缩类型。
第4位：0-timestamp 类型为 CreateTime, 1-timestap 类型为 LogAppendTime
timestamp 类型由 broker 端参数 log.message.timestamp.type 配置，默认值为 CreateTime

V2

kafka 版本从 0.11.0 以后都称为 v2.

• length

消息总长度

• attributes

弃用

• timestamp delta

时间戳增量，保存与 RecordBatch 起始时间戳的差值

• offset delta

位移增量，保存与 RecordBatch 起始位移的差值

• headers

支持应用级别的扩展

• first offset

当前 RecordBatch 的起始位移

• length

计算从 partitionleader epoch 字段开始到末尾的长度

• partitionleader epoch

分区 leader 的版本号或更新次数

• magic

V2 固定为 2

• attributes

占用 2 个字节；低三位表示压缩格式，第4位表示时间戳类型，第5位表示 RecordBatch 是否处于事务中，0-非事务，1-事务。第6位表示是不是控制消息，0-非控制，1-控制，控制消息用来支持事务功能

• last offset delta

RecordBatch 中最后一个 Record 的 offset 与 first offset 的差值。最要被 broker 用于确保RecordBatch 中 Record 组装的正确性

• first timestamp

RecordBatch 第一条Record 时间戳

• max timestamp

RecordBatch 中最大时间戳

• producer id

PID,用于支持幂等和事务

• producer epoch

用于支持幂等和事务

• first sequence

用于支持幂等和事务

• record count

RecordBatch 中 Record 个数

三、消息压缩

broker 可经过 compression.type 配置压缩方式，默认 producer，即保留生产者的压缩方式

什么时候压缩

kafka 可能在 producer 端或者 broker 端中进行压缩。

当消息在 broker 端从新压缩时，会形成性能降低，所以须要尽可能避免。

如下会在 broker 端发生从新压缩

1. broker 端和producer 端不一样的压缩算法。
2. broker 端发生消息格式转换，即新版本消息向老版本消息转化。

什么时候解压缩

kafka 将多条消息放一块儿压缩，生产者发送的是压缩的数据，broker 存储的也是压缩的数据。消费者在拉取消息时，也是压缩的数据，在处理前才会解压消息。