3臺廉價機器每秒寫入2百萬！Kafka爲何那麼快？

做者：邴越，簡介：阿里資深工程師，關注分佈式系統及高可用架構，方法論與認知升級，實踐持續學習。出處：www.cnblogs.com/binyue/p/10308754.html

30秒簡單回顧下kafka

讓咱們快速回顧一下Kafka的內容以及有關它的工做原理的一些細節。 Kafka是一種分佈式消息系統，最初是在LinkedIn創建的，如今是Apache Software Foundation的一部分，並被各類公司使用。

Kafka 的消息是保存或緩存在磁盤上的，通常認爲在磁盤上讀寫數據是會下降性能的，由於尋址會比較消耗時間，可是實際上，Kafka 的特性之一就是高吞吐率。即便是普通的服務器，Kafka 也能夠輕鬆支持每秒百萬級的寫入請求，超過了大部分的消息中間件，這種特性也使得 Kafka 在日誌處理等海量數據場景普遍應用。

通常配置很簡單。生產者將記錄發送到集羣，將其記錄，並將其交給消費者

kafka的重要抽象是主題。生產者將記錄發佈到主題，消費者訂閱一個或多個主題。 Kafka主題只是一個分片上的的預寫日誌。生產者將記錄附加到這些日誌和消費者訂閱更改。每條記錄是一個鍵/值對。其中的key用於將記錄分配給特定日誌分區（除非發佈者直接指定分區）。

這是一個簡單的例子，單一的生產者和消費者從兩個分區主題的讀和寫。

此圖顯示一個生產者進程追加到兩個分區的日誌，一個消費者從相同的日誌讀取。日誌中的每一個記錄都有一個相關的條目號，咱們稱之爲偏移量。消費者使用偏移量來描述它在每一個日誌中的位置。

這些分區分佈集羣上，容許主題容納比任何一臺機器上多的數據。

注意，與大多數消息系統不一樣，日誌始終是持久的。當收到消息時直接將其寫入文件系統。消息在讀取時不會被刪除，但按照可配置的SLA保留（好比說幾天或一週）。這容許在數據消費者可能須要從新加載數據的狀況下使用。它還能夠支持節省空間的發佈訂閱，由於不管消費者多少隻有單一共享日誌;在傳統的消息系統中，一般每一個消費者都有一個隊列，因此添加一個消費者可使你的數據量翻倍。這使得Kafka很是適合於正常消息系統外的事情，例如用做Hadoop等離線數據系統的管道。這些離線系統只能做爲週期性ETL週期的一部分間隔加載，或者可能會花費幾個小時進行維護，在此期間，若是須要，Kafka可以緩衝TB級別未消耗數據。

Kafka還經過複製日誌到多臺服務器以進行容錯。與其餘消息傳遞系統相比，副本實現的一個重要架構是複製不須要複雜的配置，這些配置僅在很是特殊的狀況下使用。假定複製是默認的：咱們將未複製數據視爲副本因子剛好爲一個的特殊狀況。

當生產者發佈包含偏移的消息時，生產者會收到確認。發佈到分區的第一條記錄返回偏移量0，第二條記錄1，並按照序列增加。消費者從偏移指定的位置消費數據，並經過按期提交將位置保存在日誌中：保存該偏移量，以防消費者實例崩潰，另外一個實例能夠從偏移的位置恢復。

但願這些有所幫助（若是沒有，你能夠在這裏閱讀更完整的kafka介紹）。

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

http://ifeve.com/benchmarking...

下面從數據寫入和讀取兩方面分析，爲何 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 直接暴力輸出。