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生产消息