2025 年 3 月 18 日，Apache Kafka 4.0 正式發(fā)布。 在此次版本更新中，相較于架構(gòu)層面的升級(jí)，開發(fā)者們也應(yīng)關(guān)注一個(gè)關(guān)鍵的細(xì)節(jié)變更：官方將生產(chǎn)者參數(shù) linger.ms 的默認(rèn)值，從沿用多年的 0ms 正式修改為 5ms。

這一調(diào)整直擊傳統(tǒng)性能調(diào)優(yōu)的認(rèn)知盲區(qū)，在傳統(tǒng)觀念中，linger.ms=0 意味著“零等待”和實(shí)時(shí)發(fā)送，通常被視為降低延遲的首選策略。然而，Kafka 4.0 的默認(rèn)值變更揭示了一個(gè)更深層的性能邏輯：在復(fù)雜的網(wǎng)絡(luò) I/O 模型中，單純追求發(fā)送端的實(shí)時(shí)性并不等同于全局的低延遲。通過引入微小的“人工延遲”來換取更高的批處理效率，往往能顯著降低系統(tǒng)的延遲。

以 Kafka 4.0 的默認(rèn)值變更為契機(jī)，本文將 深入分析 linger.ms 和 batch.size 這兩個(gè)核心參數(shù)背后的協(xié)同機(jī)制。幫助你在面對(duì)復(fù)雜的生產(chǎn)環(huán)境時(shí)，基于原理掌握 linger.ms 和 batch.size 的最佳實(shí)踐。

1 linger.ms 和 batch.size 參數(shù)

為了透徹理解這次變更背后的深層邏輯，首先我們需要回歸基礎(chǔ)，準(zhǔn)確理解這兩個(gè)核心參數(shù)的概念。

linger.ms

生產(chǎn)者會(huì)將兩次請(qǐng)求傳輸之間到達(dá)的所有記錄組合成單一的批處理請(qǐng)求。這種攢批行為通常在記錄到達(dá)速率超過發(fā)送速率的高負(fù)載場(chǎng)景下自然發(fā)生，但在負(fù)載適中時(shí)，客戶端也可通過配置 linger.ms 引入少量的“人為延遲”來主動(dòng)減少請(qǐng)求數(shù)量。其行為邏輯類似于 TCP 協(xié)議中的 Nagle 算法：生產(chǎn)者不再立即發(fā)送每一條到達(dá)的記錄，而是等待一段指定的時(shí)間以聚合更多后續(xù)記錄。該設(shè)置定義了批處理的時(shí)間上限，發(fā)送行為遵循“先滿足者優(yōu)先”原則——一旦分區(qū)積累的數(shù)據(jù)量達(dá)到 batch.size，無論 linger.ms 是否到期，批次都會(huì)立即發(fā)送；反之，若數(shù)據(jù)量不足，生產(chǎn)者將“逗留”指定時(shí)長(zhǎng)以等待更多記錄。在 Apache Kafka 4.0 中，該參數(shù)的默認(rèn)值已從 0ms 調(diào)整為 5ms，其依據(jù)在于更大批次帶來的效率增益通常足以抵消引入的等待時(shí)間，從而實(shí)現(xiàn)持平甚至更低的整體生產(chǎn)者延遲。

batch.size

當(dāng)多條記錄需發(fā)往同一分區(qū)時(shí)，生產(chǎn)者會(huì)將這些記錄聚合為批次（Batch）以減少網(wǎng)絡(luò)請(qǐng)求頻率，從而優(yōu)化客戶端與服務(wù)端的 I/O 性能。batch.size 參數(shù)定義了該批次的默認(rèn)容量上限（以字節(jié)為單位），超過該閾值的單條記錄將不被納入批處理邏輯。發(fā)往 Broker 的單個(gè)請(qǐng)求通常包含多個(gè)批次，分別對(duì)應(yīng)不同的分區(qū)。配置過小的 batch.size 會(huì)限制批處理的發(fā)生頻率并可能降低吞吐量（設(shè)置為 0 將完全禁用批處理）；而過大的配置則可能因生產(chǎn)者總是基于此閾值預(yù)分配緩沖區(qū)而導(dǎo)致內(nèi)存資源的輕微浪費(fèi)。該設(shè)置確立了發(fā)送行為的空間上限：若當(dāng)前分區(qū)積累的數(shù)據(jù)量未達(dá)到此閾值，生產(chǎn)者將依據(jù) linger.ms（默認(rèn)為 5ms）的設(shè)定進(jìn)行等待；發(fā)送觸發(fā)邏輯遵循“先滿足者優(yōu)先（Whichever happens first）”原則，即一旦數(shù)據(jù)量填滿緩沖區(qū)或等待時(shí)間耗盡，批次即會(huì)被發(fā)送。需要注意的是，Broker 端的背壓可能導(dǎo)致實(shí)際的有效等待時(shí)間超過配置值。

