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