Kafka消息規范的示例分析

這篇文章主要介紹了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生產消息

感謝你能夠認真閱讀完這篇文章，希望小編分享的“Kafka消息規范的示例分析”這篇文章對大家有幫助，同時也希望大家多多支持億速云，關注億速云行業資訊頻道，更多相關知識等著你來學習!