在眾多的消息中間件中，Kafka 的性能和吞吐量絕對(duì)是頂尖級(jí)別的，那么問(wèn)題來(lái)了， Kafka 是如何做到高吞吐的。在性能優(yōu)化方面，它使用了哪些技巧呢？下面我們就來(lái)分析一下。

以'批'為單位

批量處理是一種非常有效的提升系統(tǒng)吞吐量的方法，操作系統(tǒng)提供的緩沖區(qū)也是如此。在 Kafka 內(nèi)部，消息處理是以"批"為單位的，生產(chǎn)者、Broker、消費(fèi)者，都是如此。

在 Kafka 的客戶端 SDK 中，生產(chǎn)者只提供了單條發(fā)送的 send() 方法，并沒(méi)有提供任何批量發(fā)送的接口。原因是 Kafka 根本就沒(méi)有提供單條發(fā)送的功能，是的你沒(méi)有看錯(cuò)，雖然它提供的 API 每次只能發(fā)送一條消息，但實(shí)際上 Kafka 的客戶端 SDK 在實(shí)現(xiàn)消息發(fā)送邏輯的時(shí)候，采用了異步批量發(fā)送的機(jī)制。

當(dāng)你調(diào)用 send() 方法發(fā)送一條消息之后，無(wú)論你是同步發(fā)送還是異步發(fā)送，Kafka 都不會(huì)立即就把這條消息發(fā)送出去。它會(huì)先把這條消息，存放在內(nèi)存中緩存起來(lái)，然后選擇合適的時(shí)機(jī)把緩存中的所有消息組成一批，一次性發(fā)給 Broker。簡(jiǎn)單地說(shuō)，就是攢一波一起發(fā)。

而 Kafka Broker 在收到這一批消息后，也不會(huì)將其還原成多條消息、再一條一條地處理，這樣太慢了。Kafka 會(huì)直接將"批消息"作為一個(gè)整體，也就是說(shuō)，在 Broker 整個(gè)處理流程中，無(wú)論是寫(xiě)入磁盤(pán)、從磁盤(pán)讀出來(lái)、還是復(fù)制到其他副本，在這些流程中，批消息都不會(huì)被解開(kāi)，而是一直作為一條"批消息"來(lái)進(jìn)行處理的。

在消費(fèi)時(shí)，消息同樣是以批為單位進(jìn)行傳遞的，消費(fèi)者會(huì)從 Broker 拉到一批消息。然后將批消息解開(kāi)，再一條一條交給用戶代碼處理。

比如生產(chǎn)者發(fā)送 30 條消息，在業(yè)務(wù)程序看來(lái)雖然是發(fā)送了 30 條消息，但對(duì)于 Kafka 的 Broker 來(lái)說(shuō)，它其實(shí)就是處理了 1 條包含 30 條消息的"批消息"而已。顯然處理 1 次請(qǐng)求要比處理 30 次請(qǐng)求快得多，因?yàn)闃?gòu)建批消息和解開(kāi)批消息分別在生產(chǎn)者和消費(fèi)者所在的客戶端完成，不僅減輕了 Broker 的壓力，最重要的是減少了 Broker 處理請(qǐng)求的次數(shù)，提升了總體的處理能力。

批處理只能算是一種常規(guī)的優(yōu)化手段，它是通過(guò)減少網(wǎng)絡(luò) IO 從而實(shí)現(xiàn)優(yōu)化。而 Kafka 每天要處理海量日志，那么磁盤(pán) IO 也是它的瓶頸。并且對(duì)于處在同一個(gè)內(nèi)網(wǎng)的數(shù)據(jù)中心來(lái)說(shuō)，相比讀寫(xiě)磁盤(pán)，網(wǎng)絡(luò)傳輸是非?？斓?。

接下來(lái)我們看一下，Kafka 在磁盤(pán) IO 這塊兒做了哪些優(yōu)化。

磁盤(pán)順序讀寫(xiě)

我們知道 kafka 是將消息存儲(chǔ)在文件系統(tǒng)之上的，高度依賴文件系統(tǒng)來(lái)存儲(chǔ)和緩存消息，因此可能有人覺(jué)得這樣做效率是不是很低呢？因?yàn)橐痛疟P(pán)打交道，而且使用的還是機(jī)械硬盤(pán)。

