Kafka消息规范的示例分析
这篇文章主要介绍了Kafka消息规范的示例分析，具有一定借鉴价值，感兴趣的朋友可以参考下，希望大家阅读完这篇文章之后大有收获，下面让小编带着大家一起了解一下。
Kafka作为一个消息队列，有其自己定义消息的格式。Kafka中的消息采用ByteBuf，之所以采用ByteBuf这种紧密的二进制存储格式是因为这样可以节省大量的空间。毕竟如果使用Java类的格式来定义消息对象将会浪费大量的空间(Java对象除了本身属性所占的空间外，还存在一些Header，还会存在一些补齐)。
V2消息格式
Kafka的消息格式经历了V0、V1以及V2版本。V0没有时间戳的字段，导致很难对过期的消息进行判断。V0、V1存在很多固定长度的字段，这些字段在实际中往往占用很少，造成浪费，因此V2将其中的很多定义长度的字段设计成可变长度。
可变长度的设计借鉴了Zig-zag编码格式，最高位用来表示当前字节是否已经是某个数编码的最后一个字节（1代表不是，0代表是）。
消息总长度：整个消息的长度，方便消息的遍历以及获取其总长度
属性：保留字段，暂时无作用
时间戳增量：消息距离Batch时间戳的增量，不再使用固定8字节的时间戳，该字段将会大大降低消息的存储空间
位移增量：消息距离Batch位移的增量
key length：消息key内容的长度
key：消息key的内容
value size：消息内容的长度
value：消息内容
header：header的个数
heders：具体的header，对用户可见，可做消息路由或者某些消息元数据的载体。
V2消息批次格式RecordBatch
一个消息批次包含若干个消息组成，其实Kafka的日志文件就是用若干个消息批次组成的，kafka不是直接在消息层面上操作的，它总是在消息批次层面上进行写入。
起始位移：Kafka日志分区中的offset
长度：该消息批次的长度
分区leader版本号
版本号：目前该值是2
CRC：CRC校验码，用来确认消息在传输过程中不会被篡改，该字段在V0、V1中是在消息层面的，但对每一条消息都进行CRC，将会造成CPU的浪费
属性：该字段在V0和V1的版本中也是存在于消息层面，在V2中低三位依然表示消息的压缩类型，第4位依然是时间戳类型(一种是客户端指定时间戳，另一种是有kafka broker指定时间戳)，第5位和第6位分别表示新引入的事务类型和控制类型
起始时间戳：batch中第一条消息的时间戳
最大时间戳：batch中最后一条消息的时间戳
PID、producer epoch、起始序列号：序列号的引入为了生产消息的幂等性，Kafka用它来判断消息是否已经提交，防止重复生产消息。PID代表幂等性producer的ID，producer epoch表示producer携带的当前版本号，broker使用这两个字段判断producer是否有效，防止过期的producer生产消息
感谢你能够认真阅读完这篇文章，希望小编分享的"Kafka消息规范的示例分析"这篇文章对大家有帮助，同时也希望大家多多支持，关注行业资讯频道，更多相关知识等着你来学习!
