轉載自: https://yq.aliyun.com/ziliao/65771
參考: Kafka集群partition replication默認自動分配分析
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 數量，以便於您獲取更多的相關知識。