Kafka 為什麼能那麼快 | Kafka高效讀寫數據的原因

無論 kafka 作為 MQ 也好，作為存儲層也罷，無非就是兩個功能（好簡單的樣子），一是 Producer 生產的數據存到 broker，二是 Consumer 從 broker 讀取數據。那 Kafka 的快也就體現在讀寫兩個方面了，下面我們就聊聊 Kafka 快的原因。

1. 利用 Partition 實現並行處理

我們都知道 Kafka 是一個 Pub-Sub 的消息系統，無論是發布還是訂閱，都要指定 Topic。

Topic 只是一個邏輯的概念。每個 Topic 都包含一個或多個 Partition，不同 Partition 可位於不同節點。

一方面，由於不同 Partition 可位於不同機器，因此可以充分利用集群優勢，實現機器間的並行處理。另一方面，由於 Partition 在物理上對應一個文件夾，即使多個 Partition 位於同一個節點，也可通過配置讓同一節點上的不同 Partition 置於不同的磁碟上，從而實現磁碟間的並行處理，充分發揮多磁碟的優勢。

能並行處理，速度肯定會有提升，多個工人肯定比一個工人乾的快。

可以並行寫入不同的磁碟？那磁碟讀寫的速度可以控制嗎？

那就先簡單扯扯磁碟/IO 的那些事

硬碟性能的制約因素是什麼？如何根據磁碟I/O特性來進行系統設計？

硬碟內部主要部件為磁碟碟片、傳動手臂、讀寫磁頭和主軸馬達。實際數據都是寫在碟片上，讀寫主要是通過傳動手臂上的讀寫磁頭來完成。實際運行時，主軸讓磁碟碟片轉動，然後傳動手臂可伸展讓讀取頭在碟片上進行讀寫操作。磁碟物理結構如下圖所示：

由於單一碟片容量有限，一般硬碟都有兩張以上的碟片，每個碟片有兩面，都可記錄資訊，所以一張碟片對應著兩個磁頭。碟片被分為許多扇形的區域，每個區域叫一個扇區。碟片表面上以碟片中心為圓心，不同半徑的同心圓稱為磁軌，不同碟片相同半徑的磁軌所組成的圓柱稱為柱面。磁軌與柱面都是表示不同半徑的圓，在許多場合，磁軌和柱面可以互換使用。磁碟碟片垂直視角如下圖所示：

影響磁碟的關鍵因素是磁碟服務時間，即磁碟完成一個I/O請求所花費的時間，它由尋道時間、旋轉延遲和數據傳輸時間三部分構成。

機械硬碟的連續讀寫性能很好，但隨機讀寫性能很差，這主要是因為磁頭移動到正確的磁軌上需要時間，隨機讀寫時，磁頭需要不停的移動，時間都浪費在了磁頭定址上，所以性能不高。衡量磁碟的重要主要指標是IOPS和吞吐量。

在許多的開源框架如 Kafka、HBase 中，都通過追加寫的方式來儘可能的將隨機 I/O 轉換為順序 I/O，以此來降低定址時間和旋轉延時，從而最大限度的提高 IOPS。

感興趣的同學可以看看 磁碟I/O那些事

磁碟讀寫的快慢取決於你怎麼使用它，也就是順序讀寫或者隨機讀寫。

2. 順序寫磁碟

Kafka 中每個分區是一個有序的，不可變的消息序列，新的消息不斷追加到 partition 的末尾，這個就是順序寫。

很久很久以前就有人做過基準測試：《每秒寫入2百萬（在三台廉價機器上）》//ifeve.com/benchmarking-apache-kafka-2-million-writes-second-three-cheap-machines/

由於磁碟有限，不可能保存所有數據，實際上作為消息系統 Kafka 也沒必要保存所有數據，需要刪除舊的數據。又由於順序寫入的原因，所以 Kafka 採用各種刪除策略刪除數據的時候，並非通過使用「讀 – 寫」模式去修改文件，而是將 Partition 分為多個 Segment，每個 Segment 對應一個物理文件，通過刪除整個文件的方式去刪除 Partition 內的數據。這種方式清除舊數據的方式，也避免了對文件的隨機寫操作。

3. 充分利用 Page Cache

引入 Cache 層的目的是為了提高 Linux 作業系統對磁碟訪問的性能。Cache 層在記憶體中快取了磁碟上的部分數據。當數據的請求到達時，如果在 Cache 中存在該數據且是最新的，則直接將數據傳遞給用戶程式，免除了對底層磁碟的操作，提高了性能。Cache 層也正是磁碟 IOPS 為什麼能突破 200 的主要原因之一。

