【知識點】一樣是消息隊列，Kafka憑什麼速度那麼快？

一樣是消息隊列，Kafka憑什麼速度那麼快？

 

做者 | MrZhangxd

 

Kafka的消息是保存或緩存在磁盤上的，通常認爲在磁盤上讀寫數據是會下降性能的，由於尋址會比較消耗時間，可是實際上，Kafka的特性之一就是高吞吐率。

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

 

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

 

下面從數據寫入和讀取兩方面分析，爲何Kafka速度這麼快。

 

1、寫入數據

 

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

 

一、順序寫入

 

磁盤讀寫的快慢取決於你怎麼使用它，也就是順序讀寫或者隨機讀寫。在順序讀寫的狀況下，磁盤的順序讀寫速度和內存持平。

由於硬盤是機械結構，每次讀寫都會尋址->寫入，其中尋址是一個「機械動做」，它是最耗時的。因此硬盤最討厭隨機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)。 

2、讀取數據

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壓縮協議

3、總結

    Kafka速度的祕訣在於，它把全部的消息都變成一個批量的文件，而且進行合理的批量壓縮，減小網絡IO損耗，經過mmap提升I/O速度，寫入數據的時候因爲單個Partion是末尾添加因此速度最優；讀取數據的時候配合sendfile直接暴力輸出。