優(yōu)實(shí)踐)
1. 把“零拷貝”這三個(gè)字先拆開(kāi)看零拷貝技術(shù)這個(gè)詞經(jīng)常被講得玄乎其實(shí)它壓根不是“沒(méi)有拷貝”而是把 CPU 參與的數(shù)據(jù)搬運(yùn)次數(shù)降到最低。只要數(shù)據(jù)還在磁盤和網(wǎng)卡之間流動(dòng)DMA 那次拷貝就繞不開(kāi)硬件總線上的電信號(hào)總得走一趟。所以更準(zhǔn)確的說(shuō)法是“減少 CPU 拷貝與上下文切換”而“零拷貝”只是這組優(yōu)化手段的統(tǒng)稱涵蓋 mmap、sendfile、splice、DMA gather 等一整套內(nèi)核提供的接口。我做后端這些年發(fā)現(xiàn)一個(gè)現(xiàn)象很多人背得下“Kafka 快是因?yàn)榱憧截悺钡孀屗嬕淮?Consumer 拉消息的完整數(shù)據(jù)流就卡殼了。而這類問(wèn)題在排查線上性能瓶頸時(shí)非常致命——你以為是零拷貝沒(méi)生效實(shí)際上是 TLS 加密讓 sendfile 退化成了普通讀寫你以為是磁盤扛不住實(shí)際上是消費(fèi)者 fetch 太碎導(dǎo)致小包滿天飛。這篇內(nèi)容就圍繞零拷貝技術(shù)、常見(jiàn)幾種實(shí)現(xiàn)方案的取舍以及 Kafka 里到底哪條鏈路在用哪套方案展開(kāi)順帶把“Kafka 為什么快”這件事講透別只停留在背結(jié)論的層面。適合誰(shuí)看寫過(guò) Java 或者做過(guò)服務(wù)端開(kāi)發(fā)、用過(guò)消息隊(duì)列但沒(méi)深挖過(guò)底層、想在面試或者調(diào)優(yōu)時(shí)有話可說(shuō)的同學(xué)也適合做數(shù)據(jù)管道、日志采集、文件服務(wù)的從業(yè)者因?yàn)榱憧截愒谀切﹫?chǎng)景里比在消息隊(duì)列里更常用。下面所有的數(shù)字和結(jié)論都基于 Linux 平臺(tái)的常規(guī)實(shí)現(xiàn)其他平臺(tái)會(huì)有差異我會(huì)在涉及的地方點(diǎn)出來(lái)。1.1 一次普通的文件發(fā)送數(shù)據(jù)到底走了幾趟先不看 Kafka就看最樸素的需求把服務(wù)端磁盤上一個(gè)大文件通過(guò) Socket 發(fā)給客戶端。用 Java 寫出來(lái)大概是這樣FileInputStream fis new FileInputStream(data.log); byte[] buf new byte[8192]; Socket socket serverSocket.accept(); OutputStream os socket.getOutputStream(); int n; while ((n fis.read(buf)) ! -1) { os.write(buf, 0, n); }這段代碼邏輯沒(méi)毛病但底層發(fā)生的事比看上去多得多。read()和write()是兩個(gè)系統(tǒng)調(diào)用每一次都要從用戶態(tài)切進(jìn)內(nèi)核態(tài)處理完再切回用戶態(tài)。光這一套來(lái)回就是兩次上下文切換整個(gè)流程跑下來(lái)是四次切換用戶進(jìn)程調(diào)用read()陷入內(nèi)核態(tài)內(nèi)核通過(guò) DMA 把磁盤數(shù)據(jù)搬進(jìn)內(nèi)核的頁(yè)緩存page cache這次是DMA 拷貝內(nèi)核把頁(yè)緩存里的數(shù)據(jù)復(fù)制到用戶態(tài)傳進(jìn)來(lái)的buf數(shù)組這次是CPU 拷貝read()返回切回用戶態(tài)用戶進(jìn)程調(diào)用write()再次陷入內(nèi)核態(tài)內(nèi)核把用戶buf里的數(shù)據(jù)復(fù)制到 Socket 發(fā)送緩沖區(qū)又是CPU 拷貝內(nèi)核通過(guò) DMA 把 Socket 緩沖區(qū)的數(shù)據(jù)搬到網(wǎng)卡DMA 拷貝write()返回切回用戶態(tài)。算下來(lái)總共4 次拷貝2 次 DMA 2 次 CPU4 次上下文切換。這里最虧的是第 3 步和第 6 步 —— 數(shù)據(jù)在用戶態(tài)和內(nèi)核態(tài)之間被白搬了兩趟用戶進(jìn)程其實(shí)壓根沒(méi)對(duì)數(shù)據(jù)做任何加工它只是當(dāng)了回搬運(yùn)工。對(duì) 8KB 的小文件來(lái)說(shuō)這點(diǎn)開(kāi)銷無(wú)所謂但當(dāng)你在做視頻分發(fā)、日志投遞、備份同步這類動(dòng)輒 GB 級(jí)的傳輸時(shí)這兩次純粹的內(nèi)存拷貝會(huì)把 CPU 的 L1/L2 緩存沖得一塌糊涂?jī)?nèi)存帶寬也被吃掉一大塊。這里有個(gè)容易混淆的點(diǎn)DMA 拷貝也是拷貝只是不占 CPU。所謂“零拷貝”從來(lái)不承諾省掉 DMA它省的是 CPU 和上下文切換。1.2 四次上下文切換的隱性開(kāi)銷上下文切換的成本常被低估。一次切換不只是保存寄存器、切換頁(yè)表那么簡(jiǎn)單它還會(huì)污染 CPU 緩存 —— 用戶態(tài)剛預(yù)熱好的數(shù)據(jù)內(nèi)核態(tài)處理時(shí)可能就被換出去了等你切回來(lái)緩存命中率掉一大截。高頻的 read/write 循環(huán)會(huì)把這個(gè)代價(jià)放大成一個(gè)顯著的性能拐點(diǎn)。我做個(gè)粗算假設(shè)單次上下文切換在 1 微秒量級(jí)傳 10GB 數(shù)據(jù)每次 8KB那就是 130 萬(wàn)次 read 130 萬(wàn)次 write約 520 萬(wàn)次切換折算下來(lái)光切換就接近 5 秒的 CPU 時(shí)間這還不算兩次 CPU 拷貝吃掉的帶寬。在壓測(cè)里這個(gè)差距非常直觀同樣硬件用傳統(tǒng) read/write 走文件轉(zhuǎn)發(fā)吞吐可能卡在幾百 MB/s 且 CPU 某一個(gè)核直接跑滿換成 sendfile 之后CPU 占用能掉到原來(lái)的三分之一以下吞吐反而翻倍。這就是為什么零拷貝不是一個(gè)“錦上添花”的優(yōu)化而是大流量場(chǎng)景下的必選項(xiàng)。它把原本由 CPU 承擔(dān)的搬運(yùn)工作交給內(nèi)核和網(wǎng)卡硬件去做讓 CPU 騰出手來(lái)干真正需要它的事。1.3 零拷貝省掉的到底是什么把上面那張流程圖的賬重新算一遍真正無(wú)法消除的是兩次 DMA磁盤到頁(yè)緩存、緩沖到網(wǎng)卡可消除的是兩次 CPU 拷貝另外如果能讓用戶態(tài)完全不參與上下文切換也能從四次壓到兩次甚至更少。所以“零拷貝”這個(gè)名字有點(diǎn)營(yíng)銷味它真實(shí)的含義是數(shù)據(jù)在內(nèi)核態(tài)內(nèi)部完成流轉(zhuǎn)用戶態(tài)不再?gòu)?fù)制一份完整的數(shù)據(jù)副本。數(shù)據(jù)依然要從磁盤到內(nèi)存、從內(nèi)存到網(wǎng)卡但那條“磁盤 → 內(nèi)核 → 用戶 → 內(nèi)核 → 網(wǎng)卡”的之字形路徑被拉直成了“磁盤 → 內(nèi)核 → 網(wǎng)卡”。理解到這一層你就明白零拷貝有一個(gè)隱含前提你不需要修改數(shù)據(jù)內(nèi)容。一旦你要對(duì)數(shù)據(jù)做加工加密、壓縮、格式轉(zhuǎn)換、內(nèi)容過(guò)濾就必須把數(shù)據(jù)撈到用戶態(tài)零拷貝立刻失效。這一點(diǎn)在后面講 Kafka 用不了零拷貝的場(chǎng)景時(shí)會(huì)反復(fù)出現(xiàn)非常關(guān)鍵。2. 常見(jiàn)實(shí)現(xiàn)方案對(duì)比四條路線怎么選Linux 內(nèi)核提供的零拷貝接口不止一個(gè)它們面向的場(chǎng)景并不一樣選錯(cuò)了不僅沒(méi)收益還可能更慢。下面把主流四種拆開(kāi)講mmapwrite、sendfile、sendfileDMA gather、splice。每一種我都標(biāo)出它的拷貝次數(shù)和適用范圍方便你對(duì)照自己的業(yè)務(wù)做判斷。2.1 mmap write內(nèi)存映射的取巧路線mmap()的思路是把內(nèi)核頁(yè)緩存的一段區(qū)域映射到用戶進(jìn)程的地址空間里。映射建立之后用戶程序讀寫那塊虛擬地址實(shí)際讀寫的就是頁(yè)緩存內(nèi)核不需要再做第二份拷貝。用 mmap 重寫前面的發(fā)送邏輯FileChannel channel FileChannel.open(Paths.get(data.log), StandardOpenOption.READ); MappedByteBuffer mapped channel.map(FileChannel.MapMode.READ_ONLY, 0, channel.size()); SocketChannel socketChannel SocketChannel.open(addr); while (mapped.hasRemaining()) { socketChannel.write(mapped); }這條路徑上發(fā)生的事DMA 把磁盤數(shù)據(jù)搬進(jìn)頁(yè)緩存mmap建立映射無(wú)拷貝write()時(shí)內(nèi)核把頁(yè)緩存內(nèi)容復(fù)制進(jìn) Socket 緩沖區(qū)CPU 拷貝最后 DMA 到網(wǎng)卡。總計(jì)3 次拷貝2 DMA 1 CPU4 次上下文切換。相比傳統(tǒng)方案省掉了一次 CPU 拷貝但write()那一步的拷貝還在因?yàn)?Socket 緩沖區(qū)是另一塊內(nèi)存內(nèi)核不能直接把頁(yè)緩存的頁(yè)掛上去。mmap 的優(yōu)點(diǎn)在于用戶態(tài)能讀寫數(shù)據(jù)。你可以一邊映射一邊改內(nèi)容改完直接write不用來(lái)回拷貝。所以它適合那種“要檢查或微調(diào)數(shù)據(jù)但不希望整塊復(fù)制”的場(chǎng)景比如某些協(xié)議解析、內(nèi)存數(shù)據(jù)庫(kù)的持久化文件。缺點(diǎn)是映射的建立和銷毀有成本頁(yè)緩存被長(zhǎng)期占用大文件映射還可能觸發(fā)缺頁(yè)中斷風(fēng)暴而且munmap時(shí)機(jī)不好控制的話容易造成內(nèi)存回收壓力。2.2 sendfile把文件句柄直接交給內(nèi)核sendfile()在 Linux 2.2 引入它的設(shè)計(jì)目標(biāo)非常明確把一個(gè)文件描述符的內(nèi)容直接倒進(jìn)另一個(gè)描述符通常是 Socket用戶態(tài)完全不參與數(shù)據(jù)。ssize_t sendfile(int out_fd, int in_fd, off_t *offset, size_t count);這一下把 read/write 那套徹底甩開(kāi)了。內(nèi)核內(nèi)部的處理是DMA 把數(shù)據(jù)從磁盤讀進(jìn)頁(yè)緩存然后內(nèi)核把頁(yè)緩存內(nèi)容復(fù)制進(jìn) Socket 緩沖區(qū)最后 DMA 發(fā)給網(wǎng)卡。一共3 次拷貝2 DMA 1 CPU但上下文切換只剩2 次—— 用戶進(jìn)程發(fā)起sendfile進(jìn)內(nèi)核處理完返回中間不需要回用戶態(tài)。這個(gè)方案的收益非常明顯CPU 拷貝少了一次上下文切換少了一半而且整個(gè)邏輯走的是內(nèi)核單一路徑緩存局部性也好。Java 里的FileChannel.transferTo()在 Linux 上最終就落到sendfile系統(tǒng)調(diào)用上這是后面理解 Kafka 的關(guān)鍵。不過(guò) sendfile 2.2 的初版有個(gè)限制它只允許in_fd是文件、out_fd是 Socket反向不行而且用戶態(tài)拿不到數(shù)據(jù)只能“盲發(fā)”。想對(duì)內(nèi)容做半點(diǎn)處理這條路就斷了。2.3 sendfile DMA gather真正的零 CPU 拷貝Linux 2.4 對(duì) sendfile 做了一次關(guān)鍵升級(jí)如果網(wǎng)卡支持分散聚集Scatter-Gather DMA內(nèi)核就不再把頁(yè)緩存的內(nèi)容復(fù)制到 Socket 緩沖區(qū)而是只把數(shù)據(jù)的內(nèi)存地址和長(zhǎng)度描述符一個(gè)指針加長(zhǎng)度的小結(jié)構(gòu)追加到 Socket 緩沖區(qū)后面最后由網(wǎng)卡的 DMA 引擎按照描述符列表直接從頁(yè)緩存把數(shù)據(jù)攢起來(lái)發(fā)走。這次優(yōu)化把最后那一次 CPU 拷貝也干掉了數(shù)據(jù)流變成DMA磁盤→頁(yè)緩存 DMA gather頁(yè)緩存→網(wǎng)卡2 次拷貝2 次上下文切換CPU 完全不參與數(shù)據(jù)搬運(yùn)。這才是真正意義上的“零拷貝”。代價(jià)是對(duì)硬件有要求網(wǎng)卡得支持 SG-DMA而且 Socket 緩沖區(qū)得能存描述符而不是數(shù)據(jù)本身。現(xiàn)在主流的服務(wù)器網(wǎng)卡基本都支持所以你在生產(chǎn)環(huán)境上跑 Kafka 或者 Nginx 做靜態(tài)文件分發(fā)走的通常就是這一條。注意硬件不支持 SG-DMA 時(shí)內(nèi)核會(huì)自動(dòng)退化回 2.2 那條路徑功能不受影響但性能打折。判斷方法可以看ethtool -k 網(wǎng)卡名里的scatter-gather是否開(kāi)啟。2.4 splice 與管道方案兩個(gè) fd 之間的搬運(yùn)工splice()是后來(lái)補(bǔ)上的一塊拼圖它解決的是 sendfile 早期只能“文件到 Socket”這一個(gè)方向的問(wèn)題。splice 的做法是借助一個(gè)內(nèi)核管道pipe作為中轉(zhuǎn)在兩個(gè)任意類型的文件描述符之間移動(dòng)數(shù)據(jù)全程在內(nèi)核態(tài)完成管道里流動(dòng)的同樣只是頁(yè)的引用而不是數(shù)據(jù)副本。典型用法是先把數(shù)據(jù) splice 到管道再?gòu)墓艿?splice 到 Socket。它適合的場(chǎng)景比較特殊比如需要在兩個(gè) Socket 之間做純轉(zhuǎn)發(fā)、或者構(gòu)建代理服務(wù)。不過(guò)在標(biāo)準(zhǔn)的“文件發(fā)給客戶端”路徑上sendfile 更直接splice 多了一次管道操作優(yōu)勢(shì)不明顯。2.5 四種方案的橫向?qū)Ρ扰c選型建議把上面的分析壓成一張表選型時(shí)對(duì)著看就行方案數(shù)據(jù)拷貝次數(shù)上下文切換用戶態(tài)能否處理數(shù)據(jù)典型適用場(chǎng)景read write42 DMA 2 CPU4 次能小文件、需要對(duì)內(nèi)容加工mmap write32 DMA 1 CPU4 次能可直接改映射區(qū)需要讀寫數(shù)據(jù)、內(nèi)存映射文件sendfile32 DMA 1 CPU2 次不能文件直發(fā)、靜態(tài)資源分發(fā)sendfile DMA gather22 DMA2 次不能大文件分發(fā)、消息隊(duì)列讀路徑splice管道中轉(zhuǎn)22 DMA2 次不能代理轉(zhuǎn)發(fā)、任意 fd 之間搬運(yùn)我個(gè)人的判斷邏輯很簡(jiǎn)單要不要改數(shù)據(jù)。如果答案是“要”就從 mmap 和 read/write 里挑數(shù)據(jù)量小就別折騰直接 read/write 更省心如果答案是“不要”那 sendfile 系列基本是最優(yōu)解能上 DMA gather 就上不能也夠用。splice 屬于“sendfile 覆蓋不到的方向”時(shí)的備選日常業(yè)務(wù)里碰到的機(jī)會(huì)不多。還有一個(gè)常被忽略的點(diǎn)零拷貝不是免費(fèi)的午餐。它省了 CPU但把壓力轉(zhuǎn)移到了頁(yè)緩存上——大量文件走 sendfile 會(huì)迅速吃掉 page cache擠占其他進(jìn)程的文件緩存空間。所以在內(nèi)存吃緊的機(jī)器上它帶來(lái)的收益可能被緩存淘汰的開(kāi)銷抵消掉一部分這個(gè)后面講調(diào)優(yōu)時(shí)會(huì)再提。3. Kafka 里的零拷貝它用的是哪一條路線聊完通用方案回到 Kafka。很多人只知道“Kafka 用了零拷貝”但具體用在哪、用的是什么、什么情況下用不了說(shuō)得清楚的不多。我把這條鏈路拆成三段消息怎么落到磁盤、broker 怎么把消息吐給消費(fèi)者、索引文件為什么走的是另一套。3.1 消息從生產(chǎn)到落盤的這一段其實(shí)沒(méi)有零拷貝先糾正一個(gè)常見(jiàn)誤解零拷貝發(fā)生在消費(fèi)路徑上不是生產(chǎn)路徑上。生產(chǎn)者發(fā)消息過(guò)來(lái)broker 收到的是一個(gè)字節(jié)流它需要做格式校驗(yàn)、分配 offset、可能還要按批次重新組裝成日志格式這些操作都需要數(shù)據(jù)在用戶態(tài)可訪問(wèn)所以這一段是普通的網(wǎng)絡(luò)讀寫加內(nèi)存操作沒(méi)有零拷貝可言。不過(guò)生產(chǎn)路徑另有它的優(yōu)化手段順序追加寫和批量落盤。每條消息不是單獨(dú)一次write而是攢成一個(gè)批次batch追加到當(dāng)前活躍的日志段文件末尾這樣磁盤磁頭或者說(shuō) SSD 的寫入單元幾乎不需要尋道。順序?qū)懙耐掏履鼙入S機(jī)寫高出一個(gè)數(shù)量級(jí)這一點(diǎn)對(duì) Kafka 的整體性能貢獻(xiàn)其實(shí)比零拷貝還大 —— 只是零拷貝更容易被拿來(lái)講故事。落盤之后消息就靜靜躺在日志段文件里等著被消費(fèi)者拉取。真正的表演從這時(shí)開(kāi)始。3.2 消費(fèi)者拉取時(shí)transferTo 把數(shù)據(jù)直接推給網(wǎng)卡消費(fèi)者發(fā) fetch 請(qǐng)求過(guò)來(lái)broker 的處理邏輯大致是定位到對(duì)應(yīng)的日志段文件從指定 offset 開(kāi)始讀取一段數(shù)據(jù)然后寫回 Socket。如果這一段用普通方式實(shí)現(xiàn)就是“讀文件到堆內(nèi)存 → 寫 Socket”前面算過(guò)四次拷貝四次切換。Kafka 沒(méi)這么干。Java NIO 給FileChannel提供了transferTo(position, count, targetChannel)方法在 Linux 上它會(huì)被 JVM 映射到sendfile系統(tǒng)調(diào)用。Kafka 的日志讀取層封裝了一個(gè)TransferableChannel抽象明文連接PLAINTEXT的實(shí)現(xiàn)類在transferFrom里直接調(diào)用fileChannel.transferTo(...)把日志段文件和 Socket 通道接起來(lái)。Java 層面的調(diào)用形態(tài)大致是這樣// 簡(jiǎn)化示意把日志段文件的一段區(qū)間直接推進(jìn) Socket long position segmentStartOffset relativeOffset; long count Math.min(remainingBytes, maxFetchBytes); fileChannel.transferTo(position, count, socketChannel);注意這里沒(méi)有byte[] buffer沒(méi)有read也沒(méi)有write數(shù)據(jù)從頁(yè)緩存直接被內(nèi)核推向網(wǎng)卡。Java 代碼里只出現(xiàn)了一個(gè)文件通道和一個(gè) Socket 通道用戶態(tài)從頭到尾沒(méi)碰過(guò)消息體。所以 Kafka 的消費(fèi)鏈路實(shí)際是sendfile DMA gather那條路線磁盤 → 頁(yè)緩存DMA頁(yè)緩存描述符進(jìn) Socket 緩沖區(qū)網(wǎng)卡 DMA 按描述符取數(shù)發(fā)走。CPU 只負(fù)責(zé)發(fā)起調(diào)用和控制流程不搬數(shù)據(jù)。這就是為什么一臺(tái)普通配置的 broker 能扛住幾十萬(wàn)條每秒的出口流量而 CPU 使用率還不高 —— 它壓根沒(méi)在干搬運(yùn)的活。順便說(shuō)一個(gè)實(shí)操中很值得注意的細(xì)節(jié)transferTo單次能傳的字節(jié)數(shù)有上限超過(guò)之后會(huì)分批循環(huán)調(diào)用。所以真正的日志段文件再大也沒(méi)關(guān)系內(nèi)核會(huì)一段一段地推。但如果你看到transferTo返回 0 而數(shù)據(jù)還沒(méi)傳完那通常意味著 Socket 發(fā)送緩沖區(qū)滿了屬于正常的背壓不是 bug。3.3 為什么 Kafka 選 sendfile 而不是 mmap看到這里可能有人問(wèn)既然 mmap 也能省一次拷貝而且用戶態(tài)還能訪問(wèn)數(shù)據(jù)Kafka 為什么不用 mmap 讀日志原因很實(shí)在mmap 省的是拷貝但省不掉上下文切換和頁(yè)表開(kāi)銷。mmap 路徑下每次發(fā)送依然是write()系統(tǒng)調(diào)用四次切換照舊而且大規(guī)模映射文件會(huì)帶來(lái)兩個(gè)麻煩一是頁(yè)表項(xiàng)暴漲二是內(nèi)存不足時(shí)觸發(fā)缺頁(yè)中斷在 GC 敏感或者內(nèi)存吃緊的機(jī)器上這種抖動(dòng)很難受。Kafka 的日志文件是按段滾動(dòng)、長(zhǎng)期保留、體量巨大的映射一堆 GB 級(jí)文件對(duì)它來(lái)說(shuō)不是好主意。反過(guò)來(lái)說(shuō)Kafka 明確知道自己“不需要修改消息內(nèi)容” —— broker 的職責(zé)就是存和轉(zhuǎn)消息體的解析交給客戶端。這個(gè)前提太適合 sendfile 了無(wú)加工、大塊連續(xù)、目標(biāo)就是網(wǎng)絡(luò)。選型邏輯和前面那張表完全一致。3.4 索引文件反而用的是 mmap有意思的是Kafka 并沒(méi)有完全拋棄 mmap它把 mmap 用在了另一個(gè)地方偏移量索引文件和時(shí)間戳索引文件。這些索引文件的特點(diǎn)是小而碎——每條記錄只有 8 字節(jié)或 16 字節(jié)查詢時(shí)需要頻繁按 offset 定位。如果每次都走系統(tǒng)調(diào)用去讀開(kāi)銷全在切換上。Kafka 用MappedByteBuffer把索引文件映射進(jìn)內(nèi)存查的時(shí)候直接在內(nèi)存里做二分查找省掉了系統(tǒng)調(diào)用這一層。索引文件本身不大默認(rèn)每 4KB 日志對(duì)應(yīng)一條索引映射帶來(lái)的內(nèi)存壓力可控正好揚(yáng)長(zhǎng)避短。所以準(zhǔn)確的表述是Kafka 的消息數(shù)據(jù)走 sendfile索引數(shù)據(jù)走 mmap。兩套方案各用在它最擅長(zhǎng)的地方這才是合理的工程取舍而不是“Kafka 用了零拷貝”這種一句話概括。理解了這一點(diǎn)你對(duì)零拷貝的理解才算從“聽(tīng)說(shuō)過(guò)”進(jìn)到了“會(huì)用”。4. Kafka 為什么這么快零拷貝只是其中一塊拼圖標(biāo)題里帶了“Kafka 為什么這么快”那就得說(shuō)實(shí)話把性能全歸給零拷貝是偷懶的歸因。零拷貝確實(shí)在消費(fèi)鏈路上貢獻(xiàn)很大但 Kafka 的高吞吐是好幾層設(shè)計(jì)疊加出來(lái)的結(jié)果。這一章逐層拆開(kāi)順便說(shuō)清楚零拷貝在什么情況下會(huì)失效——這部分內(nèi)容比“它很快”有用得多。4.1 順序?qū)懠禹?yè)緩存磁盤這一關(guān)被繞過(guò)去了Kafka 消息落盤是純追加永遠(yuǎn)寫在文件末尾。機(jī)械盤上順序?qū)懙耐掏驴梢缘綆装?MB/sSSD 上更不用說(shuō)這和隨機(jī)寫的差距是數(shù)量級(jí)的。而且現(xiàn)代操作系統(tǒng)會(huì)把空閑內(nèi)存全拿來(lái)做 page cacheKafka 寫入時(shí)數(shù)據(jù)先進(jìn)頁(yè)緩存由內(nèi)核異步刷盤生產(chǎn)者感知到的延遲很低。這里有個(gè)很妙的聯(lián)動(dòng)寫的時(shí)候數(shù)據(jù)進(jìn)頁(yè)緩存消費(fèi)的時(shí)候 sendfile 直接從頁(yè)緩存讀如果消息剛寫進(jìn)來(lái)就被消費(fèi)典型的實(shí)時(shí)管道場(chǎng)景整個(gè)鏈路一次磁盤 IO 都不需要發(fā)生全程在內(nèi)存里完成。這個(gè)“寫緩存 零拷貝讀緩存”的組合才是 Kafka 吞吐數(shù)字好看的直接原因。4.2 批量、壓縮與分區(qū)并行把固定開(kāi)銷攤薄單條消息走一次網(wǎng)絡(luò)請(qǐng)求代價(jià)太高Kafka 從協(xié)議層面就強(qiáng)制批量生產(chǎn)者端有batch.size和linger.ms控制攢批broker 端按批次存儲(chǔ)消費(fèi)者端一次 fetch 也拉一批。批次越大每次請(qǐng)求的固定開(kāi)銷網(wǎng)絡(luò)往返、系統(tǒng)調(diào)用、鎖競(jìng)爭(zhēng)被攤得越薄。壓縮也是同理而且壓縮有個(gè)額外好處數(shù)據(jù)在磁盤上和在網(wǎng)絡(luò)上都是壓縮態(tài)broker 不解壓直接原樣轉(zhuǎn)發(fā)。壓縮比越高實(shí)際走零拷貝的字節(jié)數(shù)越少網(wǎng)絡(luò)和磁盤壓力同步下降。這就是為什么在日志采集這類文本重復(fù)度高的場(chǎng)景里開(kāi)lz4或者zstd之后吞吐能明顯往上跳一截。再疊加分區(qū)一個(gè) topic 分成多個(gè) partition分散在不同 broker 上生產(chǎn)消費(fèi)都并行。這一層是水平擴(kuò)展的邏輯和零拷貝無(wú)關(guān)但對(duì)整體吞吐的貢獻(xiàn)同樣巨大。4.3 零拷貝失效的四種典型情況這一段是我最想讓你記住的因?yàn)樗鼪Q定了你在線上遇到“Kafka 變慢”時(shí)該往哪查。第一種開(kāi)啟 TLS/SSL 加密。這是最常見(jiàn)的失效原因。sendfile 的前提是數(shù)據(jù)原樣進(jìn)網(wǎng)卡可一旦要加密就必須把數(shù)據(jù)撈到用戶態(tài)做加解密運(yùn)算零拷貝直接退化成普通讀寫。所以同一個(gè)集群PLAINTEXT 端口和 SSL 端口的吞吐差距可能有一倍以上CPU 占用也完全不同。這不是配置問(wèn)題是原理決定的只能靠加機(jī)器或者換加密方案來(lái)消化。第二種broker 端做消息格式轉(zhuǎn)換。當(dāng)生產(chǎn)者和消費(fèi)者使用的消息格式版本不一致broker 需要把日志里的消息反序列化再按目標(biāo)格式重新序列化。這個(gè)過(guò)程中數(shù)據(jù)必須進(jìn)用戶態(tài)零拷貝自然用不上。老版本集群升級(jí)期間這種情況很常見(jiàn)日志格式統(tǒng)一之后就好了。第三種消費(fèi)端 fetch 請(qǐng)求太碎。每次只拉幾百字節(jié)transferTo還沒(méi)來(lái)得及發(fā)揮作用就結(jié)束了系統(tǒng)調(diào)用的固定開(kāi)銷占比反而升高。表現(xiàn)出來(lái)就是 broker 的 CPU 不高、網(wǎng)絡(luò)包數(shù)量巨大、吞吐上不去。調(diào)大fetch.min.bytes和fetch.max.wait.ms讓消費(fèi)者多等一會(huì)兒攢夠數(shù)據(jù)效果立竿見(jiàn)影。第四種客戶端和服務(wù)端壓縮算法不一致導(dǎo)致重壓縮。如果生產(chǎn)者用 gzip、broker 配置要求 zstdbroker 就得解壓再壓數(shù)據(jù)全程在用戶態(tài)走一遍。統(tǒng)一壓縮算法是必須遵守的紀(jì)律。4.4 一份可直接抄的參數(shù)清單下面這些參數(shù)是我在實(shí)際調(diào)優(yōu)里改動(dòng)最頻繁的幾個(gè)列出來(lái)方便對(duì)照。默認(rèn)值不一定適合你的場(chǎng)景特別是磁盤和網(wǎng)絡(luò)差異大的機(jī)器。參數(shù)作用位置調(diào)整思路num.io.threadsbroker處理請(qǐng)求的 IO 線程數(shù)通常設(shè)為磁盤數(shù)量的倍數(shù)num.network.threadsbroker網(wǎng)絡(luò)收發(fā)線程數(shù)高并發(fā)拉取場(chǎng)景適當(dāng)增加log.segment.bytesbroker日志段大小默認(rèn) 1GB小段利于清理但索引更碎socket.send.buffer.bytesbrokerSocket 發(fā)送緩沖區(qū)配合大流量拉取適當(dāng)調(diào)大compression.typetopic / broker全鏈路統(tǒng)一文本類首選 lz4 或 zstdbatch.size/linger.ms生產(chǎn)者攢批大小與等待時(shí)間兩者互相制約fetch.min.bytes消費(fèi)者單次拉取最小字節(jié)數(shù)調(diào)大可顯著減少請(qǐng)求數(shù)replica.fetch.max.bytesbroker副本同步單次拉取上限大消息場(chǎng)景要留意調(diào)參這件事有個(gè)基本順序先看瓶頸在哪一層磁盤、網(wǎng)絡(luò)、CPU、GC再動(dòng)對(duì)應(yīng)的參數(shù)一次只改一個(gè)維度并留出觀察窗口。上來(lái)就把十幾個(gè)參數(shù)一起改出了問(wèn)題根本定位不到是哪一項(xiàng)引起的。5. 動(dòng)手驗(yàn)證怎么確認(rèn)零拷貝真的生效了理論講完落到操作上。零拷貝這種東西最怕“以為自己開(kāi)了”所以得能驗(yàn)證。下面是我常用的幾個(gè)手段從輕到重排列都能在測(cè)試環(huán)境跑。5.1 用系統(tǒng)調(diào)用跟蹤看 sendfile 有沒(méi)有被調(diào)用最直接的辦法是盯系統(tǒng)調(diào)用。在 broker 進(jìn)程上掛一個(gè)跟蹤過(guò)濾出 sendfile# 跟蹤指定進(jìn)程的 sendfile 調(diào)用統(tǒng)計(jì)調(diào)用次數(shù)與傳輸字節(jié)數(shù) sudo strace -f -c -e tracesendfile,read,write -p broker_pid如果消費(fèi)壓力上來(lái)之后sendfile的調(diào)用次數(shù)和返回字節(jié)數(shù)同步增長(zhǎng)而read/write的增長(zhǎng)相對(duì)平緩基本可以確認(rèn)零拷貝在正常工作。反過(guò)來(lái)如果read和write的調(diào)用量異常高就要懷疑是不是走了加密端口、或者消費(fèi)者拉得太碎。更細(xì)一點(diǎn)可以用-T參數(shù)看每次調(diào)用的耗時(shí)如果單次sendfile動(dòng)輒幾百微秒通常是 Socket 緩沖區(qū)滿了在等屬于背壓信號(hào)而不是性能問(wèn)題。# 顯示每次調(diào)用的耗時(shí) sudo strace -T -e tracesendfile -p broker_pid5.2 對(duì)比測(cè)試加密端口與明文端口的吞吐差異想直觀感受零拷貝的價(jià)值做一組對(duì)照實(shí)驗(yàn)最有效。同一個(gè) topic、同樣的消息量和消費(fèi)者邏輯只改連接端口分別跑一次壓測(cè)記錄吞吐和 broker 的 CPU 使用率。我的經(jīng)驗(yàn)是在消息體較大比如 10KB 以上、消費(fèi)吞吐打滿的情況下SSL 端口的 broker CPU 占用會(huì)明顯高于明文端口吞吐則低一截而當(dāng)消息很小、瓶頸在請(qǐng)求數(shù)量而非字節(jié)數(shù)時(shí)兩者的差距會(huì)縮小因?yàn)榇藭r(shí)主要開(kāi)銷是每次請(qǐng)求的固定成本零拷貝省下的那點(diǎn)拷貝量占比不高。這個(gè)對(duì)比能幫你建立一個(gè)判斷力什么時(shí)候該為加密付出性能代價(jià)什么時(shí)候可以把加密放在鏈路的兩端而不在 broker 上做。5.3 一套完整的驗(yàn)證流程把上面的手段串成流程照著做一遍就能把這條鏈路摸清準(zhǔn)備一個(gè)單分區(qū) topic寫入固定大小比如 1KB 和 100KB 各一組的消息若干 GB啟動(dòng)消費(fèi)者用kafka-consumer-perf-test之類的工具跑滿記錄吞吐基線同時(shí)用strace -c觀察 sendfile 的調(diào)用量和字節(jié)數(shù)用iostat -x 1看磁盤利用率用sar -n DEV 1看網(wǎng)卡吞吐如果寫入后立刻消費(fèi)觀察磁盤讀是否接近零說(shuō)明數(shù)據(jù)全在頁(yè)緩存里換到 SSL 端口重復(fù)步驟 2 到 5對(duì)比兩組數(shù)據(jù)。跑完之后你會(huì)對(duì)“零拷貝貢獻(xiàn)了多少、頁(yè)緩存貢獻(xiàn)了多少、加密損失了多少”有一個(gè)量化的認(rèn)識(shí)比看十篇文章都管用。提示測(cè)試機(jī)上的頁(yè)緩存會(huì)干擾結(jié)果兩組實(shí)驗(yàn)之間記得清理或者用不同的文件集否則第二組可能全程命中緩存數(shù)據(jù)不可比。6. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄這一章是我踩過(guò)的坑和幫別人排查過(guò)的典型問(wèn)題整理成速查形式。很多時(shí)候你以為是零拷貝失效實(shí)際問(wèn)題在別處。6.1 典型問(wèn)題速查表現(xiàn)象可能原因排查動(dòng)作處理方式broker CPU 高但吞吐低走的是加密端口零拷貝退化確認(rèn)客戶端連接協(xié)議換明文端口或把加密放到鏈路兩端網(wǎng)絡(luò)包數(shù)量巨大平均包很小消費(fèi)者 fetch 過(guò)于頻繁看fetch.min.bytes配置調(diào)大最小拉取字節(jié)數(shù)和等待時(shí)間磁盤讀 IO 很高頁(yè)緩存未命中消費(fèi)落后于寫入對(duì)比寫入與消費(fèi)的時(shí)間差增加消費(fèi)者并行度或提前預(yù)熱消費(fèi)延遲抖動(dòng)大日志段滾動(dòng)、索引重建看段大小與滾動(dòng)頻率調(diào)整log.segment.bytes大消息吞吐驟降單次拉取上限不夠被拆成多次看fetch.max.bytes同步調(diào)大服務(wù)端與客戶端上限升級(jí)后性能下降消息格式不一致觸發(fā)轉(zhuǎn)換檢查日志格式版本統(tǒng)一格式版本避免 broker 端轉(zhuǎn)換6.2 三個(gè)容易踩的坑坑一把零拷貝當(dāng)成萬(wàn)能藥。有些場(chǎng)景數(shù)據(jù)本來(lái)就要加工比如要在服務(wù)端做內(nèi)容脫敏、字段提取、格式轉(zhuǎn)換這時(shí)硬套 sendfile 是套不上的強(qiáng)行設(shè)計(jì)只會(huì)讓架構(gòu)變扭。判斷標(biāo)準(zhǔn)還是那一句數(shù)據(jù)要不要改。要改就別惦記零拷貝把加工邏輯放在鏈路的其他環(huán)節(jié)更合理。坑二只盯著 broker不管消費(fèi)者。零拷貝發(fā)生在 broker 向消費(fèi)者發(fā)數(shù)據(jù)的那一段如果消費(fèi)者自己處理慢、拉取間隔長(zhǎng)broker 側(cè)再快也沒(méi)用。我見(jiàn)過(guò)太多案例最后瓶頸在消費(fèi)端的反序列化和業(yè)務(wù)處理上調(diào) broker 參數(shù)完全無(wú)效。壓測(cè)時(shí)一定要把消費(fèi)端的能力單獨(dú)測(cè)出來(lái)?？尤雎晕募到y(tǒng)與磁盤類型。順序?qū)懠恿憧截愡@套組合在網(wǎng)絡(luò)存儲(chǔ)或者某些虛擬化磁盤上的表現(xiàn)會(huì)打折扣因?yàn)榈讓涌赡懿粷M足順序?qū)懙募僭O(shè)。部署前先跑一輪基線測(cè)試別直接拿云上共享存儲(chǔ)和本地 SSD 的數(shù)據(jù)互相套用。6.3 我個(gè)人的幾條實(shí)操心得第一條先量化再優(yōu)化?？吹酵掏虏恍邢确智迨?IO 密集還是 CPU 密集。如果是 IO 等待占主導(dǎo)零拷貝相關(guān)的東西大概率不是瓶頸往磁盤和網(wǎng)絡(luò)容量上找原因更快。第二條把頁(yè)緩存當(dāng)成容量來(lái)規(guī)劃。零拷貝的收益很大程度依賴頁(yè)緩存命中所以 broker 所在機(jī)器的內(nèi)存要給足不要把堆內(nèi)存開(kāi)得過(guò)大把操作系統(tǒng)緩存擠沒(méi)了。堆外內(nèi)存和頁(yè)緩存之間是要搶資源的這個(gè)平衡點(diǎn)需要根據(jù)消息體大小和消費(fèi)時(shí)效來(lái)調(diào)。第三條加密場(chǎng)景提前算好成本。如果合規(guī)要求全鏈路加密那就別指望零拷貝的收益容量規(guī)劃按普通轉(zhuǎn)發(fā)的模型來(lái)算留出足夠的 CPU 余量。反過(guò)來(lái)如果能接受在邊緣節(jié)點(diǎn)做加解密broker 內(nèi)部走明文性能會(huì)好很多。第四條驗(yàn)證比配置重要。參數(shù)配上去不代表生效用strace看一眼 sendfile 有沒(méi)有真的在跑往往能省下幾個(gè)小時(shí)的瞎猜。這套方法我后來(lái)用在文件服務(wù)、靜態(tài)資源分發(fā)上同樣有效凡是懷疑零拷貝沒(méi)起作用的場(chǎng)合先抓一把系統(tǒng)調(diào)用再說(shuō)。最后分享一個(gè)觀察真正把零拷貝用好的系統(tǒng)用戶態(tài)代碼往往特別薄 —— 它只負(fù)責(zé)控制流程不碰數(shù)據(jù)本體。這個(gè)設(shè)計(jì)思路本身就值得借鑒不管你做的是消息隊(duì)列、文件服務(wù)還是數(shù)據(jù)管道減少不必要的數(shù)據(jù)經(jīng)過(guò)用戶態(tài)通常都能換來(lái)實(shí)打?qū)嵉男阅芴嵘?。至于具體選 sendfile 還是 mmap回到那句判斷要不要改數(shù)據(jù)。不需要改就讓它一路走內(nèi)核。 從零拷貝到Kafka：sendfile、mmap與性能調(diào)優(yōu)實(shí)踐
1. 把“零拷貝”這三個(gè)字先拆開(kāi)看零拷貝技術(shù)這個(gè)詞經(jīng)常被講得玄乎其實(shí)它壓根不是“沒(méi)有拷貝”而是把 CPU 參與的數(shù)據(jù)搬運(yùn)次數(shù)降到最低。只要數(shù)據(jù)還在磁盤和網(wǎng)卡之間流動(dòng)DMA 那次拷貝就繞不開(kāi)硬件總線上的電信號(hào)總得走一趟。所以更準(zhǔn)確的說(shuō)法是“減少 CPU 拷貝與上下文切換”而“零拷貝”只是這組優(yōu)化手段的統(tǒng)稱涵蓋 mmap、sendfile、splice、DMA gather 等一整套內(nèi)核提供的接口。我做后端這些年發(fā)現(xiàn)一個(gè)現(xiàn)象很多人背得下“Kafka 快是因?yàn)榱憧截悺钡孀屗嬕淮?Consumer 拉消息的完整數(shù)據(jù)流就卡殼了。而這類問(wèn)題在排查線上性能瓶頸時(shí)非常致命——你以為是零拷貝沒(méi)生效實(shí)際上是 TLS 加密讓 sendfile 退化成了普通讀寫你以為是磁盤扛不住實(shí)際上是消費(fèi)者 fetch 太碎導(dǎo)致小包滿天飛。這篇內(nèi)容就圍繞零拷貝技術(shù)、常見(jiàn)幾種實(shí)現(xiàn)方案的取舍以及 Kafka 里到底哪條鏈路在用哪套方案展開(kāi)順帶把“Kafka 為什么快”這件事講透別只停留在背結(jié)論的層面。適合誰(shuí)看寫過(guò) Java 或者做過(guò)服務(wù)端開(kāi)發(fā)、用過(guò)消息隊(duì)列但沒(méi)深挖過(guò)底層、想在面試或者調(diào)優(yōu)時(shí)有話可說(shuō)的同學(xué)也適合做數(shù)據(jù)管道、日志采集、文件服務(wù)的從業(yè)者因?yàn)榱憧截愒谀切﹫?chǎng)景里比在消息隊(duì)列里更常用。下面所有的數(shù)字和結(jié)論都基于 Linux 平臺(tái)的常規(guī)實(shí)現(xiàn)其他平臺(tái)會(huì)有差異我會(huì)在涉及的地方點(diǎn)出來(lái)。1.1 一次普通的文件發(fā)送數(shù)據(jù)到底走了幾趟先不看 Kafka就看最樸素的需求把服務(wù)端磁盤上一個(gè)大文件通過(guò) Socket 發(fā)給客戶端。用 Java 寫出來(lái)大概是這樣FileInputStream fis new FileInputStream(data.log); byte[] buf new byte[8192]; Socket socket serverSocket.accept(); OutputStream os socket.getOutputStream(); int n; while ((n fis.read(buf)) ! -1) { os.write(buf, 0, n); }這段代碼邏輯沒(méi)毛病但底層發(fā)生的事比看上去多得多。read()和write()是兩個(gè)系統(tǒng)調(diào)用每一次都要從用戶態(tài)切進(jìn)內(nèi)核態(tài)處理完再切回用戶態(tài)。光這一套來(lái)回就是兩次上下文切換整個(gè)流程跑下來(lái)是四次切換用戶進(jìn)程調(diào)用read()陷入內(nèi)核態(tài)內(nèi)核通過(guò) DMA 把磁盤數(shù)據(jù)搬進(jìn)內(nèi)核的頁(yè)緩存page cache這次是DMA 拷貝內(nèi)核把頁(yè)緩存里的數(shù)據(jù)復(fù)制到用戶態(tài)傳進(jìn)來(lái)的buf數(shù)組這次是CPU 拷貝read()返回切回用戶態(tài)用戶進(jìn)程調(diào)用write()再次陷入內(nèi)核態(tài)內(nèi)核把用戶buf里的數(shù)據(jù)復(fù)制到 Socket 發(fā)送緩沖區(qū)又是CPU 拷貝內(nèi)核通過(guò) DMA 把 Socket 緩沖區(qū)的數(shù)據(jù)搬到網(wǎng)卡DMA 拷貝write()返回切回用戶態(tài)。算下來(lái)總共4 次拷貝2 次 DMA 2 次 CPU4 次上下文切換。這里最虧的是第 3 步和第 6 步 —— 數(shù)據(jù)在用戶態(tài)和內(nèi)核態(tài)之間被白搬了兩趟用戶進(jìn)程其實(shí)壓根沒(méi)對(duì)數(shù)據(jù)做任何加工它只是當(dāng)了回搬運(yùn)工。對(duì) 8KB 的小文件來(lái)說(shuō)這點(diǎn)開(kāi)銷無(wú)所謂但當(dāng)你在做視頻分發(fā)、日志投遞、備份同步這類動(dòng)輒 GB 級(jí)的傳輸時(shí)這兩次純粹的內(nèi)存拷貝會(huì)把 CPU 的 L1/L2 緩存沖得一塌糊涂?jī)?nèi)存帶寬也被吃掉一大塊。這里有個(gè)容易混淆的點(diǎn)DMA 拷貝也是拷貝只是不占 CPU。所謂“零拷貝”從來(lái)不承諾省掉 DMA它省的是 CPU 和上下文切換。1.2 四次上下文切換的隱性開(kāi)銷上下文切換的成本常被低估。一次切換不只是保存寄存器、切換頁(yè)表那么簡(jiǎn)單它還會(huì)污染 CPU 緩存 —— 用戶態(tài)剛預(yù)熱好的數(shù)據(jù)內(nèi)核態(tài)處理時(shí)可能就被換出去了等你切回來(lái)緩存命中率掉一大截。高頻的 read/write 循環(huán)會(huì)把這個(gè)代價(jià)放大成一個(gè)顯著的性能拐點(diǎn)。我做個(gè)粗算假設(shè)單次上下文切換在 1 微秒量級(jí)傳 10GB 數(shù)據(jù)每次 8KB那就是 130 萬(wàn)次 read 130 萬(wàn)次 write約 520 萬(wàn)次切換折算下來(lái)光切換就接近 5 秒的 CPU 時(shí)間這還不算兩次 CPU 拷貝吃掉的帶寬。在壓測(cè)里這個(gè)差距非常直觀同樣硬件用傳統(tǒng) read/write 走文件轉(zhuǎn)發(fā)吞吐可能卡在幾百 MB/s 且 CPU 某一個(gè)核直接跑滿換成 sendfile 之后CPU 占用能掉到原來(lái)的三分之一以下吞吐反而翻倍。這就是為什么零拷貝不是一個(gè)“錦上添花”的優(yōu)化而是大流量場(chǎng)景下的必選項(xiàng)。它把原本由 CPU 承擔(dān)的搬運(yùn)工作交給內(nèi)核和網(wǎng)卡硬件去做讓 CPU 騰出手來(lái)干真正需要它的事。1.3 零拷貝省掉的到底是什么把上面那張流程圖的賬重新算一遍真正無(wú)法消除的是兩次 DMA磁盤到頁(yè)緩存、緩沖到網(wǎng)卡可消除的是兩次 CPU 拷貝另外如果能讓用戶態(tài)完全不參與上下文切換也能從四次壓到兩次甚至更少。所以“零拷貝”這個(gè)名字有點(diǎn)營(yíng)銷味它真實(shí)的含義是數(shù)據(jù)在內(nèi)核態(tài)內(nèi)部完成流轉(zhuǎn)用戶態(tài)不再?gòu)?fù)制一份完整的數(shù)據(jù)副本。數(shù)據(jù)依然要從磁盤到內(nèi)存、從內(nèi)存到網(wǎng)卡但那條“磁盤 → 內(nèi)核 → 用戶 → 內(nèi)核 → 網(wǎng)卡”的之字形路徑被拉直成了“磁盤 → 內(nèi)核 → 網(wǎng)卡”。理解到這一層你就明白零拷貝有一個(gè)隱含前提你不需要修改數(shù)據(jù)內(nèi)容。一旦你要對(duì)數(shù)據(jù)做加工加密、壓縮、格式轉(zhuǎn)換、內(nèi)容過(guò)濾就必須把數(shù)據(jù)撈到用戶態(tài)零拷貝立刻失效。這一點(diǎn)在后面講 Kafka 用不了零拷貝的場(chǎng)景時(shí)會(huì)反復(fù)出現(xiàn)非常關(guān)鍵。2. 常見(jiàn)實(shí)現(xiàn)方案對(duì)比四條路線怎么選Linux 內(nèi)核提供的零拷貝接口不止一個(gè)它們面向的場(chǎng)景并不一樣選錯(cuò)了不僅沒(méi)收益還可能更慢。下面把主流四種拆開(kāi)講mmapwrite、sendfile、sendfileDMA gather、splice。每一種我都標(biāo)出它的拷貝次數(shù)和適用范圍方便你對(duì)照自己的業(yè)務(wù)做判斷。2.1 mmap write內(nèi)存映射的取巧路線mmap()的思路是把內(nèi)核頁(yè)緩存的一段區(qū)域映射到用戶進(jìn)程的地址空間里。映射建立之后用戶程序讀寫那塊虛擬地址實(shí)際讀寫的就是頁(yè)緩存內(nèi)核不需要再做第二份拷貝。用 mmap 重寫前面的發(fā)送邏輯FileChannel channel FileChannel.open(Paths.get(data.log), StandardOpenOption.READ); MappedByteBuffer mapped channel.map(FileChannel.MapMode.READ_ONLY, 0, channel.size()); SocketChannel socketChannel SocketChannel.open(addr); while (mapped.hasRemaining()) { socketChannel.write(mapped); }這條路徑上發(fā)生的事DMA 把磁盤數(shù)據(jù)搬進(jìn)頁(yè)緩存mmap建立映射無(wú)拷貝write()時(shí)內(nèi)核把頁(yè)緩存內(nèi)容復(fù)制進(jìn) Socket 緩沖區(qū)CPU 拷貝最后 DMA 到網(wǎng)卡。總計(jì)3 次拷貝2 DMA 1 CPU4 次上下文切換。相比傳統(tǒng)方案省掉了一次 CPU 拷貝但write()那一步的拷貝還在因?yàn)?Socket 緩沖區(qū)是另一塊內(nèi)存內(nèi)核不能直接把頁(yè)緩存的頁(yè)掛上去。mmap 的優(yōu)點(diǎn)在于用戶態(tài)能讀寫數(shù)據(jù)。你可以一邊映射一邊改內(nèi)容改完直接write不用來(lái)回拷貝。所以它適合那種“要檢查或微調(diào)數(shù)據(jù)但不希望整塊復(fù)制”的場(chǎng)景比如某些協(xié)議解析、內(nèi)存數(shù)據(jù)庫(kù)的持久化文件。缺點(diǎn)是映射的建立和銷毀有成本頁(yè)緩存被長(zhǎng)期占用大文件映射還可能觸發(fā)缺頁(yè)中斷風(fēng)暴而且munmap時(shí)機(jī)不好控制的話容易造成內(nèi)存回收壓力。2.2 sendfile把文件句柄直接交給內(nèi)核sendfile()在 Linux 2.2 引入它的設(shè)計(jì)目標(biāo)非常明確把一個(gè)文件描述符的內(nèi)容直接倒進(jìn)另一個(gè)描述符通常是 Socket用戶態(tài)完全不參與數(shù)據(jù)。ssize_t sendfile(int out_fd, int in_fd, off_t *offset, size_t count);這一下把 read/write 那套徹底甩開(kāi)了。內(nèi)核內(nèi)部的處理是DMA 把數(shù)據(jù)從磁盤讀進(jìn)頁(yè)緩存然后內(nèi)核把頁(yè)緩存內(nèi)容復(fù)制進(jìn) Socket 緩沖區(qū)最后 DMA 發(fā)給網(wǎng)卡。一共3 次拷貝2 DMA 1 CPU但上下文切換只剩2 次—— 用戶進(jìn)程發(fā)起sendfile進(jìn)內(nèi)核處理完返回中間不需要回用戶態(tài)。這個(gè)方案的收益非常明顯CPU 拷貝少了一次上下文切換少了一半而且整個(gè)邏輯走的是內(nèi)核單一路徑緩存局部性也好。Java 里的FileChannel.transferTo()在 Linux 上最終就落到sendfile系統(tǒng)調(diào)用上這是后面理解 Kafka 的關(guān)鍵。不過(guò) sendfile 2.2 的初版有個(gè)限制它只允許in_fd是文件、out_fd是 Socket反向不行而且用戶態(tài)拿不到數(shù)據(jù)只能“盲發(fā)”。想對(duì)內(nèi)容做半點(diǎn)處理這條路就斷了。2.3 sendfile DMA gather真正的零 CPU 拷貝Linux 2.4 對(duì) sendfile 做了一次關(guān)鍵升級(jí)如果網(wǎng)卡支持分散聚集Scatter-Gather DMA內(nèi)核就不再把頁(yè)緩存的內(nèi)容復(fù)制到 Socket 緩沖區(qū)而是只把數(shù)據(jù)的內(nèi)存地址和長(zhǎng)度描述符一個(gè)指針加長(zhǎng)度的小結(jié)構(gòu)追加到 Socket 緩沖區(qū)后面最后由網(wǎng)卡的 DMA 引擎按照描述符列表直接從頁(yè)緩存把數(shù)據(jù)攢起來(lái)發(fā)走。這次優(yōu)化把最后那一次 CPU 拷貝也干掉了數(shù)據(jù)流變成DMA磁盤→頁(yè)緩存 DMA gather頁(yè)緩存→網(wǎng)卡2 次拷貝2 次上下文切換CPU 完全不參與數(shù)據(jù)搬運(yùn)。這才是真正意義上的“零拷貝”。代價(jià)是對(duì)硬件有要求網(wǎng)卡得支持 SG-DMA而且 Socket 緩沖區(qū)得能存描述符而不是數(shù)據(jù)本身。現(xiàn)在主流的服務(wù)器網(wǎng)卡基本都支持所以你在生產(chǎn)環(huán)境上跑 Kafka 或者 Nginx 做靜態(tài)文件分發(fā)走的通常就是這一條。注意硬件不支持 SG-DMA 時(shí)內(nèi)核會(huì)自動(dòng)退化回 2.2 那條路徑功能不受影響但性能打折。判斷方法可以看ethtool -k 網(wǎng)卡名里的scatter-gather是否開(kāi)啟。2.4 splice 與管道方案兩個(gè) fd 之間的搬運(yùn)工splice()是后來(lái)補(bǔ)上的一塊拼圖它解決的是 sendfile 早期只能“文件到 Socket”這一個(gè)方向的問(wèn)題。splice 的做法是借助一個(gè)內(nèi)核管道pipe作為中轉(zhuǎn)在兩個(gè)任意類型的文件描述符之間移動(dòng)數(shù)據(jù)全程在內(nèi)核態(tài)完成管道里流動(dòng)的同樣只是頁(yè)的引用而不是數(shù)據(jù)副本。典型用法是先把數(shù)據(jù) splice 到管道再?gòu)墓艿?splice 到 Socket。它適合的場(chǎng)景比較特殊比如需要在兩個(gè) Socket 之間做純轉(zhuǎn)發(fā)、或者構(gòu)建代理服務(wù)。不過(guò)在標(biāo)準(zhǔn)的“文件發(fā)給客戶端”路徑上sendfile 更直接splice 多了一次管道操作優(yōu)勢(shì)不明顯。2.5 四種方案的橫向?qū)Ρ扰c選型建議把上面的分析壓成一張表選型時(shí)對(duì)著看就行方案數(shù)據(jù)拷貝次數(shù)上下文切換用戶態(tài)能否處理數(shù)據(jù)典型適用場(chǎng)景read write42 DMA 2 CPU4 次能小文件、需要對(duì)內(nèi)容加工mmap write32 DMA 1 CPU4 次能可直接改映射區(qū)需要讀寫數(shù)據(jù)、內(nèi)存映射文件sendfile32 DMA 1 CPU2 次不能文件直發(fā)、靜態(tài)資源分發(fā)sendfile DMA gather22 DMA2 次不能大文件分發(fā)、消息隊(duì)列讀路徑splice管道中轉(zhuǎn)22 DMA2 次不能代理轉(zhuǎn)發(fā)、任意 fd 之間搬運(yùn)我個(gè)人的判斷邏輯很簡(jiǎn)單要不要改數(shù)據(jù)。如果答案是“要”就從 mmap 和 read/write 里挑數(shù)據(jù)量小就別折騰直接 read/write 更省心如果答案是“不要”那 sendfile 系列基本是最優(yōu)解能上 DMA gather 就上不能也夠用。splice 屬于“sendfile 覆蓋不到的方向”時(shí)的備選日常業(yè)務(wù)里碰到的機(jī)會(huì)不多。還有一個(gè)常被忽略的點(diǎn)零拷貝不是免費(fèi)的午餐。它省了 CPU但把壓力轉(zhuǎn)移到了頁(yè)緩存上——大量文件走 sendfile 會(huì)迅速吃掉 page cache擠占其他進(jìn)程的文件緩存空間。所以在內(nèi)存吃緊的機(jī)器上它帶來(lái)的收益可能被緩存淘汰的開(kāi)銷抵消掉一部分這個(gè)后面講調(diào)優(yōu)時(shí)會(huì)再提。3. Kafka 里的零拷貝它用的是哪一條路線聊完通用方案回到 Kafka。很多人只知道“Kafka 用了零拷貝”但具體用在哪、用的是什么、什么情況下用不了說(shuō)得清楚的不多。我把這條鏈路拆成三段消息怎么落到磁盤、broker 怎么把消息吐給消費(fèi)者、索引文件為什么走的是另一套。3.1 消息從生產(chǎn)到落盤的這一段其實(shí)沒(méi)有零拷貝先糾正一個(gè)常見(jiàn)誤解零拷貝發(fā)生在消費(fèi)路徑上不是生產(chǎn)路徑上。生產(chǎn)者發(fā)消息過(guò)來(lái)broker 收到的是一個(gè)字節(jié)流它需要做格式校驗(yàn)、分配 offset、可能還要按批次重新組裝成日志格式這些操作都需要數(shù)據(jù)在用戶態(tài)可訪問(wèn)所以這一段是普通的網(wǎng)絡(luò)讀寫加內(nèi)存操作沒(méi)有零拷貝可言。不過(guò)生產(chǎn)路徑另有它的優(yōu)化手段順序追加寫和批量落盤。每條消息不是單獨(dú)一次write而是攢成一個(gè)批次batch追加到當(dāng)前活躍的日志段文件末尾這樣磁盤磁頭或者說(shuō) SSD 的寫入單元幾乎不需要尋道。順序?qū)懙耐掏履鼙入S機(jī)寫高出一個(gè)數(shù)量級(jí)這一點(diǎn)對(duì) Kafka 的整體性能貢獻(xiàn)其實(shí)比零拷貝還大 —— 只是零拷貝更容易被拿來(lái)講故事。落盤之后消息就靜靜躺在日志段文件里等著被消費(fèi)者拉取。真正的表演從這時(shí)開(kāi)始。3.2 消費(fèi)者拉取時(shí)transferTo 把數(shù)據(jù)直接推給網(wǎng)卡消費(fèi)者發(fā) fetch 請(qǐng)求過(guò)來(lái)broker 的處理邏輯大致是定位到對(duì)應(yīng)的日志段文件從指定 offset 開(kāi)始讀取一段數(shù)據(jù)然后寫回 Socket。如果這一段用普通方式實(shí)現(xiàn)就是“讀文件到堆內(nèi)存 → 寫 Socket”前面算過(guò)四次拷貝四次切換。Kafka 沒(méi)這么干。Java NIO 給FileChannel提供了transferTo(position, count, targetChannel)方法在 Linux 上它會(huì)被 JVM 映射到sendfile系統(tǒng)調(diào)用。Kafka 的日志讀取層封裝了一個(gè)TransferableChannel抽象明文連接PLAINTEXT的實(shí)現(xiàn)類在transferFrom里直接調(diào)用fileChannel.transferTo(...)把日志段文件和 Socket 通道接起來(lái)。Java 層面的調(diào)用形態(tài)大致是這樣// 簡(jiǎn)化示意把日志段文件的一段區(qū)間直接推進(jìn) Socket long position segmentStartOffset relativeOffset; long count Math.min(remainingBytes, maxFetchBytes); fileChannel.transferTo(position, count, socketChannel);注意這里沒(méi)有byte[] buffer沒(méi)有read也沒(méi)有write數(shù)據(jù)從頁(yè)緩存直接被內(nèi)核推向網(wǎng)卡。Java 代碼里只出現(xiàn)了一個(gè)文件通道和一個(gè) Socket 通道用戶態(tài)從頭到尾沒(méi)碰過(guò)消息體。所以 Kafka 的消費(fèi)鏈路實(shí)際是sendfile DMA gather那條路線磁盤 → 頁(yè)緩存DMA頁(yè)緩存描述符進(jìn) Socket 緩沖區(qū)網(wǎng)卡 DMA 按描述符取數(shù)發(fā)走。CPU 只負(fù)責(zé)發(fā)起調(diào)用和控制流程不搬數(shù)據(jù)。這就是為什么一臺(tái)普通配置的 broker 能扛住幾十萬(wàn)條每秒的出口流量而 CPU 使用率還不高 —— 它壓根沒(méi)在干搬運(yùn)的活。順便說(shuō)一個(gè)實(shí)操中很值得注意的細(xì)節(jié)transferTo單次能傳的字節(jié)數(shù)有上限超過(guò)之后會(huì)分批循環(huán)調(diào)用。所以真正的日志段文件再大也沒(méi)關(guān)系內(nèi)核會(huì)一段一段地推。但如果你看到transferTo返回 0 而數(shù)據(jù)還沒(méi)傳完那通常意味著 Socket 發(fā)送緩沖區(qū)滿了屬于正常的背壓不是 bug。3.3 為什么 Kafka 選 sendfile 而不是 mmap看到這里可能有人問(wèn)既然 mmap 也能省一次拷貝而且用戶態(tài)還能訪問(wèn)數(shù)據(jù)Kafka 為什么不用 mmap 讀日志原因很實(shí)在mmap 省的是拷貝但省不掉上下文切換和頁(yè)表開(kāi)銷。mmap 路徑下每次發(fā)送依然是write()系統(tǒng)調(diào)用四次切換照舊而且大規(guī)模映射文件會(huì)帶來(lái)兩個(gè)麻煩一是頁(yè)表項(xiàng)暴漲二是內(nèi)存不足時(shí)觸發(fā)缺頁(yè)中斷在 GC 敏感或者內(nèi)存吃緊的機(jī)器上這種抖動(dòng)很難受。Kafka 的日志文件是按段滾動(dòng)、長(zhǎng)期保留、體量巨大的映射一堆 GB 級(jí)文件對(duì)它來(lái)說(shuō)不是好主意。反過(guò)來(lái)說(shuō)Kafka 明確知道自己“不需要修改消息內(nèi)容” —— broker 的職責(zé)就是存和轉(zhuǎn)消息體的解析交給客戶端。這個(gè)前提太適合 sendfile 了無(wú)加工、大塊連續(xù)、目標(biāo)就是網(wǎng)絡(luò)。選型邏輯和前面那張表完全一致。3.4 索引文件反而用的是 mmap有意思的是Kafka 并沒(méi)有完全拋棄 mmap它把 mmap 用在了另一個(gè)地方偏移量索引文件和時(shí)間戳索引文件。這些索引文件的特點(diǎn)是小而碎——每條記錄只有 8 字節(jié)或 16 字節(jié)查詢時(shí)需要頻繁按 offset 定位。如果每次都走系統(tǒng)調(diào)用去讀開(kāi)銷全在切換上。Kafka 用MappedByteBuffer把索引文件映射進(jìn)內(nèi)存查的時(shí)候直接在內(nèi)存里做二分查找省掉了系統(tǒng)調(diào)用這一層。索引文件本身不大默認(rèn)每 4KB 日志對(duì)應(yīng)一條索引映射帶來(lái)的內(nèi)存壓力可控正好揚(yáng)長(zhǎng)避短。所以準(zhǔn)確的表述是Kafka 的消息數(shù)據(jù)走 sendfile索引數(shù)據(jù)走 mmap。兩套方案各用在它最擅長(zhǎng)的地方這才是合理的工程取舍而不是“Kafka 用了零拷貝”這種一句話概括。理解了這一點(diǎn)你對(duì)零拷貝的理解才算從“聽(tīng)說(shuō)過(guò)”進(jìn)到了“會(huì)用”。4. Kafka 為什么這么快零拷貝只是其中一塊拼圖標(biāo)題里帶了“Kafka 為什么這么快”那就得說(shuō)實(shí)話把性能全歸給零拷貝是偷懶的歸因。零拷貝確實(shí)在消費(fèi)鏈路上貢獻(xiàn)很大但 Kafka 的高吞吐是好幾層設(shè)計(jì)疊加出來(lái)的結(jié)果。這一章逐層拆開(kāi)順便說(shuō)清楚零拷貝在什么情況下會(huì)失效——這部分內(nèi)容比“它很快”有用得多。4.1 順序?qū)懠禹?yè)緩存磁盤這一關(guān)被繞過(guò)去了Kafka 消息落盤是純追加永遠(yuǎn)寫在文件末尾。機(jī)械盤上順序?qū)懙耐掏驴梢缘綆装?MB/sSSD 上更不用說(shuō)這和隨機(jī)寫的差距是數(shù)量級(jí)的。而且現(xiàn)代操作系統(tǒng)會(huì)把空閑內(nèi)存全拿來(lái)做 page cacheKafka 寫入時(shí)數(shù)據(jù)先進(jìn)頁(yè)緩存由內(nèi)核異步刷盤生產(chǎn)者感知到的延遲很低。這里有個(gè)很妙的聯(lián)動(dòng)寫的時(shí)候數(shù)據(jù)進(jìn)頁(yè)緩存消費(fèi)的時(shí)候 sendfile 直接從頁(yè)緩存讀如果消息剛寫進(jìn)來(lái)就被消費(fèi)典型的實(shí)時(shí)管道場(chǎng)景整個(gè)鏈路一次磁盤 IO 都不需要發(fā)生全程在內(nèi)存里完成。這個(gè)“寫緩存 零拷貝讀緩存”的組合才是 Kafka 吞吐數(shù)字好看的直接原因。4.2 批量、壓縮與分區(qū)并行把固定開(kāi)銷攤薄單條消息走一次網(wǎng)絡(luò)請(qǐng)求代價(jià)太高Kafka 從協(xié)議層面就強(qiáng)制批量生產(chǎn)者端有batch.size和linger.ms控制攢批broker 端按批次存儲(chǔ)消費(fèi)者端一次 fetch 也拉一批。批次越大每次請(qǐng)求的固定開(kāi)銷網(wǎng)絡(luò)往返、系統(tǒng)調(diào)用、鎖競(jìng)爭(zhēng)被攤得越薄。壓縮也是同理而且壓縮有個(gè)額外好處數(shù)據(jù)在磁盤上和在網(wǎng)絡(luò)上都是壓縮態(tài)broker 不解壓直接原樣轉(zhuǎn)發(fā)。壓縮比越高實(shí)際走零拷貝的字節(jié)數(shù)越少網(wǎng)絡(luò)和磁盤壓力同步下降。這就是為什么在日志采集這類文本重復(fù)度高的場(chǎng)景里開(kāi)lz4或者zstd之后吞吐能明顯往上跳一截。再疊加分區(qū)一個(gè) topic 分成多個(gè) partition分散在不同 broker 上生產(chǎn)消費(fèi)都并行。這一層是水平擴(kuò)展的邏輯和零拷貝無(wú)關(guān)但對(duì)整體吞吐的貢獻(xiàn)同樣巨大。4.3 零拷貝失效的四種典型情況這一段是我最想讓你記住的因?yàn)樗鼪Q定了你在線上遇到“Kafka 變慢”時(shí)該往哪查。第一種開(kāi)啟 TLS/SSL 加密。這是最常見(jiàn)的失效原因。sendfile 的前提是數(shù)據(jù)原樣進(jìn)網(wǎng)卡可一旦要加密就必須把數(shù)據(jù)撈到用戶態(tài)做加解密運(yùn)算零拷貝直接退化成普通讀寫。所以同一個(gè)集群PLAINTEXT 端口和 SSL 端口的吞吐差距可能有一倍以上CPU 占用也完全不同。這不是配置問(wèn)題是原理決定的只能靠加機(jī)器或者換加密方案來(lái)消化。第二種broker 端做消息格式轉(zhuǎn)換。當(dāng)生產(chǎn)者和消費(fèi)者使用的消息格式版本不一致broker 需要把日志里的消息反序列化再按目標(biāo)格式重新序列化。這個(gè)過(guò)程中數(shù)據(jù)必須進(jìn)用戶態(tài)零拷貝自然用不上。老版本集群升級(jí)期間這種情況很常見(jiàn)日志格式統(tǒng)一之后就好了。第三種消費(fèi)端 fetch 請(qǐng)求太碎。每次只拉幾百字節(jié)transferTo還沒(méi)來(lái)得及發(fā)揮作用就結(jié)束了系統(tǒng)調(diào)用的固定開(kāi)銷占比反而升高。表現(xiàn)出來(lái)就是 broker 的 CPU 不高、網(wǎng)絡(luò)包數(shù)量巨大、吞吐上不去。調(diào)大fetch.min.bytes和fetch.max.wait.ms讓消費(fèi)者多等一會(huì)兒攢夠數(shù)據(jù)效果立竿見(jiàn)影。第四種客戶端和服務(wù)端壓縮算法不一致導(dǎo)致重壓縮。如果生產(chǎn)者用 gzip、broker 配置要求 zstdbroker 就得解壓再壓數(shù)據(jù)全程在用戶態(tài)走一遍。統(tǒng)一壓縮算法是必須遵守的紀(jì)律。4.4 一份可直接抄的參數(shù)清單下面這些參數(shù)是我在實(shí)際調(diào)優(yōu)里改動(dòng)最頻繁的幾個(gè)列出來(lái)方便對(duì)照。默認(rèn)值不一定適合你的場(chǎng)景特別是磁盤和網(wǎng)絡(luò)差異大的機(jī)器。參數(shù)作用位置調(diào)整思路num.io.threadsbroker處理請(qǐng)求的 IO 線程數(shù)通常設(shè)為磁盤數(shù)量的倍數(shù)num.network.threadsbroker網(wǎng)絡(luò)收發(fā)線程數(shù)高并發(fā)拉取場(chǎng)景適當(dāng)增加log.segment.bytesbroker日志段大小默認(rèn) 1GB小段利于清理但索引更碎socket.send.buffer.bytesbrokerSocket 發(fā)送緩沖區(qū)配合大流量拉取適當(dāng)調(diào)大compression.typetopic / broker全鏈路統(tǒng)一文本類首選 lz4 或 zstdbatch.size/linger.ms生產(chǎn)者攢批大小與等待時(shí)間兩者互相制約fetch.min.bytes消費(fèi)者單次拉取最小字節(jié)數(shù)調(diào)大可顯著減少請(qǐng)求數(shù)replica.fetch.max.bytesbroker副本同步單次拉取上限大消息場(chǎng)景要留意調(diào)參這件事有個(gè)基本順序先看瓶頸在哪一層磁盤、網(wǎng)絡(luò)、CPU、GC再動(dòng)對(duì)應(yīng)的參數(shù)一次只改一個(gè)維度并留出觀察窗口。上來(lái)就把十幾個(gè)參數(shù)一起改出了問(wèn)題根本定位不到是哪一項(xiàng)引起的。5. 動(dòng)手驗(yàn)證怎么確認(rèn)零拷貝真的生效了理論講完落到操作上。零拷貝這種東西最怕“以為自己開(kāi)了”所以得能驗(yàn)證。下面是我常用的幾個(gè)手段從輕到重排列都能在測(cè)試環(huán)境跑。5.1 用系統(tǒng)調(diào)用跟蹤看 sendfile 有沒(méi)有被調(diào)用最直接的辦法是盯系統(tǒng)調(diào)用。在 broker 進(jìn)程上掛一個(gè)跟蹤過(guò)濾出 sendfile# 跟蹤指定進(jìn)程的 sendfile 調(diào)用統(tǒng)計(jì)調(diào)用次數(shù)與傳輸字節(jié)數(shù) sudo strace -f -c -e tracesendfile,read,write -p broker_pid如果消費(fèi)壓力上來(lái)之后sendfile的調(diào)用次數(shù)和返回字節(jié)數(shù)同步增長(zhǎng)而read/write的增長(zhǎng)相對(duì)平緩基本可以確認(rèn)零拷貝在正常工作。反過(guò)來(lái)如果read和write的調(diào)用量異常高就要懷疑是不是走了加密端口、或者消費(fèi)者拉得太碎。更細(xì)一點(diǎn)可以用-T參數(shù)看每次調(diào)用的耗時(shí)如果單次sendfile動(dòng)輒幾百微秒通常是 Socket 緩沖區(qū)滿了在等屬于背壓信號(hào)而不是性能問(wèn)題。# 顯示每次調(diào)用的耗時(shí) sudo strace -T -e tracesendfile -p broker_pid5.2 對(duì)比測(cè)試加密端口與明文端口的吞吐差異想直觀感受零拷貝的價(jià)值做一組對(duì)照實(shí)驗(yàn)最有效。同一個(gè) topic、同樣的消息量和消費(fèi)者邏輯只改連接端口分別跑一次壓測(cè)記錄吞吐和 broker 的 CPU 使用率。我的經(jīng)驗(yàn)是在消息體較大比如 10KB 以上、消費(fèi)吞吐打滿的情況下SSL 端口的 broker CPU 占用會(huì)明顯高于明文端口吞吐則低一截而當(dāng)消息很小、瓶頸在請(qǐng)求數(shù)量而非字節(jié)數(shù)時(shí)兩者的差距會(huì)縮小因?yàn)榇藭r(shí)主要開(kāi)銷是每次請(qǐng)求的固定成本零拷貝省下的那點(diǎn)拷貝量占比不高。這個(gè)對(duì)比能幫你建立一個(gè)判斷力什么時(shí)候該為加密付出性能代價(jià)什么時(shí)候可以把加密放在鏈路的兩端而不在 broker 上做。5.3 一套完整的驗(yàn)證流程把上面的手段串成流程照著做一遍就能把這條鏈路摸清準(zhǔn)備一個(gè)單分區(qū) topic寫入固定大小比如 1KB 和 100KB 各一組的消息若干 GB啟動(dòng)消費(fèi)者用kafka-consumer-perf-test之類的工具跑滿記錄吞吐基線同時(shí)用strace -c觀察 sendfile 的調(diào)用量和字節(jié)數(shù)用iostat -x 1看磁盤利用率用sar -n DEV 1看網(wǎng)卡吞吐如果寫入后立刻消費(fèi)觀察磁盤讀是否接近零說(shuō)明數(shù)據(jù)全在頁(yè)緩存里換到 SSL 端口重復(fù)步驟 2 到 5對(duì)比兩組數(shù)據(jù)。跑完之后你會(huì)對(duì)“零拷貝貢獻(xiàn)了多少、頁(yè)緩存貢獻(xiàn)了多少、加密損失了多少”有一個(gè)量化的認(rèn)識(shí)比看十篇文章都管用。提示測(cè)試機(jī)上的頁(yè)緩存會(huì)干擾結(jié)果兩組實(shí)驗(yàn)之間記得清理或者用不同的文件集否則第二組可能全程命中緩存數(shù)據(jù)不可比。6. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄這一章是我踩過(guò)的坑和幫別人排查過(guò)的典型問(wèn)題整理成速查形式。很多時(shí)候你以為是零拷貝失效實(shí)際問(wèn)題在別處。6.1 典型問(wèn)題速查表現(xiàn)象可能原因排查動(dòng)作處理方式broker CPU 高但吞吐低走的是加密端口零拷貝退化確認(rèn)客戶端連接協(xié)議換明文端口或把加密放到鏈路兩端網(wǎng)絡(luò)包數(shù)量巨大平均包很小消費(fèi)者 fetch 過(guò)于頻繁看fetch.min.bytes配置調(diào)大最小拉取字節(jié)數(shù)和等待時(shí)間磁盤讀 IO 很高頁(yè)緩存未命中消費(fèi)落后于寫入對(duì)比寫入與消費(fèi)的時(shí)間差增加消費(fèi)者并行度或提前預(yù)熱消費(fèi)延遲抖動(dòng)大日志段滾動(dòng)、索引重建看段大小與滾動(dòng)頻率調(diào)整log.segment.bytes大消息吞吐驟降單次拉取上限不夠被拆成多次看fetch.max.bytes同步調(diào)大服務(wù)端與客戶端上限升級(jí)后性能下降消息格式不一致觸發(fā)轉(zhuǎn)換檢查日志格式版本統(tǒng)一格式版本避免 broker 端轉(zhuǎn)換6.2 三個(gè)容易踩的坑坑一把零拷貝當(dāng)成萬(wàn)能藥。有些場(chǎng)景數(shù)據(jù)本來(lái)就要加工比如要在服務(wù)端做內(nèi)容脫敏、字段提取、格式轉(zhuǎn)換這時(shí)硬套 sendfile 是套不上的強(qiáng)行設(shè)計(jì)只會(huì)讓架構(gòu)變扭。判斷標(biāo)準(zhǔn)還是那一句數(shù)據(jù)要不要改。要改就別惦記零拷貝把加工邏輯放在鏈路的其他環(huán)節(jié)更合理。坑二只盯著 broker不管消費(fèi)者。零拷貝發(fā)生在 broker 向消費(fèi)者發(fā)數(shù)據(jù)的那一段如果消費(fèi)者自己處理慢、拉取間隔長(zhǎng)broker 側(cè)再快也沒(méi)用。我見(jiàn)過(guò)太多案例最后瓶頸在消費(fèi)端的反序列化和業(yè)務(wù)處理上調(diào) broker 參數(shù)完全無(wú)效。壓測(cè)時(shí)一定要把消費(fèi)端的能力單獨(dú)測(cè)出來(lái)?？尤雎晕募到y(tǒng)與磁盤類型。順序?qū)懠恿憧截愡@套組合在網(wǎng)絡(luò)存儲(chǔ)或者某些虛擬化磁盤上的表現(xiàn)會(huì)打折扣因?yàn)榈讓涌赡懿粷M足順序?qū)懙募僭O(shè)。部署前先跑一輪基線測(cè)試別直接拿云上共享存儲(chǔ)和本地 SSD 的數(shù)據(jù)互相套用。6.3 我個(gè)人的幾條實(shí)操心得第一條先量化再優(yōu)化?？吹酵掏虏恍邢确智迨?IO 密集還是 CPU 密集。如果是 IO 等待占主導(dǎo)零拷貝相關(guān)的東西大概率不是瓶頸往磁盤和網(wǎng)絡(luò)容量上找原因更快。第二條把頁(yè)緩存當(dāng)成容量來(lái)規(guī)劃。零拷貝的收益很大程度依賴頁(yè)緩存命中所以 broker 所在機(jī)器的內(nèi)存要給足不要把堆內(nèi)存開(kāi)得過(guò)大把操作系統(tǒng)緩存擠沒(méi)了。堆外內(nèi)存和頁(yè)緩存之間是要搶資源的這個(gè)平衡點(diǎn)需要根據(jù)消息體大小和消費(fèi)時(shí)效來(lái)調(diào)。第三條加密場(chǎng)景提前算好成本。如果合規(guī)要求全鏈路加密那就別指望零拷貝的收益容量規(guī)劃按普通轉(zhuǎn)發(fā)的模型來(lái)算留出足夠的 CPU 余量。反過(guò)來(lái)如果能接受在邊緣節(jié)點(diǎn)做加解密broker 內(nèi)部走明文性能會(huì)好很多。第四條驗(yàn)證比配置重要。參數(shù)配上去不代表生效用strace看一眼 sendfile 有沒(méi)有真的在跑往往能省下幾個(gè)小時(shí)的瞎猜。這套方法我后來(lái)用在文件服務(wù)、靜態(tài)資源分發(fā)上同樣有效凡是懷疑零拷貝沒(méi)起作用的場(chǎng)合先抓一把系統(tǒng)調(diào)用再說(shuō)。最后分享一個(gè)觀察真正把零拷貝用好的系統(tǒng)用戶態(tài)代碼往往特別薄 —— 它只負(fù)責(zé)控制流程不碰數(shù)據(jù)本體。這個(gè)設(shè)計(jì)思路本身就值得借鑒不管你做的是消息隊(duì)列、文件服務(wù)還是數(shù)據(jù)管道減少不必要的數(shù)據(jù)經(jīng)過(guò)用戶態(tài)通常都能換來(lái)實(shí)打?qū)嵉男阅芴嵘?。至于具體選 sendfile 還是 mmap回到那句判斷要不要改數(shù)據(jù)。不需要改就讓它一路走內(nèi)核。