Kafka文件存儲機制及partition和offset

轉載自:  https://yq.aliyun.com/ziliao/65771

 參考:  Kafka集羣partition replication默認自動分配分析

　　    如何爲kafka選擇合適的partitions

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（將一個topic分爲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文件元數據佔用空間大小。

 

topic------->多個partiton----------->1個partion多個segment----------->1個segment多個index和log

在只有一個broker的時候，多個partion位於這個broker，有多個broker的時候是按照必定的算法分佈在多個broker上。

5.kafka中的partition和offset

5.1Log機制

說到分區,就要說kafka對消息的存儲.在官方文檔中.

 

分區讀寫日誌圖

 

首先,kafka是經過log(日誌)來記錄消息發佈的.每當產生一個消息,kafka會記錄到本地的log文件中,這個log和咱們平時的log有必定的區別.這裏能夠參考一下The Log,很少解釋.

這個log文件默認的位置在config/server.properties中指定的.默認的位置是log.dirs=/tmp/kafka-logs,linux不用說,windows的話就在你對應磁盤的根目錄下.我這裏是D盤.

 

分區partition

kafka是爲分佈式環境設計的,所以若是日誌文件,其實也能夠理解成消息數據庫,放在同一個地方,那麼必然會帶來可用性的降低,一掛全掛,若是全量拷貝到全部的機器上,那麼數據又存在過多的冗餘,並且因爲每臺機器的磁盤大小是有限的,因此即便有再多的機器,可處理的消息仍是被磁盤所限制,沒法超越當前磁盤大小.所以有了partition的概念.

kafka對消息進行必定的計算,經過hash來進行分區.這樣,就把一份log文件分紅了多份.如上面的分區讀寫日誌圖,分紅多份之後,在單臺broker上,好比快速上手中,若是新建topic的時候,咱們選擇了--replication-factor 1 --partitions 2,那麼在log目錄裏,咱們會看到

test-0目錄和test-1目錄.就是兩個分區了.

你可能會想,這特麼沒啥區別呀.注意,當有了多個broker以後,這個意義就存在了.這裏上一張圖,原文在參考連接裏有

 

5.2 kafka分佈式分區存儲

 

這是一個topic包含4個Partition，2 Replication(拷貝),也就是說所有的消息被放在了4個分區存儲,爲了高可用,將4個分區作了2份冗餘,而後根據分配算法.將總共8份數據,分配到broker集羣上.

結果就是每一個broker上存儲的數據比全量數據要少,但每份數據都有冗餘,這樣,一旦一臺機器宕機,並不影響使用.好比圖中的Broker1,宕機了.那麼剩下的三臺broker依然保留了全量的分區數據.因此還能使用,若是再宕機一臺,那麼數據不完整了.固然你能夠設置更多的冗餘,好比設置了冗餘是4,那麼每臺機器就有了0123完整的數據,宕機幾臺都行.須要在存儲佔用和高可用之間作衡量.

至於宕機後,zookeeper會選出新的partition leader.來提供服務.這個等下篇文章

偏移offset

上一段說了分區,分區就是一個有序的,不可變的消息隊列.新來的commit log持續日後面加數據.這些消息被分配了一個下標(或者偏移),就是offset,用來定位這一條消息.

消費者消費到了哪條消息,是保持在消費者這一端的.消息者也能夠控制,消費者能夠在本地保存最後消息的offset,並間歇性的向zookeeper註冊offset.也能夠重置offset

如何經過offset算出分區

其實partition存儲的時候,又分紅了多個segment(段),而後經過一個index,索引,來標識第幾段.這裏先能夠去看一下本地log目錄的分區文件夾.

在我這裏,test-0,這個分區裏面,會有一個index文件和一個log文件,

 

index和log

 

對於某個指定的分區,假設每5個消息,做爲一個段大小,當產生了10條消息的狀況想,目前有會獲得(只是解釋)

0.index (表示這裏index是對0-4作的索引)

5.index (表示這裏index是對5-9作的索引)

10.index (表示這裏index是對10-15作的索引,目前還沒滿)

和

0.log

5.log

10.log

,當消費者須要讀取offset=8的時候,首先kafka對index文件列表進行二分查找,能夠算出.應該是在5.index對應的log文件中,而後對對應的5.log文件,進行順序查找,5->6->7->8,直到順序找到8就行了.

 

以上是Kafka文件存儲機制及partition和offset的所有內容，在雲棲社區的博客、問答、雲棲號、人物、課程等欄目也有Kafka文件存儲機制及partition和offset的相關內容，歡迎繼續使用右上角搜索按鈕進行搜索存儲 ， 文件 ， 數據 ， 索引 ， 磁盤 物理 kafka offset保存機制、kafka offset 存儲、kafka partition、kafka partition 設置、kafka partition 數量，以便於您獲取更多的相關知識。