從0.8.x版本開始到現在的2.x版本，kafka的訊息格式也經歷了 3 個版本： v0 版本、v1 版本和 v2 版本 。
kafka 從 0.8.x 版本開始到 0.10.x 版本之前的訊息格式通常稱為 v0 版本。
下圖中左邊的 「record」 部分就是 v0 版本的訊息格式，每個 record ( v0 和 v1 版）必定對應乙個 offset 和 message size。offset 用來標誌它在 partition 中的偏移量 ，這個 offset 是邏輯值，而非實際物理偏移值，message size 表示訊息的大小，這兩者在一起被稱為日誌頭部 （log_overhead ) ，固定為12b 。log_overhead 和 record 一起用來描述一條訊息。
與訊息對應的還有訊息集的概念（詳細結構參考下圖中的右邊部分），訊息集中包含一條或多條訊息，訊息集不僅是儲存於磁碟及在網路上傳輸（produce & fetch）的基本形式，而且是kafka 中壓縮的基本單元。
v0版本中乙個訊息的最小長度（record_overhead_v0）為crc32+magic+attributes+keylength+value length=4b+1b+1b+4b+4b=14b。也就是說，v0版本中一條訊息的最小長度為14b，如果小於這個值，那麼這就是一條破損的訊息而不被接收。2.0.0 版本之前如果想要檢視日誌分段檔案中的內容，使用 「kafka-run-class.sh kafka.tools.dumplogsegments --files 檔名」 的方式。kafka 從 0.10.0 版本開始到 0.11.0 版本之前所使用的訊息格式版本為 v1，比 v0 版本就多了乙個 timestamp 字段，表示訊息的時間戳。 v1 版本的訊息結構如下圖所示。
來配置，預設值為createtime，即採用生產者建立訊息時的時間戳。如果在建立 producerrecord 時沒有顯式指定訊息的時間戳，那麼 kafkaproducer 也會在傳送這條訊息前自動新增上。
v1 版本的訊息的最小長度（record_overhead_v1）要比 v0 版本的大 8 個位元組，即22b。
kafka實現的壓縮方式是將多條訊息一起進行壓縮，這樣可以保證較好的壓縮效果。
在一般情況下，生產者傳送的壓縮資料在broker中也是保持壓縮狀態進行儲存的，消費者從服務端獲取的也是壓縮的訊息，消費者在處理訊息之前才會解壓訊息，這樣保持了端到端的壓縮。
kafka 通過 broker 端引數compression.type
壓縮率是壓縮後的大小與壓縮前的對比。例如：把100mb的檔案壓縮後是90mb，壓縮率為90/100×100%=90%，壓縮率越小，壓縮效果越好。當生產者建立壓縮訊息的時候，對內部壓縮訊息設定的 offset 從 0 開始為每個內部訊息分配 offset，詳細可以參考下圖右半部分。其實每個從生產者發出的訊息集中的訊息offset都是從0開始的，當然這個offset不能直接儲存在日誌檔案中，對 offset 的轉換是在服務端進行的，客戶端不需要做這個工作。外層訊息儲存了內層訊息中最後一條訊息的絕對位移（absolute offset），絕對位移是相對於整個分割槽而言的。參考下圖，對於未壓縮的情形，圖右內層訊息中最後一條的offset理應是1030，但被壓縮之後就變成了5，而這個1030被賦予給了外層的 offset。
v1版本比v0版的訊息多了乙個timestamp欄位。對於壓縮的情形，外層訊息的timestamp設定為：
內層訊息的timestamp設定為：
對 attributes 字段而言，它的 timestamp 位只在外層訊息中設定，內層訊息中的timestamp型別一直都是createtime。
kafka 從 0.11.0 版本開始所使用的訊息格式版本為 v2，這個版本的訊息相比 v0 和 v1 的版本而言改動很大，同時還參考了 protocol buffer而引入了變長整型（varints）和zigzag編碼。
2.0.0版本開始如果想要檢視日誌分段檔案中的內容，使用 「kafka-dump-log.sh --files 檔名」 的方式。2.x版本前後兩種檢視日誌分段的方式在本質上沒有什麼區別，只不過在kafka 2.0.0之前並沒有kafka-dump-log.sh指令碼，所以只能使用kafka-run-class.sh kafka.tools.dumplogsegments的形式，而從kafka 2.0.0開始，可以直接使用kafka-dump-log.sh指令碼來避免書寫錯誤。通過檢視kafka-dump-log.sh指令碼可以發現，內部還是使用kafka-run-class.sh kafka.tools.dumplogsegments的方式
kafka（七） 訊息格式
1 乙個kafka的message由乙個固定長度的header和乙個變長的訊息體body組成 2 header部分由乙個位元組的magic 檔案格式 和四個位元組的crc32 用於判斷body訊息體是否正常，是否丟包，資料不一樣crc32算出來的數字也是不一樣的 構成。當magic的值為1的時候，會...
訊息佇列 訊息佇列 kafka
kafka是乙個分布式的基於發布 訂閱模式的訊息佇列，主要用於大資料實時處理領域。要理解kafka首先要有分布式的概念，要有訊息佇列的概念。分布式系統最大的優勢就是解耦和削峰，這種情況下，a系統生成了乙個訊息，b系統非同步獲取，那麼就需要乙個存放訊息的訊息佇列 mq 相比較傳統的訊息佇列，訊息被消費...
Kafka訊息模型
一 訊息傳遞模型 傳統的訊息佇列最少提供兩種訊息模型，一種p2p，一種pub sub，而kafka並沒有這麼做，巧妙的，它提供了乙個消費者組的概念，乙個訊息可以被多個消費者組消費，但是只能被乙個消費者組裡的乙個消費者消費，這樣當只有乙個消費者組時就等同與p2p模型，當存在多個消費者組時就是pub s...