通過對(duì)兩個(gè)維度的拆解，我們可以清晰地看到 linger.ms 和 batch.size 的協(xié)同工作模式：

• 它們共同決定了 RecordBatch（批次）的大小和 ProduceRequest（請(qǐng)求）的發(fā)送時(shí)機(jī)。

• linger.ms 和 batch.size 參數(shù)值較大 -> RecordBatch 和 ProduceRequest 批處理效果越好 -> Kafka 服務(wù)器需要處理的 RPC 數(shù)量更少 -> Kafka 服務(wù)端 CPU 消耗越低。

• 副作用：客戶端在批處理上花費(fèi)的時(shí)間增加，從而導(dǎo)致客戶端的發(fā)送延遲變高。

這引出了一個(gè)關(guān)鍵的性能權(quán)衡問題：

“在服務(wù)端 CPU 資源充足的前提下，為了追求極致的低延遲。是否應(yīng)當(dāng)盡可能最小化 linger.ms 和 batch.size？”

基于直覺的推斷，答案似乎是肯定的。然而，Kafka 4.0 的官方文檔指出了相反的結(jié)論：

“Apache Kafka 4.0 將默認(rèn)值從 0 調(diào)整為 5。盡管增加了人為的等待時(shí)間，但更大批次帶來的處理效率提升，通常會(huì)導(dǎo)致相似甚至更低的生產(chǎn)者延遲?！?/blockquote>

inger.ms=0 代表即時(shí)發(fā)送，為什么在延遲的表現(xiàn)上反而不如“先等待 5ms”？

2 Kafka 服務(wù)端與客戶端交互的底層規(guī)則

要透徹理解這一反直覺的性能表現(xiàn)，我們不能僅停留在客戶端配置的表面，而必須深入 Apache Kafka 網(wǎng)絡(luò)協(xié)議的底層。延遲的產(chǎn)生，本質(zhì)上源于客戶端發(fā)送策略與服務(wù)端處理模型之間的交互機(jī)制。為了探究其根源，我們需要分別從服務(wù)端和客戶端兩個(gè)維度，解析這套底層規(guī)則的運(yùn)作邏輯。

服務(wù)端視角：嚴(yán)格按序的“串行”模式

Kafka 的網(wǎng)絡(luò)協(xié)議在設(shè)計(jì)上與 HTTP 1.x 頗為相似，它采用的是一種嚴(yán)格的順序且串行的工作模式。這是理解所有延遲問題的基石：

• 順序性（Sequential）： 對(duì)于來自同一個(gè) TCP 連接的請(qǐng)求，服務(wù)端必須嚴(yán)格按照接收到的順序進(jìn)行處理，并按同樣的順序返回響應(yīng)。

• 串行性（Serial）：服務(wù)端只有在完全處理完當(dāng)前請(qǐng)求并發(fā)送響應(yīng)后，才會(huì)開始處理下一個(gè)請(qǐng)求。即便客戶端并發(fā)發(fā)送 N 個(gè) ProduceRequest，服務(wù)端也會(huì)嚴(yán)格執(zhí)行‘One-by-One’策略：必須等到前一個(gè)請(qǐng)求的數(shù)據(jù)完成所有 ISR 副本同步并返回響應(yīng)后，才會(huì)開始處理下一個(gè)請(qǐng)求。

這意味著：哪怕客戶端一股腦地并發(fā)發(fā)送了 N 個(gè) ProduceRequest，服務(wù)端也不會(huì)并行處理。如果前一個(gè)請(qǐng)求因?yàn)?ISR 同步卡頓了，后續(xù)的所有請(qǐng)求都只能在服務(wù)端排隊(duì)等候。

客戶端視角：化解擁堵的“Batch”原理

在客戶端側(cè)，Producer 的批處理主要包含兩個(gè)核心模塊：RecordAccumulator 和 Sender，分別對(duì)應(yīng) RecordBatch 和 ProduceRequest。

• RecordAccumulator：負(fù)責(zé)將 RecordBatch 進(jìn)行批處理。KafkaProducer 將記錄放入 RecordAccumulator 進(jìn)行批處理。當(dāng)分區(qū)內(nèi)的 ProduceBatch 數(shù)據(jù)超過 batch.size 時(shí)，它會(huì)切換到下一個(gè)分區(qū)并創(chuàng)建一個(gè)新的 ProduceBatch 進(jìn)行批處理。

