Kafka message协议和存储 （0.7版本）

虽然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