Kafka是什麼java
Kafka是最初由Linkedin公司開發,是一個分佈式、分區的、多副本的、多訂閱者,基於zookeeper協調的分佈式日誌系統(也能夠當作MQ系統),常見能夠用於web/nginx日誌、訪問日誌,消息服務等等,Linkedin於2010年貢獻給了Apache基金會併成爲頂級開源項目。nginx
1.前言web
一個商業化消息隊列的性能好壞,其文件存儲機制設計是衡量一個消息隊列服務技術水平和最關鍵指標之一。
下面將從Kafka文件存儲機制和物理結構角度,分析Kafka是如何實現高效文件存儲,及實際應用效果。異步
2.Kafka文件存儲機制jvm
Kafka部分名詞解釋以下:socket
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文件元數據佔用空間大小。