• Sender：負(fù)責(zé)維護(hù)與服務(wù)器節(jié)點(diǎn)的連接并分批發(fā)送數(shù)據(jù)。它會(huì)基于節(jié)點(diǎn)從 RecordAccumulator 中排干就緒分區(qū)的數(shù)據(jù)，將它們打包成 ProduceRequest 并發(fā)送。排干需要同時(shí)滿足以下條件：

• • 連接上的在途請(qǐng)求數(shù)量小于 max.in.flight.requests.per.connection=5

  • 對(duì)應(yīng)節(jié)點(diǎn)的任何 ProduceBatch 超過 linger.ms 或超過 batch.size

3 場(chǎng)景推演：0ms 與 5ms 的性能對(duì)比

基于上述原理，我們需要進(jìn)一步評(píng)估該機(jī)制在實(shí)際場(chǎng)景中的表現(xiàn)。當(dāng)客戶端配置 linger.ms=0 以執(zhí)行即時(shí)發(fā)送策略，而服務(wù)端受限于串行處理模型時(shí)，供需兩側(cè)的處理節(jié)奏將產(chǎn)生錯(cuò)配。為了準(zhǔn)確判斷這種錯(cuò)配究竟是降低了延遲還是引發(fā)了排隊(duì)積壓，僅憑定性分析不足以說明問題。接下來，我們將構(gòu)建一個(gè)模型，通過場(chǎng)景化的定量推演，計(jì)算不同配置下的具體延遲數(shù)據(jù)。

場(chǎng)景假設(shè)：

• 部署一個(gè)單節(jié)點(diǎn)集群，創(chuàng)建一個(gè)包含 10 個(gè)分區(qū)的 Topic。

• 客戶端：?jiǎn)慰蛻舳?，發(fā)送速率 1000 條記錄 / 秒，記錄大小 1KB。

• 服務(wù)端：處理一個(gè) ProduceRequest 耗時(shí) 5ms。

• 對(duì)比組：

• • 配置 A：linger.ms=0，batch.size=16KB（Apache Kafka 4.0 之前的默認(rèn)配置）

  • 配置 B：linger.ms=5，其余不變（4.0 新版默認(rèn)）

推演 A：當(dāng) linger.ms = 0

• 1,000 records/s意味著每 1ms 調(diào)用一次 KafkaProducer；

• 由于 linger.ms=0，前 5 條記錄會(huì)立即轉(zhuǎn)換為 5 個(gè) ProduceRequest，分別在時(shí)間戳 T=0ms，T=0.1ms， ...，T=0.4ms 發(fā)送。

• Apache Kafka 順序且串行地處理這 5 個(gè) ProduceRequest：

• • T=5ms：Apache Kafka 完成第 1 個(gè) ProduceRequest 的請(qǐng)求，返回響應(yīng)，并開始處理下一個(gè) ProduceRequest；

  • T=10ms：第 2 個(gè) ProduceRequest 處理完畢，開始處理下一個(gè)；

  • 以此類推，第 5 個(gè) ProduceRequest 在 T=25ms 時(shí)處理完畢。

• T=5ms：客戶端收到第 1 個(gè) ProduceRequest 的響應(yīng)，滿足 inflight.request < 5 的條件，從 RecordAccumulator 排干數(shù)據(jù)。此時(shí)，內(nèi)存中已積累了 （5 - 0.4） / 1 ～= 4K 的數(shù)據(jù)，這些數(shù)據(jù)將被放入一個(gè) ProduceRequest 中，Sender 將其打包成第 6 個(gè)請(qǐng)求發(fā)出。

• • T=30ms：Apache Kafka 在 T=25ms 處理完第 5 個(gè)請(qǐng)求后，接著處理第 6 個(gè)請(qǐng)求，并在 T=30ms 返回響應(yīng)。

T=10ms：同樣地，收到第 2 個(gè) ProduceRequest 的響應(yīng)后，客戶端積累了 （10 - 5） / 1 = 5K 的數(shù)據(jù)并發(fā)送給 Broker。Apache Kafka 在 T=35ms 返回響應(yīng)。

• 以此類推，后續(xù)的 ProduceRequest 都會(huì)在 T1 時(shí)刻積累 5K 數(shù)據(jù)并發(fā)送給 Broker，Broker 會(huì)在 T1 + 25ms 響應(yīng)請(qǐng)求。平均生產(chǎn)延遲為 5ms / 2 + 25ms = 27.5ms。（5ms / 2 是平均批處理時(shí)間）。

