大數據:基於zookeeper協調的分布式日誌系統Kafka的文件存儲機制

Kafka是什麼

Kafka是最初由Linkedin公司開發,是一個分佈式、分區的、多副本的、多訂閱者,基於zookeeper協調的分佈式日誌系統(也可以當做MQ系統),常見可以用於web/nginx日誌、訪問日誌,消息服務等等,Linkedin於2010年貢獻給了Apache基金會併成為頂級開源項目。

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中文件存儲方式:

大數據:基於zookeeper協調的分佈式日誌系統Kafka的文件存儲機制

 圖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個規則:

大數據:基於zookeeper協調的分佈式日誌系統Kafka的文件存儲機制

 圖2

以上述圖2中一對segment file文件為例,說明segment中indexdata file對應關係物理結構如下:

大數據:基於zookeeper協調的分佈式日誌系統Kafka的文件存儲機制

 圖3

上述圖3中索引文件存儲大量元數據,數據文件存儲大量消息,索引文件中元數據指向對應數據文件中message的物理偏移地址。

其中以索引文件中元數據3,497為例,依次在數據文件中表示第3個message(在全局partiton表示第368772個message)、以及該消息的物理偏移地址為497。

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

大數據:基於zookeeper協調的分佈式日誌系統Kafka的文件存儲機制

 圖4

參數說明:

關鍵字解釋說明8 byte offset在parition(分區)內的每條消息都有一個有序的id號,這個id號被稱為偏移(offset),它可以唯一確定每條消息在parition(分區)內的位置。即offset表示partiion的第多少message4 byte message sizemessage大小4 byte CRC32用crc32校驗message1 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設置一個元數據指針,它比稠密索引節省了更多的存儲空間,但查找起來需要消耗更多的時間。

3 Kafka文件存儲機制–實際運行效果

實驗環境:

  • Kafka集群:由2臺虛擬機組成
  • cpu:4核
  • 物理內存:8GB
  • 網卡:千兆網卡
  • jvm heap: 4GB
  • 詳細Kafka服務端配置及其優化請參考:kafka server.properties配置詳解
大數據:基於zookeeper協調的分佈式日誌系統Kafka的文件存儲機制

 圖5 

從上述圖5可以看出,Kafka運行時很少有大量讀磁盤的操作,主要是定期批量寫磁盤操作,因此操作磁盤很高效。這跟Kafka文件存儲中讀寫message的設計是息息相關的。Kafka中讀寫message有如下特點:

寫message

  • 消息從java堆轉入page cache(即物理內存)。
  • 由異步線程刷盤,消息從page cache刷入磁盤。

讀message

  • 消息直接從page cache轉入socket發送出去。
  • 當從page cache沒有找到相應數據時,此時會產生磁盤IO,從磁
  • 盤Load消息到page cache,然後直接從socket發出去

4.總結

Kafka高效文件存儲設計特點

  • Kafka把topic中一個parition大文件分成多個小文件段,通過多個小文件段,就容易定期清除或刪除已經消費完文件,減少磁盤佔用。
  • 通過索引信息可以快速定位message和確定response的最大大小。
  • 通過index元數據全部映射到memory,可以避免segment file的IO磁盤操作。
  • 通過索引文件稀疏存儲,可以大幅降低index文件元數據佔用空間大小。

【1】想了解大數據知識,可以關注我下方評論轉發後,私信“資料”。

【2】部分資料有時間限制,抓緊時間吧!

感謝大家支持!


分享到:


相關文章: