3臺廉價機器每秒寫入2百萬！Kafka為什么那么快？

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

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

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

http: //ifeve.com /benchmarking-apache-kafka-2-million-writes-second-three-cheap-machines/

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

數據寫入

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

順序寫入

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

因為硬盤是機械結構，每次讀寫都會尋址->寫入，其中尋址是一個“機械動作”，它是最耗時的。

所以硬盤最討厭隨機 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)。

如果 Kafka 寫入 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 Socket編程

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。