推演 B：當(dāng) linger.ms = 5

• T=5ms：由于 linger.ms=5，客戶端會(huì)先積攢數(shù)據(jù)直到 5ms，然后發(fā)出第一個(gè) ProduceRequest。服務(wù)端會(huì)在 T=10ms 時(shí)對(duì)該請(qǐng)求做出響應(yīng)。

• T=10ms：由于 linger.ms=5，客戶端會(huì)繼續(xù)積攢新數(shù)據(jù)達(dá) 5ms，隨后發(fā)出第二個(gè) ProduceRequest。服務(wù)端會(huì)在 T=15ms 時(shí)做出響應(yīng)。

• 以此類推： 后續(xù)的請(qǐng)求都會(huì)在 T1 時(shí)刻攢夠 5K 數(shù)據(jù)后發(fā)往 Broker，Broker 會(huì)在 T1 + 5ms 時(shí)做出響應(yīng)。此時(shí)的平均生產(chǎn)延遲計(jì)算如下：5ms / 2 + 5ms = 7.5ms（注：5ms / 2 代表平均攢批的時(shí)間）。

在這個(gè)假設(shè)場(chǎng)景中，雖然我們將 linger.ms 從 0 ms 增加到 5 ms，但平均生產(chǎn)延遲反而從 27.5 ms 降到了 7.5 ms。由此可見，“l(fā)inger.ms 越小，延遲越低”這一說法并不絕對(duì)成立。

4 linger.ms 與 batch.size 配置最佳實(shí)踐

通過對(duì)比 linger.ms 為 0ms 和 5ms 的情況，我們可以得出結(jié)論：客戶端的主動(dòng)批處理，將 在途請(qǐng)求控制在 1 及以內(nèi)，要比快速把請(qǐng)求發(fā)出然后在網(wǎng)絡(luò)層排隊(duì)，更能降低生產(chǎn)延遲。

那么如何在千變?nèi)f化的生產(chǎn)環(huán)境中，精準(zhǔn)設(shè)定這兩個(gè)參數(shù)的閾值？

我們需要一套科學(xué)的計(jì)算公式，根據(jù)服務(wù)端的實(shí)際處理能力，倒推客戶端的最佳配置。以下是針對(duì)最小化生產(chǎn)延遲的定向配置建議：

• linger.ms >= 服務(wù)端處理耗時(shí)。

如果 linger.ms 小于網(wǎng)絡(luò)耗時(shí)和服務(wù)端的處理時(shí)間，根據(jù) Kafka 網(wǎng)絡(luò)協(xié)議的串行處理模式，發(fā)出的 ProduceRequests 就會(huì)在網(wǎng)絡(luò)層產(chǎn)生積壓。這違背了我們前面提到的“將網(wǎng)絡(luò)在途請(qǐng)求數(shù)控制在 1 及以內(nèi)”的原則。

• batch.size >= （單個(gè)客戶端最大寫入吞吐量） * （linger.ms / 1000） / （Broker 數(shù)量）。

如果 batch.size 未設(shè)置為大于或等于此值，則意味著在達(dá)到 linger.ms 之前，由于 ProduceBatch 超過 batch.size，將會(huì)被迫提前發(fā)送請(qǐng)求。同樣，這些 ProduceRequest 無法及時(shí)處理，將在網(wǎng)絡(luò)中排隊(duì)，違反了 “將網(wǎng)絡(luò)在途請(qǐng)求數(shù)控制在 1 及以內(nèi)”的原則。

• 建議將 batch.size 設(shè)置得盡可能大（例如 256K）：

linger.ms 是基于服務(wù)端的平均生產(chǎn)延遲來設(shè)定的。一旦服務(wù)端出現(xiàn)性能抖動(dòng)（Jitter），更大的 batch.size 允許我們?cè)趩蝹€(gè) RecordBatch 中積攢更多數(shù)據(jù)，從而避免因?yàn)椴鸱殖啥鄠€(gè)小請(qǐng)求發(fā)送而導(dǎo)致整體延遲升高。

以單節(jié)點(diǎn)集群為例，假設(shè)服務(wù)器處理一個(gè) ProduceRequest 需要 5ms。那么我們需要將 linger.ms 設(shè)置為至少 5ms。如果我們預(yù)期單個(gè)生產(chǎn)者的發(fā)送速度能達(dá)到 10MBps，那么 batch.size 應(yīng)設(shè)置為至少 10 * 1024 *（5 / 1000）= 51.2K。

