kafka原理解析之-消息格式

kafka经过多个版本的演变，消息格式也在不断的变化改进，本文讨论kafka使用过的各种消息格式，有些格式在最新的版本中已经不用，但我们可以从中学习一些设计思想

一、消息格式

介绍各版本消息格式及版本变更特性

1、V0： Kafka 0.10.0 之前的版本，

属性说明：

• LOG_OVERHEAD : offset + message_size 合在一起，表示 日志头部， 固定为 12 B.
• MESSAGE : LOG_OVERHEAD + RECORD 一起描述 一条消息。
• offset : 每条消息都有一个 offset 用来标识 它在分区中的偏移量， 这个 offset 是逻辑值，而非实际物理偏移值。
• message_size : 表示消息的大小。
• Message_set : 消息集，消息集包含一条或多条消息，消息集不仅仅是存储在磁盘上，以及网络上传输 （Produce & Fetch ）的基本形式，而且是 Kafka 中压缩的基本单元。
• crc32（4B）: crc32 校验值。校验范围为 magic 至 value 之间。
• magic (1B) : 消息格式版本号，此版本的 magic 为0。
• attributes (1B) : 消息的属性。总共占1个字节，低3位表示压缩类型：0 表示NONE, 1 表示GZIP, 2 表示SNAPPY，其余位保留。
• key length (4B)： 表示消息的 key 的长度。如果为-1， 标识没有设置 key, 即 key == null.
• Key: 可选，如果没有 key 则无此字段
• value length (4B) : 实际消息体的长度。如果为 -1 ，则标识消息为空。
• value:可以为空，比如 tombstone 消息。

2、V1： 0.10.0 到 0.11.0 的版本
messageset无变化，record增加了字段，如下图。

属性说明：

• v1 相比 v0 版本增加了 timestamp 字段。
• v1 版本的 magic 字段为 1 。
• v1 版本的 attribute 字段的低三位 和 v0 版本一样，表示压缩类型， 第4个位 bit 被利用起来，0 表示 timestamp 为 createTime，1 表示 timestamp 的类型为 LogAppendTime
• timestamp 类型由broker 端参数 log.message.timestamp.type 来配置，默认值为 createTime, 即采用生产者创建消息时的时间戳。

3）、V2： 0.11.0版本之后使用

相比 v0/v1 变动很大，主要有如下几点：

• 消息集的变化：在v2 版本中的消息集称为RecordBatch , 而不是先前的 MessageSet, 其内部也包含了一条或多条消息。
• 压缩优化：Record 的关键字段，大量采用了 Varints压缩技术，可大大的压缩数据规模。注意，在消息压缩的情形下， RecordBatch Header部分是不被压缩的，被压缩的是records字段中的所有内容。
• Record变化：Record去掉crc并转移到了 RecordBatch 中 ，另外Record增加了 length (消息总长度)， timestamp delta( 时间戳增量)， offset delta (位移增量) 和 headers 信息， attributes 字段被弃用了(Record中key, key length, value ,value length 同 v0 和 v1 版本的一样)。

如下图所示

Record 属性说明:

• length : 消息总长度
• attributes : 弃用，但还是在消息格式中占据 1B 的大小，以备未来的格式扩展
• timestamp delta : 时间戳增量。通常一个 timestamp 需要占用8个字节，如果像这里一样保存与 RecordBatch的起始时间戳的差值，则可以进一步节省占用的字节数。
• offset delta : 位移增量。保存与 RecordBatch 起始位移的差值，可以节省占用的字节数。
• headers : 这个字段用来支持应用级别的扩展，而不需要像 v0 和 v1 版本一样不得不将一些应用级别的属性值嵌入消息体，Header 的格式如最右部分所示，包含 key 和 value . 一个Record 里面可以包含 0 至 多个 Header 。

RecordBatch属性说明：

• first offset : 表示当前 RecordBatch 的起始位移。
• length : 计算从 partition leader epoch 字段开始到末尾的长度。
• partition leder epoch : 分区 leader 纪元，可以看作分区 ledaer 的版本号 或更新次数
• magic : 消息格式的版本号，对v2版本而言，magic 等于 2
• attributes : 消息属性。注意这里占用了2个字节。
  低3位表示压缩格式，可以参考 v0 和 v1. 第4位表示时间戳类型，
  第5位表示此RecordBatch 是否处于 事务中， 0 表示非事务，1表示事务。
  第6位表示是否是 控制消息 （ControlBatch）, 0 表示非控制消息，1表示是控制消息，控制消息用 来支持事务功能。
• last offset delta : RecordBatch 中最后一个 Record 的 offset 与 first offset 的差值。主要被 broker 用来确保 RecordBatch 中 Record 组装的正确性。
• first timestamp : RecordBatch 中第一条 Record 的时间戳
• max timestamp : Record 中最大的时间戳，一般情况下是指最后一个 Record 的时间戳，和 last offset delta 的作用一样，用来确保消息组装的正确性。
• producer id : PID, 用来支持幂等和事务。
• producer epoch : 和 producer id 一样，用来支持幂等 和十五
• first sequence : 和 producer id，producer epoch 一样，用来支持幂等和事务
• records count : RecordBatch 中 Record 的个数。

二、消息压缩

本节讨论基于 messageset 的消息压缩（RecordBatch压缩总体上大致相同）。

使用那种压缩方式是通过topic配置参数 compression.type配置，默认值为 producer , 表示保留生产者使用的压缩方式。这个参数还可以配置为 ”gzip" , “snappy”, “lz4”, 分别对应 GZIP, SNAPPY, LZ4 这3种压缩算法。如果参数 compression.tyoe 配置为 ”uncompressed“, 表示不压缩。

压缩过程如下面图示：

图一

• 消息压缩时，是将整个消息集进行压缩作为内层消息inner message，内层消息整体作为外层 (wrapper message）的 value. 压缩后的外层消息 （wrapper message ）中的key 为 null（图一左半部分没有画出 key 字段），value 字段中保存的是多条压缩消息 （inner message, 内层消息）

图二

• 每个从生产者发出的内层压缩消息集中的offset 都是从0 开始的，外层消息保存了内层压缩消息中最后一条消息的绝对位移（absolute offset）,绝对位移是相对于整个分区而言的。

kafka的压缩方案实际上是端到端批量压缩：producer把需要发送给broker的消息作为一个batch ，整体进行压缩，broker直接把这个压缩后的文件存储起来，consumer 来消费的时候直接把这个压缩文件发送出去，性能极高.