來源：cnblogs.com/binyue/p/10308754.html

Kafka的消息是保存或緩存在磁盤上的，一般認為在磁盤上讀寫數據是會降低性能的，因為尋址會比較消耗時間，但是實際上，Kafka的特性之一就是高吞吐率。

即使是普通的服務器，Kafka也可以輕松支持每秒百萬級的寫入請求，超過了大部分的消息中間件，這種特性也使得Kafka在日志處理等海量數據場景廣泛應用。

針對Kafka的基準測試可以參考，Apache Kafka基準測試：每秒寫入2百萬（在三臺廉價機器上）

下面從數據寫入和讀取兩方面分析，為什么為什么Kafka速度這么快。

寫入數據

Kafka會把收到的消息都寫入到硬盤中，它絕對不會丟失數據。為了優化寫入速度Kafka采用了兩個技術， 順序寫入 和 MMFile 。

順序寫入

磁盤讀寫的快慢取決于你怎么使用它，也就是順序讀寫或者隨機讀寫。在順序讀寫的情況下，某些優化場景磁盤的讀寫速度可以和內存持平（注：此處有疑問， 不推敲細節，參考 http://searene.me/2017/07/09/Why-is-Kafka-so-fast/
）。
因為硬盤是機械結構，每次讀寫都會尋址->寫入，其中尋址是一個“機械動作”，它是最耗時的。所以硬盤最討厭隨機I/O，最喜歡順序I/O。為了提高讀寫硬盤的速度，Kafka就是使用順序I/O。

而且Linux對于磁盤的讀寫優化也比較多，包括read-ahead和write-behind，磁盤緩存等。如果在內存做這些操作的時候，一個是JAVA對象的內存開銷很大，另一個是隨著堆內存數據的增多，JAVA的GC時間會變得很長，使用磁盤操作有以下幾個好處：

• 磁盤順序讀寫速度超過內存隨機讀寫

• JVM的GC效率低，內存占用大。使用磁盤可以避免這一問題

• 系統冷啟動后，磁盤緩存依然可用

上圖就展示了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)。

讀取數據

Kafka在讀取磁盤時做了哪些優化？

基于sendfile實現Zero Copy

傳統模式下，當需要對一個文件進行傳輸的時候，其具體流程細節如下：

調用read函數，文件數據被copy到內核緩沖區

read函數返回，文件數據從內核緩沖區copy到用戶緩沖區

write函數調用，將文件數據從用戶緩沖區copy到內核與socket相關的緩沖區。

數據從socket緩沖區copy到相關協議引擎。

以上細節是傳統read/write方式進行網絡文件傳輸的方式，我們可以看到，在這個過程當中，文件數據實際上是經過了四次copy操作：

硬盤—>內核buf—>用戶buf—>socket相關緩沖區—>協議引擎

而sendfile系統調用則提供了一種減少以上多次copy，提升文件傳輸性能的方法。
在內核版本2.1中，引入了sendfile系統調用，以簡化網絡上和兩個本地文件之間的數據傳輸。sendfile的引入不僅減少了數據復制，還減少了上下文切換。

sendfile(socket, file, len);

運行流程如下：

sendfile系統調用，文件數據被copy至內核緩沖區

再從內核緩沖區copy至內核中socket相關的緩沖區

最后再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。

批量壓縮

在很多情況下，系統的瓶頸不是CPU或磁盤，而是網絡IO，對于需要在廣域網上的數據中心之間發送消息的數據流水線尤其如此。進行數據壓縮會消耗少量的CPU資源,不過對于kafka而言,網絡IO更應該需要考慮。

• 如果每個消息都壓縮，但是壓縮率相對很低，所以Kafka使用了批量壓縮，即將多個消息一起壓縮而不是單個消息壓縮

• Kafka允許使用遞歸的消息集合，批量的消息可以通過壓縮的形式傳輸并且在日志中也可以保持壓縮格式，直到被消費者解壓縮

• Kafka支持多種壓縮協議，包括Gzip和Snappy壓縮協議

總結

Kafka速度的秘訣在于，它把所有的消息都變成一個批量的文件，并且進行合理的批量壓縮，減少網絡IO損耗，通過mmap提高I/O速度，寫入數據的時候由于單個Partion是末尾添加所以速度最優；讀取數據的時候配合sendfile直接暴力輸出。

總結

以上是生活随笔為你收集整理的为什么 Kafka 速度那么快？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。