5 從“客戶端攢批”走向“服務(wù)端流水線”

Apache Kafka 4.0 對(duì)默認(rèn)值的調(diào)整，驗(yàn)證了一個(gè)核心的技術(shù)共識(shí)：在處理大規(guī)模數(shù)據(jù)流時(shí)，適度的批處理是平衡吞吐與延遲的有效手段。這是一種基于客戶端視角的成熟優(yōu)化策略。

然而，性能優(yōu)化的路徑不止一條。既然瓶頸在于服務(wù)端的“串行處理”，那么除了一味調(diào)整客戶端參數(shù)外，我們是否可以從服務(wù)端本身尋求突破？正是基于這一思考，作為云原生 Kafka 的探索者，AutoMQ 嘗試從服務(wù)端視角尋找新的突破：在完全兼容 Kafka 協(xié)議語義的前提下，AutoMQ 引入了“Pipeline（流水線）機(jī)制”。這一機(jī)制并非改變協(xié)議本身，而是優(yōu)化了服務(wù)端的模型，使得在保證順序性的同時(shí)，能夠充分利用云原生存儲(chǔ)的并發(fā)能力，將 ProduceRequest 的處理效率提升了 5 倍。

這意味著什么？讓我們回到之前的推演場(chǎng)景：

即便在 linger.ms=0 導(dǎo)致多個(gè)在途請(qǐng)求積壓的情況下，AutoMQ 的流水線機(jī)制允許服務(wù)端同時(shí)處理這些請(qǐng)求，顯著降低了排隊(duì)延遲：

• Apache Kafka：由于串行排隊(duì)，平均延遲達(dá) 27.5ms。

• AutoMQ：憑借流水線機(jī)制，平均延遲降至 7.5ms。

因此，當(dāng)使用 AutoMQ 作為服務(wù)端時(shí)，你可以享受服務(wù)端處理效率的 5 倍提升，客戶端不再需要通過長(zhǎng)時(shí)間的“逗留”來遷就服務(wù)端，從而獲得更低的延遲體驗(yàn)。你可以將參數(shù)配置為原建議值的 1/5，linger.ms 的配置策略會(huì)與 Apache Kafka 略有不同：

• linger.ms >= (服務(wù)端處理耗時(shí) / 5）

• batch.size >= (單個(gè)客戶端最大寫入吞吐量) * (linger.ms / 1000) / (Broker 數(shù)量)

（注：同樣建議在內(nèi)存允許范圍內(nèi)，將 batch.size 盡可能調(diào)大，如 256K）

這種配置上的差異，揭示了性能優(yōu)化視角的轉(zhuǎn)變：要做到性能調(diào)優(yōu)，不能僅依賴于客戶端的適配。

AutoMQ 通過架構(gòu)層面的創(chuàng)新實(shí)踐，讓用戶無需在“低延遲”和“高吞吐”之間做艱難的權(quán)衡，而是以更低的門檻實(shí)現(xiàn)了兩者的兼得。技術(shù)總是在不斷演進(jìn)的。從參數(shù)調(diào)優(yōu)走向架構(gòu)演進(jìn)，不僅是 AutoMQ 的選擇，也是云原生時(shí)代消息中間件發(fā)展的方向。

6 結(jié)語

感謝您讀到這里。

本文回顧了 Apache Kafka 4.0 中 linger.ms 與 batch.size 參數(shù)的配置，指出了在傳統(tǒng)串行網(wǎng)絡(luò)模型下，客戶端進(jìn)行性能調(diào)優(yōu)時(shí)所面臨的“延遲與吞吐”權(quán)衡難題。隨后，我們深入解析了 AutoMQ 的 Pipeline 機(jī)制，它通過服務(wù)端 I/O 模型的重構(gòu)，解除了順序處理與串行執(zhí)行的強(qiáng)綁定。

Pipeline 機(jī)制是 AutoMQ 云原生架構(gòu)的核心特性之一，無需依賴繁瑣的客戶端參數(shù)調(diào)整，即可在保證數(shù)據(jù)嚴(yán)格順序的前提下，實(shí)現(xiàn) 5 倍于傳統(tǒng)架構(gòu)的處理效率。結(jié)合對(duì)云原生存儲(chǔ)的深度適配，AutoMQ 致力于通過底層架構(gòu)的演進(jìn)，助力企業(yè)以更簡(jiǎn)的運(yùn)維構(gòu)建極致性能的流數(shù)據(jù)平臺(tái)。

感謝您的閱讀，我們下篇文章再見。