首先機(jī)械硬盤(pán)不適合隨機(jī)讀寫(xiě)，但如果是順序讀寫(xiě)，那么吞吐量實(shí)際上是不差的。在 SSD（固態(tài)硬盤(pán)）上，順序讀寫(xiě)的性能要比隨機(jī)讀寫(xiě)快幾倍，如果是機(jī)械硬盤(pán)，這個(gè)差距會(huì)達(dá)到幾十倍。因?yàn)椴僮飨到y(tǒng)每次從磁盤(pán)讀寫(xiě)數(shù)據(jù)的時(shí)候，需要先尋址，也就是先要找到數(shù)據(jù)在磁盤(pán)上的物理位置，然后再進(jìn)行數(shù)據(jù)讀寫(xiě)。如果是機(jī)械硬盤(pán)，這個(gè)尋址需要比較長(zhǎng)的時(shí)間，因?yàn)樗苿?dòng)磁頭，這是個(gè)機(jī)械運(yùn)動(dòng)，機(jī)械硬盤(pán)工作的時(shí)候會(huì)發(fā)出咔咔的聲音，就是移動(dòng)磁頭發(fā)出的聲音。

順序讀寫(xiě)相比隨機(jī)讀寫(xiě)省去了大部分的尋址時(shí)間，因?yàn)樗灰獙ぶ芬淮危涂梢赃B續(xù)地讀寫(xiě)下去，所以說(shuō)性能要比隨機(jī)讀寫(xiě)好很多。

而 kafka 正是利用了這個(gè)特性，任何發(fā)布到分區(qū)的消息都會(huì)被追加到 "分區(qū)數(shù)據(jù)文件" 的尾部，如果一個(gè)文件寫(xiě)滿了，就創(chuàng)建一個(gè)新的文件繼續(xù)寫(xiě)。消費(fèi)的時(shí)候，也是從某個(gè)全局的位置開(kāi)始，也就是某一個(gè) log 文件中的某個(gè)位置開(kāi)始，順序地把消息讀出來(lái)。這樣的順序?qū)懖僮髯?kafka 的效率非常高。

使用 PageCache

任何系統(tǒng)，不管大小，如果想提升性能，使用緩存永遠(yuǎn)是一個(gè)不錯(cuò)的選擇，而 PageCache 就是操作系統(tǒng)在內(nèi)存中給磁盤(pán)上的文件建立的緩存，它是由內(nèi)核托管的。無(wú)論我們使用什么語(yǔ)言，編寫(xiě)的程序在調(diào)用系統(tǒng)的 API 讀寫(xiě)文件的時(shí)候，并不會(huì)直接去讀寫(xiě)磁盤(pán)上的文件，應(yīng)用程序?qū)嶋H操作的都是 PageCache，也就是文件在內(nèi)存中緩存的副本。

應(yīng)用程序在寫(xiě)入文件的時(shí)候，操作系統(tǒng)會(huì)先把數(shù)據(jù)寫(xiě)入到內(nèi)存中的 PageCache，然后再一批一批地寫(xiě)到磁盤(pán)上。讀取文件的時(shí)候，也是從 PageCache 中來(lái)讀取數(shù)據(jù)，這時(shí)候會(huì)出現(xiàn)兩種可能情況。

一種是 PageCache 中有數(shù)據(jù)，那就直接讀取，這樣就節(jié)省了從磁盤(pán)上讀取的時(shí)間；另一種情況是，PageCache 中沒(méi)有數(shù)據(jù)，這時(shí)候操作系統(tǒng)會(huì)引發(fā)一個(gè)缺頁(yè)中斷，應(yīng)用程序的讀取線程會(huì)被阻塞，操作系統(tǒng)把數(shù)據(jù)從文件復(fù)制到 PageCache 中，然后應(yīng)用程序再?gòu)?PageCache 繼續(xù)把數(shù)據(jù)讀出來(lái)，這時(shí)會(huì)真正讀一次磁盤(pán)上的文件，這個(gè)讀的過(guò)程就會(huì)比較慢。

