Kafka檔案儲存體機制那些事__Big

來源:互聯網
上載者:User
Kafka是什麼

Kafka是最初由Linkedin公司開發,是一個分布式、分區的、多副本的、多訂閱者,基於zookeeper協調的分布式日誌系統(也可以當做MQ系統),常見可以用於web/nginx日誌、訪問日誌,Message Service等等,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中檔案儲存體方式:

                              圖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設定一個中繼資料指標,它比稠密索引節省了更多的儲存空間,但尋找起來需要消耗更多的時間。 3 Kafka檔案儲存體機制–實際運行效果

實驗環境: Kafka叢集:由2台虛擬機器組成 cpu:4核 實體記憶體:8GB 網卡:千兆網卡 jvm heap: 4GB 詳細Kafka服務端配置及其最佳化請參考:kafka server.properties配置詳解

                              圖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.Linux Page Cache機制
2.Kafka官方文檔 


原文地址: http://tech.meituan.com/kafka-fs-design-theory.html

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.