kafka存儲機制以及offset

1.前言

一個商業化消息隊列的性能好壞，其文件存儲機制設計是衡量一個消息隊列服務技術水平和最關鍵指標之一。
下面將從Kafka文件存儲機制和物理結構角度，分析Kafka是如何實現高效文件存儲，及實際應用效果。

2.Kafka文件存儲機制

Kafka部分名詞解釋以下：

• Broker：消息中間件處理結點，一個Kafka節點就是一個broker，多個broker能夠組成一個Kafka集羣。
• Topic：一類消息，例如page view日誌、click日誌等均可以以topic的形式存在，Kafka集羣可以同時負責多個topic的分發。
• Partition：topic物理上的分組，一個topic能夠分爲多個partition，每一個partition是一個有序的隊列。
• Segment：partition物理上由多個segment組成，下面2.2和2.3有詳細說明。
• offset：每一個partition都由一系列有序的、不可變的消息組成，這些消息被連續的追加到partition中。partition中的每一個消息都有一個連續的序列號叫作offset,用於partition惟一標識一條消息.

分析過程分爲如下4個步驟：

• topic中partition存儲分佈
• partiton中文件存儲方式
• partiton中segment文件存儲結構
• 在partition中如何經過offset查找message

經過上述4過程詳細分析，咱們就能夠清楚認識到kafka文件存儲機制的奧祕。

2.1 topic中partition存儲分佈

假設實驗環境中Kafka集羣只有一個broker，xxx/message-folder爲數據文件存儲根目錄，在Kafka broker中server.properties文件配置(參數log.dirs=xxx/message-folder)，例如建立2個topic名稱分別爲report_push、launch_info, partitions數量都爲partitions=4
存儲路徑和目錄規則爲：

xxx/message-folder

              |--report_push-0
              |--report_push-1
              |--report_push-2
              |--report_push-3
              |--launch_info-0
              |--launch_info-1
              |--launch_info-2
              |--launch_info-3

 

在Kafka文件存儲中，同一個topic下有多個不一樣partition，每一個partition爲一個目錄，partiton命名規則爲topic名稱+有序序號，第一個partiton序號從0開始，序號最大值爲partitions數量減1。
若是是多broker分佈狀況，請參考kafka集羣partition分佈原理分析

2.2 partiton中文件存儲方式

下面示意圖形象說明了partition中文件存儲方式:

圖1

• 每一個partion(目錄)至關於一個巨型文件被平均分配到多個大小相等segment(段)數據文件中。但每一個段segment file消息數量不必定相等，這種特性方便old segment file快速被刪除。
• 每一個partiton只須要支持順序讀寫就好了，segment文件生命週期由服務端配置參數決定。

這樣作的好處就是能快速刪除無用文件，有效提升磁盤利用率。

2.3 partiton中segment文件存儲結構

讀者從2.2節瞭解到Kafka文件系統partition存儲方式，本節深刻分析partion中segment file組成和物理結構。

• segment file組成：由2大部分組成，分別爲index file和data file，此2個文件一一對應，成對出現，後綴".index"和「.log」分別表示爲segment索引文件、數據文件.
• segment文件命名規則：partion全局的第一個segment從0開始，後續每一個segment文件名爲上一個segment文件最後一條消息的offset值。數值最大爲64位long大小，19位數字字符長度，沒有數字用0填充。

下面文件列表是筆者在Kafka broker上作的一個實驗，建立一個topicXXX包含1 partition，設置每一個segment大小爲500MB,並啓動producer向Kafka broker寫入大量數據,以下圖2所示segment文件列表形象說明了上述2個規則：

圖2

以上述圖2中一對segment file文件爲例，說明segment中index<—->data file對應關係物理結構以下：

圖3

上述圖3中索引文件存儲大量元數據，數據文件存儲大量消息，索引文件中元數據指向對應數據文件中message的物理偏移地址。
其中以索引文件中元數據3,497爲例，依次在數據文件中表示第3個message(在全局partiton表示第368772個message)、以及該消息的物理偏移地址爲497。

從上述圖3瞭解到segment data file由許多message組成，下面詳細說明message物理結構以下：

圖4

參數說明：

關鍵字	解釋說明
8 byte offset	在parition(分區)內的每條消息都有一個有序的id號，這個id號被稱爲偏移(offset),它能夠惟一肯定每條消息在parition(分區)內的位置。即offset表示partiion的第多少message
4 byte message size	message大小
4 byte CRC32	用crc32校驗message
1 byte 「magic"	表示本次發佈Kafka服務程序協議版本號
1 byte 「attributes"	表示爲獨立版本、或標識壓縮類型、或編碼類型。
4 byte key length	表示key的長度,當key爲-1時，K byte key字段不填
K byte key	可選
value bytes payload	表示實際消息數據。

2.4 在partition中如何經過offset查找message

例如讀取offset=368776的message，須要經過下面2個步驟查找。

• 第一步查找segment file
  上述圖2爲例，其中00000000000000000000.index表示最開始的文件，起始偏移量(offset)爲0.第二個文件00000000000000368769.index的消息量起始偏移量爲368770 = 368769 + 1.一樣，第三個文件00000000000000737337.index的起始偏移量爲737338=737337 + 1，其餘後續文件依次類推，以起始偏移量命名並排序這些文件，只要根據offset **二分查找**文件列表，就能夠快速定位到具體文件。
  當offset=368776時定位到00000000000000368769.index|log

• 第二步經過segment file查找message
  經過第一步定位到segment file，當offset=368776時，依次定位到00000000000000368769.index的元數據物理位置和00000000000000368769.log的物理偏移地址，而後再經過00000000000000368769.log順序查找直到offset=368776爲止。

從上述圖3可知這樣作的優勢，segment index file採起稀疏索引存儲方式，它減小索引文件大小，經過mmap能夠直接內存操做，稀疏索引爲數據文件的每一個對應message設置一個元數據指針,它比稠密索引節省了更多的存儲空間，但查找起來須要消耗更多的時間。