Kafka消息规范的示例分析
这篇文章主要介绍了Kafka消息规范的示例分析,具有一定借鉴价值,感兴趣的朋友可以参考下,希望大家阅读完这篇文章之后大有收获,下面让小编带着大家一起了解一下。
创新互联建站主营牟平网站建设的网络公司,主营网站建设方案,成都app软件开发公司,牟平h5微信小程序定制开发搭建,牟平网站营销推广欢迎牟平等地区企业咨询
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消息规范的示例分析”这篇文章对大家有帮助,同时也希望大家多多支持创新互联,关注创新互联行业资讯频道,更多相关知识等着你来学习!
当前题目:Kafka消息规范的示例分析
浏览路径:http://scyanting.com/article/gihghs.html