我們都知道Kafka非常快，比絕大多數的市場上其他消息中間件都要快。這裡來研究下那麼為什麼Kafka那麼快（當然不會是因為它用了Scala）。
Kafka的消息是保存或緩存在磁盤上的，一般認為在磁盤上讀寫數據是會降低性能的，因為尋址會比較消耗時間。
但是實際上，Kafka其中一個特性卻是高吞吐率，即使是普通的服務器，Kafka也能輕鬆支持每秒百萬級的寫入請求，超過了大部分的消息中間件。這種特性使得Kafka在日誌處理等海量數據場景中應用廣泛。那麼為什麼Kafka速度那麼快，可以從數據寫入和數據讀取兩方面來分析。
Kafka的數據寫入（生產者）
生產者（Producer）是負責向Kafka提交數據的，Kafka會把收到的消息都寫入到磁盤中，因此可以認為它絕對不會丟失數據。
而為了優化寫入速度，Kafka採用了兩種技術，一種是順序寫入，一種是MMFile。
順序寫入
磁盤讀寫的快慢取決於你怎麼使用它，一般可以分為順序讀寫或者隨機讀寫。
因為硬盤是機械結構，每次讀寫都會經過一個【尋址->寫入】的過程，其中的尋址是一個十分耗時的機械動作，所以硬盤最討厭隨機I/O，最喜歡順序I/O。為了提高讀寫硬盤的速度，Kafka就是使用的順序I/O。而且Linux對於磁盤的讀寫優化也比較多，包括read-ahead、write-behind和磁盤緩存等。更多的，對Java的內存管理和垃圾回收會有優化，因為如果在內存做這些操作的時候，一個會導致Java對象的內存開銷很大，另一個是隨著堆內存數據的增多，Java的GC時間會變得很長。
因此可以總結出使用磁盤操作有以下幾個好處：
1.磁盤順序讀寫速度超過內存隨機讀寫。
2.JVM的GC效率低，內存佔用大，使用磁盤可以避免這一問題。
3.系統冷啟動後，磁盤上的緩存依然可用（內存一旦關機數據就會清空，持久化到磁盤上則不會）。
上圖就展示了Kafka是如何寫入數據的，每一個Partition其實都是一個文件，收到消息後Kafka會把數據插入到文件的末尾（虛線框的部分）。
但是這種方法存在一個缺陷：沒有辦法刪除數據。一次Kafka是不會刪除數據的，它只會把所有的數據都保留下來，每個消費者（Consumer）對每個Topic都有一個offset用來表示讀取到了第幾條數據。
上圖中有兩個消費者，Consumer1有兩個offset分別對應Partition0和Partition1（假設每一個Topic是一個Partition）；Consumer2有一個offset對應Partition2.這個offset是由客戶端SKD負責保存的，Kafka的Broker完全無視這個東西的存在；一般情況下SDK會把它保存到Zookeeper裡面。（所以需要給Consumer提供Zookeeper的地址）。
如果數據完全不刪除，那麼肯定會導致硬盤爆滿，所以Kafka提供了兩種策略來刪除數據，一是基於時間，二是基於Partition文件大小。具體配置可以參看它的配置文檔。
MMFiles（Memory Mapped Files）
即便是順序寫入磁盤，磁盤的訪問速度還是不可能追上內存的。所以Kafka的數據並不是實時的寫入硬盤，它充分利用了現代操作系統的分頁存儲來利用內存，以此來提高I/O效率。Memory Mapped Files（後面簡稱MMAP）也被翻譯成內存映射文件，在64位操作系統中一般可以表示20G的數據文件。它的工作原理是直接利用操作系統的Page來實現文件到物理內存的直接映射。完成映射之後，你對物理內存的操作會被同步到硬盤上（操作系統在適當的時候）。
通過MMAP，進程就可以像讀寫硬盤一樣讀寫內存（當然是虛擬機內存），也不必關係內存的大小，因為有虛擬內存為我們兜底。使用這種方式可以獲取很大的I/O提升，省去了用戶空間到內核空間複製的開銷（調用文件的read會有把數據先放到內核空間的內存中，然後再複製到用戶空間的內存中）。但是這樣也有一個很明顯的缺陷：不可靠，因為寫到MMAP中的數據並沒有被真正地寫入到硬盤中，操作系統會在程序主動調用flush命令的時候才會把數據真正地寫入到硬盤中。Kafka提供了一個參數prducer.type來控制是不是主動flush，如果Kafka寫入到MMAP之後就立即flush然後再返回Producer，就叫做同步（sync）；如果Kafka寫入到MMAP之後立即返回Producer不調用flush，就叫做異步（async）。
MMAP其實是Linux中的一個函數，就是用來實現內存映射的。Java的NIO提供了一個MappedByteBuffer類來實現內存映射（因此Kafka是沾了Java的光，而不是Scala）。
Kafka的數據讀取（消費者）
為什麼Kafka使用磁盤文件還能那麼快——一個用硬盤的比用內存的還快，這絕對違反常識，因為Kafka作弊了，無論是順序寫入還是MMAP，其實都是Kafka作弊前的準備工作。
Zero Copy
Kafka使用了基於sendfile的Zero Copy提高Web Server靜態文件的速度。
傳統模式下，從硬盤讀取一個文件是這樣的：
1.調用read函數，文件數據被copy到內核的緩衝區（read是系統調用，放到了DMA，所以用內核空間）。
2.read函數返回，文件數據從內核緩衝區copy到用戶緩衝區。
3.write函數調用，將文件數據從用戶緩衝區copy到內核與Socket相關的緩衝區。
4.數據從Socket緩衝區copy到相關協議引擎（網卡）。
以上細節是傳統的read/write方式進行網絡傳輸的方式，我們可以看到，在這個過程當中，文件數據實際上是經過了四次copy操作：硬盤—>內核buf—>用戶buf—>socket相關緩衝區—>協議引擎。而sendfile系統調用則是提供了一種減少以上多次copy，提升文件傳輸性能的方法。Kafka在內核版本2.1中，引用了sendfile系統調用，以此簡化網絡上和兩個本地文件之間的數據傳輸。sendfile的引入不僅減少了數據複製，還減少了上下文的切換：sendfile(socket, file, len)。
運行流程如下：
1.sendfile系統調用，文件數據被copy至內核緩衝區。
2.再從內核緩衝區copy至內核中socket相關的緩衝區。
3.最後再socket相關的緩衝區copy到協議引擎。
相較傳統read/write方式，2.1版本內核引進的sendfile已經減少了內核緩衝區到user緩衝區，再由user緩衝區到socket相關緩衝區的文件copy，而在內核版本2.4之後，文件描述符結果被改變，sendfile實現了更簡單的方式，再次減少了一次copy操作。
在apache，nginx，lighttpd等web服務器當中，都有一項sendfile相關的配置，使用sendfile可以大幅提升文件傳輸性能。
Kafka把所有的消息都存放在一個一個的文件中，當消費者需要數據的時候Kafka直接把文件發送給消費者，配合MMAP作為文件讀寫方式，直接把它傳給sendfile。
Java的NIO提供了FileChannle，它的transferTo()方法和transferFrom()方法就是Zero Copy。
Kafka的批量壓縮
在很多情況下，系統的瓶頸不是CPU或磁盤，而是網絡IO，對於需要在廣域網上的數據中心之間發送消息的數據流水線尤其如此。進行數據壓縮會消耗少量的CPU資源,不過對於kafka而言,網絡IO更應該需要考慮。
1.如果每個消息都壓縮，但是壓縮率相對很低，所以Kafka使用了批量壓縮，即將多個消息一起壓縮而不是單個消息壓縮。
2.Kafka允許使用遞歸的消息集合，批量的消息可以通過壓縮的形式傳輸並且在日誌中也可以保持壓縮格式，直到被消費者解壓縮。
3.Kafka支持多種壓縮協議，包括Gzip和Snappy壓縮協議。
Kafka速度快的秘密——作弊
Kafka把所有的消息都存放在一個一個的文件中，當消費者需要數據的時候Kafka直接把文件發送給消費者。這就是秘訣所在，比如：10W的消息組合在一起是10MB的數據量，然後Kafka用類似於發文件的方式直接扔出去了，如果消費者和生產者之間的網絡非常好（只要網絡稍微正常一點10MB根本不是事。。。家裡上網都是100Mbps的帶寬了），10MB可能只需要1s。所以答案是——10W的TPS，Kafka每秒鐘處理了10W條消息。
可能你會說：不可能把整個文件發出去吧？裡面還有一些不需要的消息呢？是的，Kafka作為一個【高級作弊分子】自然要把作弊做的有逼格。Zero Copy對應的是sendfile這個函數（以Linux為例），這個函數接受：
1.out_fd作為輸出（一般及時socket的句柄）。
2.in_fd作為輸入文件句柄。
3.off_t表示in_fd的偏移（從哪裡開始讀取）。
4.size_t表示讀取多少個。
沒錯，Kafka是用MMAP作為文件讀寫方式的，它就是一個文件句柄，所以直接把它傳給sendfile；偏移也好解決，用戶會自己保持這個offset，每次請求都會發送這個offset。（還記得嗎？放在zookeeper中的）；數據量更容易解決了，如果消費者想要更快，就全部扔給消費者。如果這樣做一般情況下消費者肯定直接就被 壓死了 ；所以Kafka提供了的兩種方式——Push，我全部扔給你了，你死了不管我的事情；Pull，好吧你告訴我你需要多少個，我給你多少個。
總結
Kafka速度的秘訣在於，它把所有的消息都變成一個批量的文件，並且進行合理的批量壓縮，減少網絡IO的損耗，通過MMAP提高I/O的速度。寫入數據的時候，由於單個Partition（分區）是末尾添加的所以速度最優；讀取數據的時候配合sendfile直接暴力輸入。阿里的RocketMQ也是這種模式，只不過是用Java寫的。
閱讀更多 sandag 的文章