用戶的應(yīng)用程序在使用完某塊 PageCache 后，操作系統(tǒng)并不會(huì)立刻就清除這個(gè) PageCache，而是盡可能地利用空閑的物理內(nèi)存保存這些 PageCache，除非系統(tǒng)內(nèi)存不夠用，操作系統(tǒng)才會(huì)清理掉一部分 PageCache。清理的策略一般是 LRU 或它的變種算法，核心邏輯就是：優(yōu)先保留最近一段時(shí)間最常使用的那些 PageCache。

另外 PageCache 還有預(yù)讀功能，假設(shè)我們讀取了 1M 的內(nèi)容，但 Linux 實(shí)際讀取的卻并不止 1M，因?yàn)檫@樣你后續(xù)再讀取的時(shí)候就不需要從磁盤(pán)上加載了。因?yàn)閺拇疟P(pán)到內(nèi)存的數(shù)據(jù)傳輸速度是很慢的，如果物理內(nèi)存有空余，那么就可以多緩存一些內(nèi)容。

而 Kafka 在讀寫(xiě)消息文件的時(shí)候，充分利用了 PageCache 的特性。一般來(lái)說(shuō)，消息剛剛寫(xiě)入到服務(wù)端就會(huì)被消費(fèi)，讀取的時(shí)候，對(duì)于這種剛剛寫(xiě)入的 PageCache，命中的幾率會(huì)非常高。也就是說(shuō)，大部分情況下，消費(fèi)讀消息都會(huì)命中 PageCache，帶來(lái)的好處有兩個(gè)：一個(gè)是讀取的速度會(huì)非常快，另外一個(gè)是，給寫(xiě)入消息讓出磁盤(pán)的 IO 資源，間接也提升了寫(xiě)入的性能。

ZeroCopy（零拷貝）

Kafka 還使用了零拷貝技術(shù)，首先 Broker 將消息發(fā)送給消費(fèi)者的過(guò)程如下：

• 將指定的消息日志從文件讀到內(nèi)存中；
• 將消息通過(guò)網(wǎng)絡(luò)發(fā)送給消費(fèi)者客戶端；

這個(gè)過(guò)程會(huì)經(jīng)歷幾次復(fù)制，以及用戶空間和內(nèi)核空間的切換，示意圖如下。

整個(gè)過(guò)程大概是以上 6 個(gè)步驟，我們分別解釋一下。

1）應(yīng)用程序要讀取磁盤(pán)文件，但只有內(nèi)核才能操作硬件設(shè)備，所以此時(shí)會(huì)從用戶空間切換到內(nèi)核空間。

2）通過(guò) DMA 將文件讀到 PageCache 中，此時(shí)的數(shù)據(jù)拷貝是由 DMA 來(lái)做的，不耗費(fèi) CPU。關(guān)于 DMA，它是一種允許硬件系統(tǒng)訪問(wèn)計(jì)算機(jī)內(nèi)存的技術(shù)，說(shuō)白了就是給 CPU 打工的，幫 CPU 干一些搬運(yùn)數(shù)據(jù)的簡(jiǎn)單工作。

CPU 告訴 DMA 自己需要哪些數(shù)據(jù)，然后 DMA 負(fù)責(zé)搬運(yùn)到 PageCache，等搬運(yùn)完成后，DMA 控制器再通過(guò)中斷通知 CPU，這樣就極大地節(jié)省了 CPU 的資源。

但如果要讀取的內(nèi)容已經(jīng)命中 PageCache，那么這一步可以省略。

3）將文件內(nèi)容從 PageCache 拷貝到用戶空間中，因?yàn)閼?yīng)用程序在用戶空間，磁盤(pán)數(shù)據(jù)必須從內(nèi)核空間搬運(yùn)到用戶空間，應(yīng)用程序才能操作它。注意：這一步的數(shù)據(jù)搬運(yùn)不再由 DMA 負(fù)責(zé)，而是由 CPU 負(fù)責(zé)。

