虽然kafka0.7现在已经没用到了,但还是记录下之前整理的0.7版本的协议,权当小结。
在用kafka0.7的client读取message的时候,要自己操作offset,有时操作不好进程就出问题了(直接影响到数据的完整性!),搜了下官网wiki,看明白了每一条message传输报文的组成,知道这些,也就不会出问题。
1、kafka message传输协议报文:
0
1
2
3
(Byte)
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
1 (Bit)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LENGTH(总长度) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MAGIC(是否压缩) | COMPRESSION | CHECKSUM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CHECKSUM (cont.) | PAYLOAD /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
/ PAYLOAD (cont.) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2、报文字段:
a.
LENGTH: 占4字节(unsigned long) ,存放在kafak里面的消息的总长度,包含checksum和压缩标识;
b.
MAGIC : 占1个字节,表示是否带有压缩标志(
COMPRESSION
), 取值为0-1, 0表示不带压缩,1表示压缩
c
.
COMPRESSION :占1个字节,压缩标志,表示采用的
压缩算法, 取值为 0-2, 0表示不压缩,1表示gzip压缩,2表示snappy压缩
所以,1条不带压缩的消息的实际占用字节数为: 9字节 (4 + 1(
MAGIC
) + 4)+ 原始消息的字符串字节数,
1条带压缩的消息的实际占用字节数为: 10字节 (4 + 1(
MAGIC
) +1(
COMPRESSION
)+ 4)+ 原始消息的字符串字节数.
当我们采用socket和kafka服务器进行通讯的时候,需要按照报文的规则来切包,根据有无压缩,消息的内容长度等,从socket stream读取对应字节数,才不会出错。
具体实现可参见kafka的各种(php c++ java等)client源码。
3、offset存储
对应存储的offset的计算也是跟上面类似,但是在kafka log file里面,每条消息之间还需要1个字节的特殊字符来作为消息的分隔符,所以我们在计算
kafka message存储的offset的时候还需要加上1个字节的分隔符。
示例:
第一条消息 "hello world"长度为11, 假设存储到一个新的partition,则起始offset为0,
再加入第二条消息 "kafka"(长度5), 它的offset则为第一条消息的结束offset: 0+9(
不压缩
)+11+1(消息分隔符)=11+10=21 字节
https://cwiki.apache.org/confluence/display/KAFKA/Wire+Format