在 Linux 的實現中，文件 Cache 分為兩個層面，一是 Page Cache，另一個 Buffer Cache，每一個 Page Cache 包含若干 Buffer Cache。Page Cache 主要用來作為文件系統上的文件數據的快取來用，尤其是針對當進程對文件有 read/write 操作的時候。Buffer Cache 則主要是設計用來在系統對塊設備進行讀寫的時候，對塊進行數據快取的系統來使用。

使用 Page Cache 的好處：

• I/O Scheduler 會將連續的小塊寫組裝成大塊的物理寫從而提高性能

• I/O Scheduler 會嘗試將一些寫操作重新按順序排好，從而減少磁碟頭的移動時間

• 充分利用所有空閑記憶體（非 JVM 記憶體）。如果使用應用層 Cache（即 JVM 堆記憶體），會增加 GC 負擔

• 讀操作可直接在 Page Cache 內進行。如果消費和生產速度相當，甚至不需要通過物理磁碟（直接通過 Page Cache）交換數據

• 如果進程重啟，JVM 內的 Cache 會失效，但 Page Cache 仍然可用

Broker 收到數據後，寫磁碟時只是將數據寫入 Page Cache，並不保證數據一定完全寫入磁碟。從這一點看，可能會造成機器宕機時，Page Cache 內的數據未寫入磁碟從而造成數據丟失。但是這種丟失只發生在機器斷電等造成作業系統不工作的場景，而這種場景完全可以由 Kafka 層面的 Replication 機制去解決。如果為了保證這種情況下數據不丟失而強制將 Page Cache 中的數據 Flush 到磁碟，反而會降低性能。也正因如此，Kafka 雖然提供了 flush.messages 和 flush.ms 兩個參數將 Page Cache 中的數據強制 Flush 到磁碟，但是 Kafka 並不建議使用。

4. 零拷貝技術

Kafka 中存在大量的網路數據持久化到磁碟（Producer 到 Broker）和磁碟文件通過網路發送（Broker 到 Consumer）的過程。這一過程的性能直接影響 Kafka 的整體吞吐量。

作業系統的核心是內核，獨立於普通的應用程式，可以訪問受保護的記憶體空間，也有訪問底層硬體設備的許可權。

為了避免用戶進程直接操作內核，保證內核安全，作業系統將虛擬記憶體劃分為兩部分，一部分是內核空間（Kernel-space），一部分是用戶空間（User-space）。

傳統的 Linux 系統中，標準的 I/O 介面（例如read，write）都是基於數據拷貝操作的，即 I/O 操作會導致數據在內核地址空間的緩衝區和用戶地址空間的緩衝區之間進行拷貝，所以標準 I/O 也被稱作快取 I/O。這樣做的好處是，如果所請求的數據已經存放在內核的高速緩衝存儲器中，那麼就可以減少實際的 I/O 操作，但壞處就是數據拷貝的過程，會導致 CPU 開銷。

我們把 Kafka 的生產和消費簡化成如下兩個過程來看：

1. 網路數據持久化到磁碟 (Producer 到 Broker)
2. 磁碟文件通過網路發送（Broker 到 Consumer）

4.1 網路數據持久化到磁碟 (Producer 到 Broker)

傳統模式下，數據從網路傳輸到文件需要 4 次數據拷貝、4 次上下文切換和兩次系統調用。

data = socket.read()// 讀取網路數據 
File file = new File() 
file.write(data)// 持久化到磁碟 
file.flush()

這一過程實際上發生了四次數據拷貝：

1. 首先通過 DMA copy 將網路數據拷貝到內核態 Socket Buffer
2. 然後應用程式將內核態 Buffer 數據讀入用戶態（CPU copy）
3. 接著用戶程式將用戶態 Buffer 再拷貝到內核態（CPU copy）
4. 最後通過 DMA copy 將數據拷貝到磁碟文件

DMA（Direct Memory Access）：直接存儲器訪問。DMA 是一種無需 CPU 的參與，讓外設和系統記憶體之間進行雙向數據傳輸的硬體機制。使用 DMA 可以使系統 CPU 從實際的 I/O 數據傳輸過程中擺脫出來，從而大大提高系統的吞吐率。

同時，還伴隨著四次上下文切換，如下圖所示

數據落盤通常都是非實時的，kafka 生產者數據持久化也是如此。Kafka 的數據並不是實時的寫入硬碟，它充分利用了現代作業系統分頁存儲來利用記憶體提高 I/O 效率，就是上一節提到的 Page Cache。

對於 kafka 來說，Producer 生產的數據存到 broker，這個過程讀取到 socket buffer 的網路數據，其實可以直接在內核空間完成落盤。並沒有必要將 socket buffer 的網路數據，讀取到應用進程緩衝區；在這裡應用進程緩衝區其實就是 broker，broker 收到生產者的數據，就是為了持久化。

在此特殊場景下：接收來自 socket buffer 的網路數據，應用進程不需要中間處理、直接進行持久化時。可以使用 mmap 記憶體文件映射。