因?yàn)?DMA 主要用于硬件設(shè)備與內(nèi)存之間的數(shù)據(jù)傳輸，例如從磁盤(pán)到 RAM，從 RAM 到網(wǎng)卡。雖然 DMA 可以減少 CPU 的負(fù)擔(dān)，但通常不用于內(nèi)核空間和用戶空間之間的數(shù)據(jù)搬運(yùn)，至于原因也很簡(jiǎn)單：

• 操作系統(tǒng)需要保護(hù)內(nèi)核空間，防止用戶程序直接訪問(wèn)，以維護(hù)系統(tǒng)的安全和穩(wěn)定。通過(guò) CPU 進(jìn)行數(shù)據(jù)拷貝，操作系統(tǒng)可以控制哪些數(shù)據(jù)和資源可以被用戶程序訪問(wèn)。
• CPU 可以處理復(fù)雜的邏輯和任務(wù)調(diào)度，更適合執(zhí)行這種涉及系統(tǒng)安全和資源管理的任務(wù)。
• 在數(shù)據(jù)從內(nèi)核空間傳輸?shù)接脩艨臻g的過(guò)程中，可能需要進(jìn)行一些額外的處理，例如格式轉(zhuǎn)換、權(quán)限檢查等，這些都是 CPU 更擅長(zhǎng)的。

另外用戶空間和內(nèi)核空間的切換，本質(zhì)上就是 CPU 的執(zhí)行上下文和權(quán)限級(jí)別發(fā)生了改變。

因此這一步會(huì)涉及用戶態(tài)和內(nèi)核態(tài)之間的切換，和一個(gè)數(shù)據(jù)的拷貝。

4) 文件內(nèi)容讀取之后，要通過(guò)網(wǎng)絡(luò)發(fā)送給消費(fèi)者客戶端。而內(nèi)核提供了一個(gè) Socket 緩沖區(qū)，位于用戶空間的應(yīng)用程序在發(fā)送數(shù)據(jù)時(shí)，會(huì)先通過(guò) CPU 將數(shù)據(jù)拷貝到內(nèi)核空間的 Socket 緩沖區(qū)中，再由內(nèi)核通過(guò)網(wǎng)卡發(fā)送給消費(fèi)者。

同樣的，當(dāng)數(shù)據(jù)從網(wǎng)絡(luò)到達(dá)時(shí)，也會(huì)先被放在 Socket 緩沖區(qū)中。應(yīng)用程序從該緩沖區(qū)讀取數(shù)據(jù)，數(shù)據(jù)被拷貝到用戶空間。

所以應(yīng)用程序在通過(guò)網(wǎng)絡(luò)收發(fā)數(shù)據(jù)時(shí)，其實(shí)都是在和 Socket 緩沖區(qū)打交道，具體的發(fā)送和接收任務(wù)都是由內(nèi)核來(lái)做的，因?yàn)橹挥袃?nèi)核才能操作硬件設(shè)備。用戶空間的代碼要想與硬件設(shè)備交互，必須通過(guò)系統(tǒng)調(diào)用或操作系統(tǒng)提供的其它接口，然后由內(nèi)核代為執(zhí)行。

所以通過(guò)網(wǎng)絡(luò)發(fā)送數(shù)據(jù)，會(huì)涉及一次數(shù)據(jù)的拷貝，以及用戶空間和內(nèi)核空間的切換。因?yàn)?CPU 要將數(shù)據(jù)從用戶空間搬運(yùn)到內(nèi)核空間的 Socket 緩沖區(qū)中。

5) 內(nèi)核要將 Socket 緩沖區(qū)里的數(shù)據(jù)通過(guò)網(wǎng)卡發(fā)送出去，于是再將數(shù)據(jù)從 Socket 緩沖區(qū)搬到網(wǎng)卡的緩沖區(qū)里面，而這一步搬運(yùn)是由 DMA 來(lái)做的。只要不涉及用戶空間，大部分的數(shù)據(jù)搬運(yùn)都可以由 DMA 來(lái)做，而一旦涉及到用戶空間，數(shù)據(jù)搬運(yùn)就必須由 CPU 來(lái)做。

6) 發(fā)送完畢之后，再?gòu)膬?nèi)核空間切換到用戶空間，應(yīng)用程序繼續(xù)干其它事情。

如果想要提升性能，那么關(guān)鍵就在于減少上下文切換的次數(shù)和數(shù)據(jù)拷貝的次數(shù)，因?yàn)橛脩艨臻g和內(nèi)核空間的切換是需要成本的，至于數(shù)據(jù)拷貝就更不用說(shuō)了。

而整個(gè)過(guò)程涉及了 4 次的上下文切換，因?yàn)橛脩艨臻g沒(méi)有權(quán)限操作磁盤(pán)或網(wǎng)卡，這些操作都需要交由操作系統(tǒng)內(nèi)核來(lái)完成。而通過(guò)內(nèi)核去完成某些任務(wù)的時(shí)候，需要使用操作系統(tǒng)提供的系統(tǒng)調(diào)用函數(shù)。而一次系統(tǒng)調(diào)用必然會(huì)發(fā)生兩次上下文切換：首先從用戶態(tài)切換到內(nèi)核態(tài)，當(dāng)內(nèi)核執(zhí)行完任務(wù)后，再切換回用戶態(tài)交由應(yīng)用程序執(zhí)行其它代碼。

然后是數(shù)據(jù)拷貝，這個(gè)數(shù)據(jù)也被拷貝了 4 次，其中兩次拷貝由 DMA 負(fù)責(zé)，另外兩次由 CPU 負(fù)責(zé)。但很明顯，CPU 的兩次拷貝沒(méi)有太大必要，先將數(shù)據(jù)從 PageCache 拷貝到用戶空間，然后再?gòu)挠脩艨臻g拷貝到 Socket 緩沖區(qū)。既然這樣的話，那直接從 PageCache 拷貝到 Socket 緩沖區(qū)不行嗎。

如果文件在讀取之后不對(duì)它進(jìn)行操作，或者說(shuō)不對(duì)文件數(shù)據(jù)進(jìn)行加工，只是單純地通過(guò)網(wǎng)卡發(fā)送出去，那么就沒(méi)必要到用戶空間這里繞一圈。

此時(shí)的 4 次上下文切換就變成了 2 次，因?yàn)橄到y(tǒng)調(diào)用只有 1 次。數(shù)據(jù)搬運(yùn)也由 4 次變成了 3 次，所以總共減少了兩次上下文切換和一次數(shù)據(jù)拷貝。

而這種減少數(shù)據(jù)拷貝（特別是在用戶和內(nèi)核之間的數(shù)據(jù)拷貝）的技術(shù)，便稱之為零拷貝。

Linux 內(nèi)核提供了一個(gè)系統(tǒng)調(diào)用函數(shù) sendfile()，便可以實(shí)現(xiàn)上面這個(gè)過(guò)程。

#include <sys/sendfile.h>

ssize_t sendfile(int out_fd, int in_fd, 
                 off_t *offset, size_t count);

out_fd 和 in_fd 均為文件描述符，分別代表要寫(xiě)入的文件和要讀取的文件，offset 表示從文件的哪個(gè)位置開(kāi)始讀，count 表示寫(xiě)入多少個(gè)字節(jié)。返回值是實(shí)際寫(xiě)入的長(zhǎng)度。

當(dāng)然像 Python、Java 都對(duì) sendfile 進(jìn)行了封裝，我們?cè)谑褂?Python 進(jìn)行 Socket 編程時(shí)，便可以使用該方法。

當(dāng)然該方法會(huì)調(diào)用 os.sendfile()，它和 C 的 sendfile() 是一致的，如果是 Linux 系統(tǒng)，那么不存在問(wèn)題。如果是 Windows 系統(tǒng)，os.sendfile() 則不可用，此時(shí) Socket 的 sendfile 會(huì)退化為 send 方法。

然而目前來(lái)說(shuō)，雖然實(shí)現(xiàn)了零拷貝，但還不是零拷貝的終極形態(tài)。我們看到 CPU 還是進(jìn)行了一次拷貝，并且此時(shí)雖然不涉及用戶空間，但數(shù)據(jù)搬運(yùn)依舊是 CPU 來(lái)做的。因?yàn)?DMA 主要負(fù)責(zé)硬件（例如磁盤(pán)或網(wǎng)卡）和內(nèi)存的數(shù)據(jù)傳輸，但不適用于內(nèi)存到內(nèi)存的數(shù)據(jù)拷貝。

那么問(wèn)題來(lái)了，數(shù)據(jù)文件從磁盤(pán)讀到 PageCache 之后，可不可以直接搬到網(wǎng)卡緩沖區(qū)里面呢？如果你的網(wǎng)卡支持 SG-DMA 技術(shù)，那么通過(guò) CPU 將數(shù)據(jù)從 PageCache 拷貝到 socket 緩沖區(qū)這一步也可以省略。

你可以通過(guò)以下命令，查看網(wǎng)卡是否支持 SG（scatter-gather）特性：

[root@satori ~]# ethtool -k eth0 | grep scatter-gather
scatter-gather: on
 tx-scatter-gather: on
 tx-scatter-gather-fraglist: off [fixed]

Linux 內(nèi)核從 2.4 版本開(kāi)始起，對(duì)于那些支持 SG-DMA 技術(shù)的網(wǎng)卡，會(huì)進(jìn)一步優(yōu)化 sendfile() 系統(tǒng)調(diào)用的過(guò)程，優(yōu)化后的過(guò)程如下：

• DMA 將數(shù)據(jù)從磁盤(pán)拷貝到 PageCache；
• 將描述符和數(shù)據(jù)長(zhǎng)度發(fā)送到 Socket 緩沖區(qū)，網(wǎng)卡的 SG-DMA 控制器基于該信息直接將 PageCache 的數(shù)據(jù)拷貝到網(wǎng)卡緩沖區(qū)中；

整個(gè)過(guò)程如下：

此時(shí)便是零拷貝（Zero-copy）技術(shù)的終極形態(tài)，因?yàn)槲覀儧](méi)有在內(nèi)存層面去拷貝數(shù)據(jù)，也就是說(shuō)全程沒(méi)有通過(guò) CPU 來(lái)搬運(yùn)數(shù)據(jù)，所有的數(shù)據(jù)都是通過(guò) DMA 來(lái)進(jìn)行傳輸?shù)摹?/span>

使用零拷貝技術(shù)只需要兩次上下文切換和數(shù)據(jù)拷貝，就可以完成文件的傳輸，因?yàn)樗ㄟ^(guò)一次系統(tǒng)調(diào)用（sendfile 方法）將磁盤(pán)讀取與網(wǎng)絡(luò)發(fā)送兩個(gè)操作給合并了，從而降低了上下文切換次數(shù)。而且兩次的數(shù)據(jù)拷貝過(guò)程也不需要通過(guò) CPU，都是由 DMA 來(lái)搬運(yùn)。所以總體來(lái)看，零拷貝技術(shù)可以把文件傳輸?shù)男阅芴岣咧辽僖槐兑陨稀?/span>

但需要注意的是，零拷貝技術(shù)不允許進(jìn)程對(duì)文件內(nèi)容作進(jìn)一步加工，比如壓縮數(shù)據(jù)再發(fā)送。如果希望對(duì)讀取的文件內(nèi)容做額外的操作，那么就只能拷貝到用戶空間了。

另外當(dāng)傳輸大文件時(shí)，不建議使用零拷貝，因?yàn)?PageCache 可能被大文件占據(jù)，而導(dǎo)致「熱點(diǎn)」小文件無(wú)法利用到 PageCache，并且大文件的緩存命中率也不高，因此這種情況建議繞過(guò) PageCache。

使用 PageCache 的 IO 叫做緩存 IO，不使用 PageCache 的 IO 叫做直接 IO。

小結(jié)

以上我們就探討了 Kafka 為什么會(huì)有如此高的吞吐量，在處理海量數(shù)據(jù)時(shí)為什么這么快。核心就在于以下幾點(diǎn)：

1）消息是以 "批" 為單位的。

2）利用磁盤(pán)的順序讀寫(xiě)遠(yuǎn)遠(yuǎn)快于隨機(jī)讀寫(xiě)。

3）使用 PageCache。

4）使用零拷貝技術(shù)。