kafka檔案系統設計解析

檔案系統一般分為系統和使用者2種型別，系統級檔案系統:ext3,ext4,dfs,ntfs等等,，筆者並不會向大家介紹那種紛繁複雜的分散式或系統級檔案系統，而是從kafka架構高效能角度考慮，深入剖析kafka檔案系統儲存結構設計。

下面用圖形表示介紹客戶端處理幾個過程如下：

• 當建立連線請求時，首先客戶端向kafka broker傳送連線請求，broker中由Acceptor thread執行緒接收並建立連線後，把client的socket以輪詢方式轉交給相應的processor thread。
• 當client向broker傳送資料請求，由processor thread處理並接收client資料放到request緩衝區中，以待IO thread進行邏輯處理和計算並把返回result放到response緩衝區中.
  接著喚醒processor thread，processor thread抱住response佇列迴圈傳送所有response資料給client.
  

• paritions分佈規則，kafka叢集由多個kafka broker組成，一個topic的partitions會分佈在一個或多個broker上，topic的partitions在kafka叢集上分配規則為，安裝paritions索引編號依次有序分佈在broker上，
  當partitions數量 > brokers數量，會依次輪迴再次迭代分配。
  

• partitions命名規則,paritions名稱為:topic-name-index,  index分割槽索引編號，從0開始依次遞增。
  

• producer，每個producer可以傳送msg到topic任意一個或多個partitons。
  

• consumer，同一個Consumer Group中的Consumers，Kafka將相應Topic中的每個訊息只傳送給其中一個Consumer.
  

目前假如kafka叢集中只有一個broker，資料檔案目錄為message-folder，例如筆者建立一個topic名稱為：report_push,  partitions=4

儲存路徑和目錄規則為：

xxx/message-folder

                              |--report_push-0

                              |--report_push-1

                              |--report_push-2

                              |--report_push-3

形象表示圖如下：

 

每個partition（topic-name-index)目錄中儲存海量msg訊息，那它是怎麼儲存的呢？檔案儲存結構是怎樣？

這麼多(海量)訊息是儲存在一個大檔案中，類似DB那樣儲存，還是其他方式儲存結構呢？筆者後續會像剝洋蔥一樣，給大家一層一層依次分解並分析。

• 資料庫和kafka檔案系統比較，相信大家都用過資料庫，資料庫底層檔案系統相當複雜，因為資料庫特點，需要按照關鍵字，id快速查詢，修改，刪除，日誌，回滾等等。
  所以資料庫檔案系統是分頁儲存的樹形結構，需要支援大量隨機事物操作。相比資料庫支援查詢，事物等等複雜檔案，則kafka訊息佇列型別檔案系統簡單多了，kafka檔案系統儲存特點是，
  只需要支援producer和consumer順序生產和訊息就夠了，訊息(msg)生命週期由consumer決定。
  

• partiton檔案儲存結構分析，每個partition就像如上圖4，一個巨大檔案訊息資料被平均分配到多個檔案大小相等的檔案中。即相當於一個大檔案被切成很多相等大小的檔案段segment file
  (訊息數量不一定相等)。因為每個topic中訊息生命週期由最後一個consumer決定，當某個或些訊息被最後一個consumer(consumer group)訊息後，就可以刪除該訊息。顯然易見，
  

讀者從2.4節瞭解到kafka檔案系統partition儲存方式，下面向大家介紹一下partion檔案儲存中segement file組成結構。一個商業化訊息佇列的效能好壞，

其檔案系統儲存結構設計是衡量一個訊息佇列服務程式最關鍵指標之一，他也是訊息佇列中最核心且最能體現訊息佇列技術水平的部分。在本節中我們將走進segment file內部一探究竟。

segment file組成：由2大部分組成，分別為segment data file和segment index file，此2個檔案一一對應，成對出現.

segment index file索引檔案組成結構如下：

00000000000000000000.index       檔名稱，檔案串大小最大支援2^64bit

1. 
   
2. 每次記錄相應log檔案記錄的相對條數和物理偏移位置位置，共8bytes
   
3. 4byte 當前segment file offset - last seg file offset記錄條數       offset
   
4. 4byte對應segment file物理偏移地址 position
   
5. ………

複製程式碼

引數說明：

4 byte CRC32：使用crc32演算法計算除CRC32這4byte外的buffer。

1 byte “magic"：表示資料檔案協議版本號

1 byte “attributes"：表示標識獨立版本，標識壓縮型別，編碼型別。

key data：可選，可以儲存判斷或表示這個訊息塊的後設資料資訊。

payload data：訊息體，該訊息體可能會儲存多條訊息記錄，內部是按照序號有序儲存的。

圖6

segment index file：

稀疏索引方式，減少索引檔案大小，這樣可以直接記憶體操作，稀疏索引只為資料檔案的每個儲存塊設一個鍵-指標對,它比稠密索引節省了更多的儲存空間，但查詢給定值的記錄需更多的時間，通過二分查詢快速找到segment data file物理位置，如果在index file沒有找到data file具體位置，則data file相對位置繼續順序讀取查詢，直到找到為止。

圖7

同一個topic下有不同分割槽，每個分割槽下面會劃分為多個(段)檔案，只有一個當前檔案在寫，其他檔案只讀。當寫滿一個檔案（寫滿的意思是達到設定值）則切換檔案，新建一個當前檔案用來寫，老的當前檔案切換為只讀。檔案的命名以起始偏移量來命名。看一個例子，假設report_push這個topic下的0-0分割槽可能有以下這些檔案：

• 00000000000000000000.index

• 00000000000000000000.log

• 00000000000000368769.index

• 00000000000000368769.log

• 00000000000000737337.index

• 00000000000000737337.log

• 00000000000001105814.index

• 00000000000001105814.log

    ………………..

其中 00000000000000000000.index表示最開始的檔案，起始偏移量為0.第二個檔案00000000000000368769.index的訊息量起始偏移量為368769.同樣，第三個檔案00000000000000737337.index的起始偏移量為737337.

以起始偏移量命名並排序這些檔案，那麼當消費者要拉取某個訊息起始偏移量位置的資料變的相當簡單，只要根據傳上來的offset**二分查詢**檔案列表，定位到具體檔案，

然後將絕對offset減去檔案的起始節點轉化為相對offset，即可開始傳輸資料。例如，同樣以上面的例子為例，假設消費者想抓取從第368969訊息位置開始的資料，則根據368969二分查詢，

定位到00000000000000368769.log這個檔案（368969在368769和737337之間），根據索引檔案二分搜尋可以確定讀取資料最大大小。

                                                    圖8   

基本不會有磁碟讀的大量操作，都在記憶體進行，只有定期磁碟批量寫操作。

• 一個大檔案分成多個小檔案段。
• 多個小檔案段，容易定時清除或刪除已經消費完檔案，減少磁碟佔用。
• index全部對映到memory直接操作，避免segment file被交換到磁碟增加IO操作次數。
• 根據索引資訊，可以確定傳送response到consumer的最大大小。

• 索引檔案後設資料儲存用的是相對前一個segment file的offset儲存，節省空間大小。