Memory Mapped Files：簡稱 mmap，也有叫 MMFile 的，使用 mmap 的目的是將內核中讀緩衝區（read buffer）的地址與用戶空間的緩衝區（user buffer）進行映射。從而實現內核緩衝區與應用程式記憶體的共享，省去了將數據從內核讀緩衝區（read buffer）拷貝到用戶緩衝區（user buffer）的過程。它的工作原理是直接利用作業系統的 Page 來實現文件到物理記憶體的直接映射。完成映射之後你對物理記憶體的操作會被同步到硬碟上。

使用這種方式可以獲取很大的 I/O 提升，省去了用戶空間到內核空間複製的開銷。

mmap 也有一個很明顯的缺陷——不可靠，寫到 mmap 中的數據並沒有被真正的寫到硬碟，作業系統會在程式主動調用 flush 的時候才把數據真正的寫到硬碟。Kafka 提供了一個參數——producer.type 來控制是不是主動flush；如果 Kafka 寫入到 mmap 之後就立即 flush 然後再返回 Producer 叫同步(sync)；寫入 mmap 之後立即返回 Producer 不調用 flush 就叫非同步(async)，默認是 sync。

零拷貝（Zero-copy）技術指在電腦執行操作時，CPU 不需要先將數據從一個記憶體區域複製到另一個記憶體區域，從而可以減少上下文切換以及 CPU 的拷貝時間。

它的作用是在數據報從網路設備到用戶程式空間傳遞的過程中，減少數據拷貝次數，減少系統調用，實現 CPU 的零參與，徹底消除 CPU 在這方面的負載。

目前零拷貝技術主要有三種類型：

• 直接I/O：數據直接跨過內核，在用戶地址空間與I/O設備之間傳遞，內核只是進行必要的虛擬存儲配置等輔助工作；
• 避免內核和用戶空間之間的數據拷貝：當應用程式不需要對數據進行訪問時，則可以避免將數據從內核空間拷貝到用戶空間
• mmap
• sendfile
• splice && tee
• sockmap
• copy on write：寫時拷貝技術，數據不需要提前拷貝，而是當需要修改的時候再進行部分拷貝。

4.2 磁碟文件通過網路發送（Broker 到 Consumer）

傳統方式實現：先讀取磁碟、再用 socket 發送，實際也是進過四次 copy

buffer = File.read 
Socket.send(buffer)

這一過程可以類比上邊的生產消息：

1. 首先通過系統調用將文件數據讀入到內核態 Buffer（DMA 拷貝）
2. 然後應用程式將記憶體態 Buffer 數據讀入到用戶態 Buffer（CPU 拷貝）
3. 接著用戶程式通過 Socket 發送數據時將用戶態 Buffer 數據拷貝到內核態 Buffer（CPU 拷貝）
4. 最後通過 DMA 拷貝將數據拷貝到 NIC Buffer

Linux 2.4+ 內核通過 sendfile 系統調用，提供了零拷貝。數據通過 DMA 拷貝到內核態 Buffer 後，直接通過 DMA 拷貝到 NIC Buffer，無需 CPU 拷貝。這也是零拷貝這一說法的來源。除了減少數據拷貝外，因為整個讀文件 – 網路發送由一個 sendfile 調用完成，整個過程只有兩次上下文切換，因此大大提高了性能。

Kafka 在這裡採用的方案是通過 NIO 的 transferTo/transferFrom 調用作業系統的 sendfile 實現零拷貝。總共發生 2 次內核數據拷貝、2 次上下文切換和一次系統調用，消除了 CPU 數據拷貝

5. 批處理

在很多情況下，系統的瓶頸不是 CPU 或磁碟，而是網路IO。

因此，除了作業系統提供的低級批處理之外，Kafka 的客戶端和 broker 還會在通過網路發送數據之前，在一個批處理中累積多條記錄 (包括讀和寫)。記錄的批處理分攤了網路往返的開銷，使用了更大的數據包從而提高了頻寬利用率。

6. 數據壓縮

Producer 可將數據壓縮後發送給 broker，從而減少網路傳輸代價，目前支援的壓縮演算法有：Snappy、Gzip、LZ4。數據壓縮一般都是和批處理配套使用來作為優化手段的。

小總結 | 下次面試官問我 kafka 為什麼快，我就這麼說

• partition 並行處理
• 順序寫磁碟，充分利用磁碟特性
• 利用了現代作業系統分頁存儲 Page Cache 來利用記憶體提高 I/O 效率
• 採用了零拷貝技術
• Producer 生產的數據持久化到 broker，採用 mmap 文件映射，實現順序的快速寫入
• Customer 從 broker 讀取數據，採用 sendfile，將磁碟文件讀到 OS 內核緩衝區後，轉到 NIO buffer進行網路發送，減少 CPU 消耗