0.9版本
1、消息集Message set
一个消息集中包含一条或多条消息，消息集不仅是存储在磁盘及网络传输的基本形式，而且是kafka压缩的基本单元。
2、消息Recode
一个recode是由多个key-value键值对组成，以下介绍各个key的含义。
CRC32，大小4B。CRC校验值，校验范围为magic到value之间。
magic，大小1B。 消息格式版本号。
attributes，大小1B。 消息类型，最低三位为压缩类型。0 无 1 gzip 2 snappy 3 lz4。
key length，大小4B。 key的长度，为-1表示没有设置key。
key，可选。没有设置key就没有该字段。
value length，大小4B。 value的长度，为-1表示没有设置消息。
value，可选。 这是消息体。
3、日志头部log_overheader
每一个recode都有一个日志头部包含offset和message size两个字段。
offset，大小8B。 记录消息在partition中的偏移量。
message size，大小4B。 表示消息的总大小。
4、最小长度
当没有设置key和value时，recode长度最小，为4B+1B+1B+4B+4B=14B。日志头部为8B+4B=12B。
所以消息总大小和.log文件大小为14B+12B=26B。
2、0.10
1、对比
对比0.9版本，新增了一个timestamp字段，大小8B。
且attributes字段第四位启用，标记为时间戳类型。0为CreateTime类型，1为LogAppendTime类型。
2、最小长度
当没有设置key和value时，recode长度最小，为4B+1B+8B+1B+4B+4B=22B。
日志头部为8B+4B=12B。所以消息总大小为22B+12B=34B。
0.11版本
1、版本变化
对于key length和value length这样记录长度的字段，以int类型保存需要4个字节。
在0.11中引入了变长整型(varint&varlong)和zigzag编码，以此来节约存储空间。
记录长度字段的数值和占用字节的关系：[0,63]占用1B [64,8191]占用2B [8192,108575]占用3B。
2、消息集Recode Batch
一个recode batch包含一条或多条消息。
每个消息集都分为header和recodes两部分。压缩时只压缩recodes不压缩header。
recodes部分则包含一条或多条recode记录。
header包含了所有recode的最大最小时间戳、offset、recode个数等信息，共占用61B空间。
2、消息Recode
一个recode是由多个key-value键值对组成，以下介绍各个key的含义。
length varint 。记录本recode的长度。
attributes 1B 。 保留字段，暂时没用。
timestamp delta varlong 。 保存此recode的时间戳与header中最小时间戳的差值。
offset delta varint。 保存此recode的offset与header中最小offset的差值。
key length varint。 没有设置key则为0，占用1B。
key，可选。没有设置key就没有该字段。
value length varint。 没有设置key则为0，占用1B。
value，可选。 这是消息体。
headers count varint 。 记录本recode中headers的数量。没有则为0，占用1B。
headers，可选。
可以有多个。以前很多应用级别的设置要嵌在消息体中，现在设置在headers中即可。
有四个字段。header keyheader valueheader key lengthheader value length。
长度都是varint类型。header key是utf8类型。
3、最小长度
当key value都为null，且recode中未设置header，则recode达到理论最小长度：7个变长整形字段，即7B。
则该消息的最小长度：61B+7B=68B.
当一个消息集中含有的recode数较少时，由于消息集的header占用61B，
所以0.11版本可能会占用更大的存储。当消息集中recode数较多时，则节省空间较为明显。
4、各版本对比
eg. 假设一个消息集中含100个key value都为空的消息时，占用大小对比。
0.9版本： 26B*10=260B.
0.10版本：34B*10=340B.
0.11版本：61B+7B*10=131B.
