點評一下先：kafka的存儲主要有幾個特點：
1. 多級索引（名義上是1級索引，但是這級索引依賴了文件列表，相當於文件列表是第一級索引，所以是二級索引），二級索引文件和數據文件一一對應。
相比只有1級索引，這樣可以支持更大的數據量，也可以更好的支持刪除。如果我來設計這個存儲系統，我會這樣設計：
第一級索引：只有1個文件，文件名固定，保存數據文件名和這個數據文件保存的第1個消息的id。數據文件名如果采用數字依次編號法，那么無需存儲數據文件名，這個索引文件只需要在第1個8字節保存數據文件的起始編號，然后每8個字節保存數據文件保存的第一個消息id即可。文件格式：
| 16 | 表示第一個數據文件名字為16 |
| 1001234 | 表示名稱為16的數據文件保存的第一個消息的sqn是1001234 |
| 1790321 | 表示名稱為17的數據文件保存的第一個消息的sqn是1790321 |
| 2322233 | 表示名稱為18的數據文件保存的第一個消息的sqn是2322233 |
如果想獲取sqn=1900000的數據，首先在這個索引文件中折半查找，可以知道文件的名字為16+1
一級索引占用的內存極小，每增加一個數據文件，僅需要增加8字節，如果數據文件的大小為100M，那么1T的數據文件，1級索引只需要80K，因此可以放到內存中，增加了數據文件時寫入磁盤。當刪除數據文件時，可以重建一級索引寫回磁盤即可
2. kafka的二級索引使用了稀疏索引，就是說kafka並沒有存儲所有消息在數據文件中的偏移，而是存儲了一組連續消息在數據文件中的偏移，舉個列子，0-999的消息，二級索引可能是這樣的：
| 0 | 0 |
| 132 | 21042 |
| 247 | 45186 |
| 367 | 76256 |
這樣如果想查找第178號消息，可以看出需要數據文件取出[21042, 45186)的部分，再從這段數據中找到第178號消息。
稀疏索引可以使得索引文件非常小，但是增加了查找消息的時間。
如果隨機查找消息的場景很少，這樣做是非常合適的。
3. 對於相同的消息，如果發送的不同的主題，kafka是冗余存儲的，是否可以換一種方式，比如通過索引指向同一個數據文件呢？
這種方案可以節省磁盤空間，但是會導致原來的順序讀取變成隨機讀取，基本上沒有可行性。
Kafka是什么
Kafka是最初由Linkedin公司開發，是一個分布式、分區的、多副本的、多訂閱者，基於zookeeper協調的分布式日志系統(也可以當做MQ系統)，常見可以用於web/nginx日志、訪問日志，消息服務等等，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文件元數據占用空間大小。