網上有很多Kafka的測試文章，測試結果通常都是“吊打”其他MQ。感慨它的牛B之余我覺得必要仔細分析一下它如此快速的原因。這篇文章不同於其他介紹Kafka使用或者技術實現的文章，我會重點解釋——為什么真快。（當然不是因為它用了Scala！！！！）
生產者（寫入數據）
生產者（producer）是負責向Kafka提交數據的，我們先分析這一部分。
Kafka會把收到的消息都寫入到硬盤中，它絕對不會丟失數據。為了優化寫入速度Kafak采用了兩個技術， 順序寫入 和 MMFile 。
順序寫入
因為硬盤是機械結構，每次讀寫都會尋址->寫入，其中尋址是一個“機械動作”，它是最耗時的。所以硬盤最“討厭”隨機I/O，最喜歡順序I/O。為了提高讀寫硬盤的速度，Kafka就是使用順序I/O。
上圖就展示了Kafka是如何寫入數據的， 每一個Partition其實都是一個文件 ，收到消息后Kafka會把數據插入到文件末尾（虛框部分）。
這種方法有一個缺陷—— 沒有辦法刪除數據 ，所以Kafka是不會刪除數據的，它會把所有的數據都保留下來，每個消費者（Consumer）對每個Topic都有一個offset用來表示 讀取到了第幾條數據 。
上圖中有兩個消費者，Consumer1有兩個offset分別對應Partition0、Partition1（假設每一個Topic一個Partition）；Consumer2有一個offset對應Partition2。這個offset是由客戶端SDK負責保存的，Kafka的Broker完全無視這個東西的存在；一般情況下SDK會把它保存到zookeeper里面。(所以需要給Consumer提供zookeeper的地址)。
如果不刪除硬盤肯定會被撐滿，所以Kakfa提供了兩種策略來刪除數據。一是基於時間，二是基於partition文件大小。具體配置可以參看它的配置文檔。
Memory Mapped Files
即便是順序寫入硬盤，硬盤的訪問速度還是不可能追上內存。所以Kafka的數據並 不是實時的寫入硬盤 ，它充分利用了現代操作系統 分頁存儲 來利用內存提高I/O效率。
Memory Mapped Files(后面簡稱mmap)也被翻譯成 內存映射文件 ，在64位操作系統中一般可以表示20G的數據文件，它的工作原理是直接利用操作系統的Page來實現文件到物理內存的直接映射。完成映射之后你對物理內存的操作會被同步到硬盤上（操作系統在適當的時候）。
通過mmap，進程像讀寫硬盤一樣讀寫內存（當然是虛擬機內存），也不必關心內存的大小有虛擬內存為我們兜底。
使用這種方式可以獲取很大的I/O提升， 省去了用戶空間到內核空間 復制的開銷（調用文件的read會把數據先放到內核空間的內存中，然后再復制到用戶空間的內存中。）也有一個很明顯的缺陷——不可靠， 寫到mmap中的數據並沒有被真正的寫到硬盤，操作系統會在程序主動調用flush的時候才把數據真正的寫到硬盤。 Kafka提供了一個參數——producer.type來控制是不是主動flush，如果Kafka寫入到mmap之后就立即flush然后再返回Producer叫 同步 (sync)；寫入mmap之后立即返回Producer不調用flush叫 異步 (async)。
mmap其實是Linux中的一個函數就是用來實現內存映射的，謝謝Java NIO，它給我提供了一個mappedbytebuffer類可以用來實現內存映射（所以是沾了Java的光才可以如此神速和Scala沒關系！！）
消費者（讀取數據）
Kafka使用磁盤文件還想快速？這是我看到Kafka之后的第一個疑問，ZeroMQ完全沒有任何服務器節點，也不會使用硬盤，按照道理說它應該比Kafka快。可是實際測試下來它的速度還是被Kafka“吊打”。 “一個用硬盤的比用內存的快”，這絕對違反常識；如果這種事情發生說明——它作弊了。
沒錯，Kafka“作弊”。無論是 順序寫入 還是 mmap 其實都是作弊的准備工作。
如何提高Web Server靜態文件的速度
仔細想一下，一個Web Server傳送一個靜態文件，如何優化？答案是zero copy。傳統模式下我們從硬盤讀取一個文件是這樣的
先復制到內核空間（read是系統調用，放到了DMA，所以用內核空間），然后復制到用戶空間(1,2)；從用戶空間重新復制到內核空間（你用的socket是系統調用，所以它也有自己的內核空間），最后發送給網卡（3、4）。
Zero Copy中直接從內核空間（DMA的）到內核空間（Socket的），然后發送網卡。
這個技術非常普遍，The C10K problem 里面也有很詳細的介紹，Nginx也是用的這種技術，稍微搜一下就能找到很多資料。
Java的NIO提供了FileChannle，它的transferTo、transferFrom方法就是Zero Copy。
Kafka是如何耍賴的
想到了嗎？Kafka把所有的消息都存放在一個一個的文件中， 當消費者需要數據的時候Kafka直接把“文件”發送給消費者 。這就是秘訣所在，比如： 10W的消息組合在一起是10MB的數據量，然后Kafka用類似於發文件的方式直接扔出去了，如果消費者和生產者之間的網絡非常好（只要網絡稍微正常一點10MB根本不是事。。。家里上網都是100Mbps的帶寬了），10MB可能只需要1s。所以答案是——10W的TPS，Kafka每秒鍾處理了10W條消息。
可能你說：不可能把整個文件發出去吧？里面還有一些不需要的消息呢？是的，Kafka作為一個“高級作弊分子”自然要把作弊做的有逼格。Zero Copy對應的是sendfile這個函數（以Linux為例），這個函數接受
-
out_fd作為輸出（一般及時socket的句柄）
-
in_fd作為輸入文件句柄
-
off_t表示in_fd的偏移（從哪里開始讀取）
-
size_t表示讀取多少個
沒錯，Kafka是用mmap作為文件讀寫方式的，它就是一個文件句柄，所以直接把它傳給sendfile；偏移也好解決，用戶會自己保持這個offset，每次請求都會發送這個offset。（還記得嗎？放在zookeeper中的）；數據量更容易解決了，如果消費者想要更快，就全部扔給消費者。如果這樣做一般情況下消費者肯定直接就被 壓死了 ；所以Kafka提供了的兩種方式——Push，我全部扔給你了，你死了不管我的事情；Pull，好吧你告訴我你需要多少個，我給你多少個。
總結
Kafka速度的秘訣在於，它把所有的消息都變成一個的文件。通過mmap提高I/O速度，寫入數據的時候它是末尾添加所以速度最優；讀取數據的時候配合sendfile直接暴力輸出。阿里的RocketMQ也是這種模式，只不過是用Java寫的。
單純的去測試MQ的速度沒有任何意義，Kafka這種“暴力”、“流氓”、“無恥”的做法已經脫了MQ的底褲，更像是一個暴力的“數據傳送器”。 所以對於一個MQ的評價只以速度論英雄，世界上沒人能干的過Kafka，我們設計的時候不能聽信網上的流言蜚語——“Kafka最快，大家都在用，所以我們的MQ用Kafka沒錯”。在這種思想的作用下，你可能根本不會關心“失敗者”；而實際上可能這些“失敗者”是更適合你業務的MQ。
分析過程分為以下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
在Kafka文件存儲中，同一個topic下有多個不同partition，每個partition為一個目錄，partiton命名規則為topic名稱+有序序號，第一個partiton序號從0開始，序號最大值為partitions數量減1。
2.2 partiton中文件存儲方式
下面示意圖形象說明了partition中文件存儲方式: 
- 每個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中一對segment file文件為例，說明segment中index<—->data file對應關系物理結構如下：
上述圖3中索引文件存儲大量元數據，數據文件存儲大量消息，索引文件中元數據指向對應數據文件中message的物理偏移地址。
其中以索引文件中元數據3,497為例，依次在數據文件中表示第3個message(在全局partiton表示第368772個message)、以及該消息的物理偏移地址為497。
從上述圖3了解到segment data file由許多message組成，下面詳細說明message物理結構如下：
參數說明
| 關鍵字 | 解釋說明 |
|---|---|
| 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
從上述圖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文件元數據占用空間大小。