kafka-消息格式

消息

消息包含一个可变长度的 header ,一个可变长度不透明的字节数组 key ,一个可变长度不透明的字节数组 value ,消息中 header 的格式会在下一节描述. 保持消息中的 key 和 value 不透明(二进制格式)是正确的决定: 目前构建序列化库取得很大的进展,而且任何单一的序列化方式都不能满足所有的用途.毋庸置疑,使用kafka的特定应用程序可能会要求特定的序列化类型作为自己使用的一部分. RecordBatch 接口就是一种简单的消息迭代器,它可以使用特定的方法批量读写消息到 NIO 的 Channel 中.

消息通常按照批量的方式写入.record batch 是批量消息的技术术语,它包含一条或多条 records.不良情况下, record batch 只包含一条 record. Record batches 和 records 都有他们自己的 headers.在 kafka 0.11.0及后续版本中(消息格式的版本为 v2 或者 magic=2)解释了每种消息格式。

V2版本对消息集合称为RecordBatch
kafka-消息格式_第1张图片
整体来看分为两个大部分:recordBatch header,records。其中recordBatch header包含13个字段,这里为何加个修饰recordBatch,文后有解释;records是一个嵌套结构体。

消息格式Record的关键字段,可以看到内部字段大量采用了Varints,这样Kafka可以根据具体的值来确定需要几个字节来保存。v2版本的消息格式去掉了crc字段,另外增加了length(消息总长度)、timestamp delta(时间戳增量)、offset delta(位移增量)和headers信息,并且attributes被弃用了,至于key、key length、value、value length字段和v0以及v1版本的一样。

Record的消息格式

名称 含义 字节数
ength 消息总长度(每条) 可变长字段
attributes 弃用(保留未来的格式扩展使用) 1B
timestamp delta 时间戳增量。通常一个时间戳会占据8个字节,这里保存的是由RecordBatch的起始时间戳的差值,明显占据更少的空间 可变长字段
offset delta 位移增量。保存与RecordBacth的起始位移的差值,同样可以节省占用字节数。 可变长字段
headers 为了做应用级别的扩展使用,Header的格式如上图最有,包含key和value,一个Record里面可以包含0至多个Header 作者:觅密学堂IT分享 https://www.bilibili.com/read/cv15447937 出处:bilibili

RecordBatch格式

名称 含义 字节数
first offset RecordBacth的起始位移,也就是第一条消息的位移 8B
length 计算从magic字段开始到末尾的总长度 4B
partition leader epoch leader的版本号,为了副本同步使用 4B
magic 消息的版本号 1B
Attributes 第三位压缩格式,第四位时间戳类型,第五位表示是否处于事务当中,0,非事务,1事务 第六位表示是否控制消息 2B
last offset delta Record Batch 中最后一个 消息的位移与第一个位移的差值,主要用来Broker来保证RecordBacth中Record组装的准确性。 4B
first timestamp RecordBatch中第一条消息的时间戳 8B
max timestamp 最大时间戳,一般是最后一条消息的时间戳 8B
record count 消息的个数 4B
header部分

attributes:消息属性,注意这里占用了两个字节,具体格式如图所示(此图只画一个字节各位意义,实际占用两个字节)
低3位表示压缩类型,可以参考v0和v1;
第4位表示时间戳类型;
第5位表示此RecordBatch是否处于事务中,0表示非事务,1表示事务。
kafka-消息格式_第2张图片

第6位表示是否是Control消息,0表示非Control消息,而1表示是Control消息,Control消息用来支持事务功能。

名称 含义
first offset 表示当前RecordBatch的起始位移。
length 计算partition leader epoch到末尾的长度
partition leader epoch 分区leader纪元,可以看作分区leader的版本号或更新次数
magic 消息格式的版本号,对于v2版本而言,magic等于2。
last offset delta RecordBatch中最后一个Record的offset与first offset的差值。主要被broker用来确认RecordBatch中Records的组装正确性。
first timestamp RecordBatch中第一条Record的时间戳。
max timestamp RecordBatch中最大的时间戳,一般情况下是指最后一个Record的时间戳,和last offset delta的作用一样,用来确保消息组装的正确性。
producer id 用来支持幂等性。
producer epoch 和producer id一样,用来支持幂等性和事务。
first sequence 和producer id、producer epoch一样,用来支持幂等性和事务。
records count RecordBatch中Record的个数。

V2版本的消息不仅提供了更多的功能,比如事务、幂等性等,某些情况下还减少消息的空间占用,提高磁盘利用率,总体性能提升很大。具体读者可以自行测试,作者也用一个章节专门介绍编码实测方案、执行过程和测试结果。

你可能感兴趣的:(kafka,kafka)