前陣子業(yè)務(wù)告警群里又炸了——消費(fèi)延遲從平時(shí)的幾百毫秒一路飆到分鐘級(jí)P99 延遲曲線在監(jiān)控面板上直接拉成一條陡坡。接手這套 Kafka 系統(tǒng)兩年類似的戲碼每隔一陣就重演一次。與其每次都臨時(shí)救火不如把全鏈路參數(shù)優(yōu)化這件事系統(tǒng)捋一遍。這篇是 Kafka 系列進(jìn)階的第二篇核心只聊三件事吞吐量怎么往上提延遲怎么按得住以及在兩者互相拉扯時(shí)參數(shù)該怎么取舍。適合已經(jīng)跑通過基礎(chǔ)收發(fā)流程、想深挖性能的開發(fā)者也適合被消費(fèi)積壓折騰過的運(yùn)維同事參考。1. 調(diào)優(yōu)第一步先定義指標(biāo)再開始擰參數(shù)1.1 吞吐和延遲是一對(duì)天生的對(duì)手很多人一上來就急著改參數(shù)結(jié)果參數(shù)堆了一堆業(yè)務(wù)還是抱怨延遲高。問題往往出在沒想清楚你到底要優(yōu)化什么。Kafka 的吞吐和延遲在絕大多數(shù)場(chǎng)景下是互相較勁的。想要吞吐高核心手段是攢批——把多條消息攢成一個(gè)大批次發(fā)出去網(wǎng)絡(luò)包更少、磁盤順序?qū)懜咝У鷥r(jià)是消息在生產(chǎn)端多等了一段時(shí)間。想要延遲低就得來一條發(fā)一條減少等待代價(jià)是網(wǎng)絡(luò)往返次數(shù)暴增吞吐自然上不去。我用一個(gè)類比給團(tuán)隊(duì)講過這事攢批好比拼車拼車要等乘客湊齊才發(fā)車滿載率高、單趟運(yùn)的人多但乘客可能多等幾分鐘低延遲好比打?qū)＼囯S叫隨走單人單趟體驗(yàn)好但運(yùn)力效率低。調(diào)優(yōu)的本質(zhì)就是搞清你的業(yè)務(wù)到底適合拼車還是專車。1.2 先把指標(biāo)口徑定清楚動(dòng)手之前一定要把指標(biāo)定義明白否則后面全是糊涂賬。第一個(gè)指標(biāo)是吞吐量。線上一般用兩種口徑每秒處理的消息條數(shù)msg/s和每秒處理的字節(jié)數(shù)MB/s。消息體積差異很大時(shí)只看條數(shù)是會(huì)騙人的——一個(gè)小消息場(chǎng)景每秒幾十萬條大消息場(chǎng)景可能每秒不到一萬條但后者的帶寬壓力反而更大。第二個(gè)指標(biāo)是延遲。這里要區(qū)分端到端延遲和單段耗時(shí)端到端是從 Producer 發(fā)送消息到 Consumer 真正拿到消息的完整時(shí)間通常用 P99 甚至 P999 衡量比平均值更能反映真實(shí)體驗(yàn)。平均值拉平了毛刺P99 才能暴露出尾部的慢請(qǐng)求。建議在優(yōu)化前寫下一行目標(biāo)比如吞吐達(dá)到 8 萬條/秒端到端 P99 小于 50ms。有了這個(gè)數(shù)字后面每個(gè)參數(shù)的取舍都有依據(jù)不會(huì)東一榔頭西一棒子。1.3 沒有基線調(diào)優(yōu)就是在裸奔這個(gè)坑我踩過不止一次。有一次接手某個(gè)日志采集系統(tǒng)我直接調(diào)高了壓縮和批量參數(shù)吞吐從 4 萬漲到 6 萬當(dāng)時(shí)還挺得意。結(jié)果業(yè)務(wù)第二天找過來說 P99 從 30ms 漲到了 130ms他們完全不能接受最后只能回滾。那次之后我給自己立了規(guī)矩調(diào)優(yōu)前先壓一輪測(cè)試記錄基線數(shù)據(jù)之后每改一個(gè)參數(shù)都拿新數(shù)據(jù)和基線對(duì)比?；€數(shù)據(jù)至少包括吞吐量、P99 延遲、Broker CPU、內(nèi)存、磁盤 IO 這幾項(xiàng)。沒有基線所謂的優(yōu)化只是憑感覺出了問題連是哪個(gè)參數(shù)拖累的都說不清楚。2. Producer 端參數(shù)在攢批與實(shí)時(shí)性之間精打細(xì)算2.1 acks 是可靠性和吞吐的第一道杠桿acks參數(shù)決定了 Producer 要等到多少副本確認(rèn)后才認(rèn)為發(fā)送成功它對(duì)語義的影響遠(yuǎn)大于對(duì)吞吐的影響。acks0表示消息發(fā)出就算成功不管 Broker 是否收到。這種配置吞吐最高但丟消息概率也最高除了極端的監(jiān)控日志場(chǎng)景生產(chǎn)環(huán)境我不建議用。acks1表示 leader 副本寫入成功就算成功這是吞吐和可靠性的常見折中點(diǎn)。acksall表示所有 ISR 副本都寫入成功才算成功配合min.insync.replicas才能保證 leader 掛了也不丟已確認(rèn)消息。很多人一看到acksall就本能抗拒覺得吞吐肯定垮。實(shí)際上只要分區(qū)數(shù)充足、ISR 里沒有拖后腿的慢副本acksall的額外代價(jià)沒有想象中那么大。真正讓性能崩掉的往往不是 acks 本身而是某個(gè)副本同步跟不上ISR 反復(fù)收縮整個(gè)發(fā)送鏈路被卡住。所以別只盯著參數(shù)副本健康狀態(tài)更要時(shí)刻盯緊。2.2 攢批三兄弟linger.ms、batch.size、buffer.memory這三個(gè)參數(shù)是 Producer 吞吐優(yōu)化的重頭戲也最容易讓人迷惑。linger.ms默認(rèn)是 0也就是來一條發(fā)一條。對(duì)單條幾百字節(jié)的小消息來說這等于每發(fā)一條消息都要消耗一次完整的網(wǎng)絡(luò)往返吞吐非常難看。調(diào)到 5~20ms 后Producer 會(huì)在這段時(shí)間內(nèi)攢消息盡量填滿批次再發(fā)送。這里有個(gè)理解誤區(qū)linger.ms不是每條消息都必須等這么久它只是最長等待時(shí)間如果batch.size提前攢滿批次會(huì)立刻發(fā)出。所以延遲敏感的場(chǎng)景設(shè) 5~10ms吞吐優(yōu)先的場(chǎng)景設(shè) 20ms 甚至更高都不會(huì)出現(xiàn)每條消息都被卡住的錯(cuò)覺。batch.size默認(rèn) 16KB指的是單個(gè)批次的內(nèi)存上限不是攢夠多少條才發(fā)。如果單條消息 1KB16KB 大約能裝 16 條這個(gè)批次容量太平庸如果單條消息 10KB16KB 的批次可能一條消息就占滿攢批效果為零。經(jīng)驗(yàn)做法用單條消息大小 × 期望的批次條數(shù)來估算比如每條 1KB、希望一個(gè)批次裝 200 條就設(shè)batch.size256KB左右。buffer.memory默認(rèn) 32MB是 Producer 緩沖區(qū)總量。當(dāng) Broker 處理不過來時(shí)消息會(huì)堆積在內(nèi)存里一旦緩沖區(qū)滿了send()就會(huì)阻塞最長等待max.block.ms默認(rèn) 60s。調(diào)大這個(gè)值能扛突發(fā)流量但積壓消息也意味著延遲升高這是躲不開的權(quán)衡。2.3 壓縮選型用 CPU 換帶寬和磁盤當(dāng)網(wǎng)絡(luò)或磁盤成為瓶頸時(shí)開啟壓縮往往是性價(jià)比最高的動(dòng)作。compression.type默認(rèn)是none但這在真實(shí)高吞吐場(chǎng)景里很少是最優(yōu)解。三個(gè)常見選項(xiàng)lz4壓縮速度快、CPU 開銷小適合對(duì)吞吐敏感的在線鏈路zstd壓縮率最高大約比lz4再省 20%~30% 空間但 CPU 開銷更大gzip現(xiàn)在基本不推薦了壓得慢又耗 CPU。壓縮這件事是 Kafka 自動(dòng)透明的Broker 存的是壓縮后的數(shù)據(jù)Consumer 拿到的還是解壓后的原始消息使用方無感知。我實(shí)測(cè)過一組數(shù)據(jù)在千兆網(wǎng)卡接近打滿的集群里單條 1KB 的 JSON 日志開zstd之后吞吐量提升了差不多 1.5 倍。代價(jià)是消費(fèi)端反序列化時(shí)多花一點(diǎn) CPU但只要消費(fèi)邏輯不復(fù)雜這個(gè)開銷通常不是瓶頸。2.4 一個(gè)可以直接參考的 Producer 配置清單下面這份配置是我在延遲目標(biāo) P99 小于 80ms、又希望吞吐盡量高的場(chǎng)景下反復(fù)壓測(cè)后留下的版本acksall linger.ms10 batch.size65536 buffer.memory67108864 compression.typelz4 max.block.ms5000 enable.idempotencetrue開啟冪等后Producer 會(huì)自動(dòng)帶上 sequence numberBroker 能識(shí)別重復(fù)消息并去重代價(jià)幾乎可以忽略。如果業(yè)務(wù)完全不能接受任何重復(fù)消息這套配置能保證 exactly-once 語義的基礎(chǔ)前提。注意linger.ms10配合batch.size64KB不是說每條消息都會(huì)等滿 10ms而是批次滿了就發(fā)網(wǎng)絡(luò)空閑時(shí)最多等 10ms 就發(fā)出對(duì)在線業(yè)務(wù)的延遲壓力完全可以接受。3. Broker 端參數(shù)分區(qū)數(shù)、副本機(jī)制與 IO 模型3.1 分區(qū)數(shù)不是越大越好分區(qū)數(shù)決定了 Kafka 的并行度上限——一個(gè)分區(qū)的消息只能被同一消費(fèi)組里的一個(gè)消費(fèi)者線程消費(fèi)所以分區(qū)越多理論上消費(fèi)并行度越高。但越多越好是新手最容易犯的錯(cuò)誤之一。分區(qū)多帶來的代價(jià)很實(shí)在每個(gè)分區(qū)都有獨(dú)立的 leader/follower 日志段和索引文件文件句柄占用隨之增加副本同步時(shí)Follower 線程需要逐個(gè)分區(qū)拉取消息分區(qū)太多會(huì)讓同步效率下降極端情況下分區(qū)數(shù)過多還會(huì)拖慢 leader 選舉和 ISR 收縮的速度。經(jīng)驗(yàn)做法是從吞吐倒推先估算單分區(qū)的極限吞吐通常單分區(qū)順序?qū)懘疟P時(shí)可以跑到幾十 MB/s再用目標(biāo)峰值吞吐 / 單分區(qū)吞吐算出分區(qū)數(shù)下限最后留 1.5~2 倍余量。比如目標(biāo)峰值 200MB/s單分區(qū)按 50MB/s 算至少需要 4 個(gè)分區(qū)保守一點(diǎn)建 8 個(gè)分區(qū)。另外要記住分區(qū)只建議增加不建議減少因?yàn)闇p少分區(qū)會(huì)觸發(fā)完整重平衡風(fēng)險(xiǎn)不小。3.2 副本機(jī)制min.insync.replicas 和 unclean 選舉副本參數(shù)的核心是解決leader 掛了如何保證不丟消息。min.insync.replicas默認(rèn)是 1如果 Producer 端設(shè)了acksall我強(qiáng)烈建議把 Broker 端的min.insync.replicas設(shè)為 2。兩者配合消息只有在leader 至少 1 個(gè) follower都寫入成功后才算確認(rèn)這樣即使 leader 掛了已確認(rèn)的消息在另一個(gè)副本里仍然完整存在。但這個(gè)配置不是免費(fèi)的當(dāng) ISR 里的存活副本數(shù)少于 2 時(shí)Producer 發(fā)送會(huì)直接報(bào)NotEnoughReplicas異常相當(dāng)于用可用性換可靠性。所以是否要設(shè)成 2要看業(yè)務(wù)能不能接受短時(shí)寫入失敗。通常 3 副本 min.insync.replicas2 是比較穩(wěn)妥的組合。unclean.leader.election.enable這個(gè)參數(shù)更要小心。它默認(rèn)是 false但偶爾有運(yùn)維為了盡量讓分區(qū)有 leader而改成 true。這是一條不能碰的紅線開啟后leader 掛了可能會(huì)選一個(gè)數(shù)據(jù)落后很多的副本頂上直接造成大量已確認(rèn)消息丟失。寧可短暫不可用也堅(jiān)決不要啟用 unclean 選舉。3.3 IO 線程和網(wǎng)絡(luò)線程怎么調(diào)num.network.threads默認(rèn) 3負(fù)責(zé)處理網(wǎng)絡(luò)連接與請(qǐng)求收發(fā)num.io.threads默認(rèn) 8負(fù)責(zé)磁盤讀寫和實(shí)際的消息存儲(chǔ)操作。這兩個(gè)參數(shù)沒有萬能答案得結(jié)合機(jī)器核數(shù)和實(shí)際壓測(cè)來定。在 16 核以上的機(jī)器上我通常會(huì)把num.io.threads調(diào)到 12 到 16網(wǎng)絡(luò)線程調(diào)到 4 到 6。但要注意IO 線程和網(wǎng)絡(luò)線程不吃內(nèi)存它們吃的是 CPU。線程設(shè)太多上下文切換開銷會(huì)把收益抵消掉。最穩(wěn)妥的辦法是壓測(cè)時(shí)用top觀察 CPU 使用率如果多個(gè)核心都跑到了 80% 以上再加線程已經(jīng)沒有意義瓶頸已經(jīng)轉(zhuǎn)移到磁盤或網(wǎng)絡(luò)上。3.4 頁緩存Kafka 高性能的真正幕后功臣很多人以為 Kafka 的高吞吐全靠堆內(nèi)緩存其實(shí)恰恰相反。Kafka 在寫入時(shí)先落到操作系統(tǒng)的頁緩存page cache磁盤刷盤是異步的讀取時(shí)如果數(shù)據(jù)還在頁緩存里直接通過sendfile零拷貝發(fā)到 socketCPU 幾乎不參與數(shù)據(jù)復(fù)制。理解了這一點(diǎn)就明白為什么 Kafka 的 JVM 堆內(nèi)存不需要設(shè)太大——堆主要用來存分區(qū)元數(shù)據(jù)、索引信息和一些內(nèi)存池通常 6~8GB 就夠。把內(nèi)存盡量留給操作系統(tǒng)做頁緩存才是正確姿勢(shì)。我看到過有人把堆設(shè)到 20GB結(jié)果 GC 頻繁導(dǎo)致吞吐驟降這是典型的好心辦壞事。3.5 文件段與索引參數(shù)log.segment.bytes默認(rèn) 1GB控制日志段文件的大小。段越大單文件能容納的消息越多但段內(nèi)索引條目也越多段太小會(huì)導(dǎo)致段文件數(shù)量爆炸增加文件句柄和索引維護(hù)開銷。一般保持默認(rèn)即可不需要刻意調(diào)整。如果消息體積特別小且數(shù)據(jù)量巨大可以適當(dāng)調(diào)大到 2GB如果磁盤空間緊張也可以調(diào)小些但不建議低于 512MB。4. Consumer 端參數(shù)拉取窗口、消費(fèi)線程與重平衡4.1 fetch.min.bytes 與 fetch.max.wait.ms 的正確姿勢(shì)Consumer 是 pull 模式主動(dòng)去 Broker 拉數(shù)據(jù)。fetch.min.bytes控制至少攢多少字節(jié)才返回一次fetch.max.wait.ms控制最多等多久就返回一次。這兩個(gè)參數(shù)的關(guān)系和 Producer 端的batch.size linger.ms很像。想壓低延遲就把fetch.max.wait.ms設(shè)小比如 50~100ms這樣 Consumer 最多等這么短時(shí)間就有數(shù)據(jù)回來。想提高吞吐就把fetch.min.bytes調(diào)大比如 64KB 甚至更大這樣每次拉取都能帶走一批數(shù)據(jù)減少拉取次數(shù)。兩種思路對(duì)應(yīng)兩類業(yè)務(wù)場(chǎng)景在線接口關(guān)注延遲離線批處理關(guān)注吞吐。注意fetch.max.wait.ms默認(rèn) 500ms對(duì)小消息低延遲場(chǎng)景來說這個(gè)默認(rèn)值有點(diǎn)偏高。4.2 max.poll.records 和消費(fèi)循環(huán)的工期控制max.poll.records默認(rèn)是 500也就是一次poll()最多返回 500 條。這個(gè)參數(shù)的隱患在于如果每條消息的業(yè)務(wù)處理耗時(shí)很長一次 poll 返回 500 條可能要處理幾十秒一旦超過max.poll.interval.ms默認(rèn) 5 分鐘Consumer 會(huì)被判定為死亡并踢出消費(fèi)組觸發(fā)全體重平衡。我的建議是先算一筆賬單條消息的平均處理耗時(shí)乘以max.poll.records要保證一輪處理時(shí)間控制在幾秒內(nèi)。如果處理一條消息需要 20ms500 條就是 10 秒還勉強(qiáng)可以如果單條處理需要 100ms500 條就是 50 秒這時(shí)候要么把max.poll.records降到 100要么把處理邏輯異步化把poll()拿到的消息交給專門的工作線程池去處理。4.3 手動(dòng)提交 offset寧可重復(fù)不要丟失enable.auto.commit默認(rèn)是 true但生產(chǎn)環(huán)境我更建議改成 false然后手動(dòng)提交 offset。原因很簡(jiǎn)單自動(dòng)提交的時(shí)機(jī)不可控很可能在消息處理完成后、下次自動(dòng)提交前發(fā)生重平衡導(dǎo)致這批消息被重復(fù)消費(fèi)。手動(dòng)提交也有講究。最穩(wěn)妥的姿勢(shì)是先處理后提交保證消息真的處理成功了才更新 offset。這樣重平衡時(shí)最多重復(fù)消費(fèi)但不會(huì)丟數(shù)據(jù)。對(duì)大部分業(yè)務(wù)來說重復(fù)消費(fèi)比丟數(shù)據(jù)更容易接受配合消息冪等設(shè)計(jì)就能把這個(gè)副作用消掉。提交頻率上不需要每條都提交可以在一個(gè)處理批次結(jié)束后統(tǒng)一提交一次但務(wù)必確保在max.poll.interval.ms內(nèi)完成。在 Kafka 中消費(fèi)組需要在 session.timeout.ms 內(nèi)發(fā)送心跳。默認(rèn)值在不同版本略有差異如果消費(fèi)者處理耗時(shí)偏長可以把 session.timeout.ms 適當(dāng)調(diào)大但要記得同時(shí)調(diào)整心跳頻率和 max.poll.interval.ms否則反而容易觸發(fā)重平衡。4.4 重平衡高吞吐的隱形殺手重平衡rebalance是最容易被忽略的性能殺手。重平衡期間整個(gè)消費(fèi)組的所有消費(fèi)者都會(huì)暫停消費(fèi)直到分區(qū)重新分配完成。如果消費(fèi)組很大、掛掉一個(gè)消費(fèi)者導(dǎo)致全組 10 秒都不能消費(fèi)這損失比吞吐指標(biāo)低幾個(gè)百分點(diǎn)嚴(yán)重得多。觸發(fā)重平衡的常見原因包括消費(fèi)者加入或退出、訂閱的 topic 新增分區(qū)、心跳超時(shí)被踢出。降低影響的辦法有幾個(gè)一是使用靜態(tài)消費(fèi)者static membership讓消費(fèi)者重啟后保持原有成員身份避免觸發(fā)重平衡二是把heartbeat.interval.ms和session.timeout.ms合理配對(duì)心跳更快一點(diǎn)、超時(shí)更長一點(diǎn)三是最重要的——不要在 poll 循環(huán)里寫重量級(jí)邏輯比如同步訪問數(shù)據(jù)庫或調(diào)用遠(yuǎn)程接口這種慢操作幾乎一定會(huì)引發(fā)一連串重平衡。5. 容易被忽略的 OS 層頁緩存、swap 與網(wǎng)絡(luò)棧5.1 swap 是 Kafka 性能的隱形殺手虛擬內(nèi)存 swap 一旦被頻繁使用Kafka 的延遲和吞吐都會(huì)斷崖式下跌因?yàn)轫摼彺姹粨Q到磁盤讀寫直接打在慢速存儲(chǔ)上。Linux 默認(rèn)的vm.swappiness是 60這個(gè)值對(duì) Kafka 來說太高了。標(biāo)準(zhǔn)建議是設(shè)成 1甚至 0。設(shè)成 1 的意思是除非萬不得已否則別用 swap這樣既保留了 swap 作為內(nèi)存溢出的最后防線又不會(huì)讓內(nèi)核沒事就把 page cache 換出去。改法很簡(jiǎn)單寫到/etc/sysctl.conf里永久生效。這個(gè)參數(shù)看著不起眼但踩過 swap 坑的人都知道那是一種什么體驗(yàn)——明明磁盤和網(wǎng)絡(luò)都還好P99 就是莫名其妙飆到幾秒。5.2 文件句柄分區(qū)一多就爆的隱藏坑Kafka 每個(gè)分區(qū)、每個(gè)副本都會(huì)占用文件句柄尤其是分區(qū)數(shù)動(dòng)輒幾百上千時(shí)文件句柄很快會(huì)吃滿系統(tǒng)默認(rèn)限制。默認(rèn)ulimit -n在不少機(jī)器上只有 1024生產(chǎn)環(huán)境絕對(duì)不夠。建議把軟限制和硬限制都調(diào)高至少 65535 起步分區(qū)特別多的集群可以設(shè)到 100 萬以上。如果集群跑在容器或 Kubernetes 里還要檢查容器層面的 limit 配置否則宿主機(jī)改了沒用容器里照樣報(bào)Too many open files。這個(gè)坑很隱蔽一旦分區(qū)數(shù)漲上去Broker 可能莫名奇妙開始拒絕請(qǐng)求。5.3 網(wǎng)絡(luò)棧網(wǎng)卡隊(duì)列和 socket 緩沖高吞吐場(chǎng)景下網(wǎng)絡(luò)軟中斷會(huì)成為新的瓶頸。表現(xiàn)是單個(gè) CPU 核心的軟中斷占用率到 100%但其他核心很閑。解決辦法是開啟網(wǎng)卡多隊(duì)列ethtool -l能看到隊(duì)列數(shù)并讓irqbalance把不同隊(duì)列的中斷分散到多個(gè) CPU 核心上。socket 緩沖區(qū)大小也值得看一眼。net.core.rmem_max和net.core.wmem_max過小在高帶寬下會(huì)導(dǎo)致 TCP 吞吐受限?？梢栽?etc/sysctl.conf里調(diào)大這兩個(gè)值同時(shí)配合 Producer 端的socket.send.buffer.bytes和socket.receive.buffer.bytes一起調(diào)整。需要說明的是這一步屬于網(wǎng)絡(luò)瓶頸場(chǎng)景的專項(xiàng)調(diào)優(yōu)不是每個(gè)集群都必須動(dòng)。5.4 磁盤掛載與 IO 調(diào)度Kafka 強(qiáng)烈依賴磁盤順序?qū)懶阅芩源疟P掛載參數(shù)直接決定寫入穩(wěn)定性。掛載 ext4 時(shí)建議加上nodelalloc和noatime前者禁用延遲塊分配讓日志數(shù)據(jù)更及時(shí)落盤后者避免讀文件時(shí)產(chǎn)生不必要的 atime 寫 IO。后者避免了無謂的元數(shù)據(jù)寫入對(duì)小文件讀多的場(chǎng)景尤其友好。磁盤 IO 調(diào)度器方面機(jī)械盤建議使用deadline調(diào)度器SSD 建議使用none或noop避免內(nèi)核默認(rèn)的cfq在大量順序?qū)憟?chǎng)景造成調(diào)度延遲。6. 壓測(cè)方案用同一把尺子驗(yàn)證調(diào)優(yōu)效果6.1 官方工具比自定義腳本更省心Kafka 自帶的生產(chǎn)者和消費(fèi)者壓測(cè)工具是最省心的選擇它們變量少、結(jié)果格式統(tǒng)一、基本能滿足絕大多數(shù)基準(zhǔn)測(cè)試需求。生產(chǎn)者壓測(cè)命令大致長這樣kafka-producer-perf-test.sh \ --topic perf-test \ --num-records 5000000 \ --record-size 1024 \ --throughput 100000 \ --producer-props bootstrap.serversbroker-1:9092 \ linger.ms10 \ batch.size65536 \ compression.typelz4消費(fèi)者壓測(cè)則是kafka-consumer-perf-test.sh \ --bootstrap-server broker-1:9092 \ --topic perf-test \ --messages 5000000 \ --timeout 600000工具會(huì)輸出吞吐量msg/s 和 MB/s以及延遲分位數(shù)。注意第一次壓測(cè)前先確保 topic 里攢夠數(shù)據(jù)否則消費(fèi)者工具跑不了真實(shí)數(shù)據(jù)量。6.2 變量控制一次只改一個(gè)參數(shù)壓測(cè)最大的敵人不是環(huán)境不穩(wěn)定而是同時(shí)改多個(gè)參數(shù)導(dǎo)致結(jié)論無法歸因。我見過有人一次改了壓縮、linger.ms、分區(qū)數(shù)三個(gè)變量最后吞吐漲了卻完全不知道是哪個(gè)參數(shù)起了作用。正確做法是先用默認(rèn)配置跑一輪基線然后每輪只改一個(gè)參數(shù)記錄結(jié)果。整個(gè)流程可以用一張簡(jiǎn)單的表來跟蹤參數(shù)、值、吞吐、P99、CPU、磁盤 IO 全都記下來。壓測(cè)環(huán)境盡量貼近線上機(jī)器規(guī)格相同、磁盤類型相同、網(wǎng)絡(luò)拓?fù)湎嗤駝t壓測(cè)結(jié)果搬到線上可能完全對(duì)不上。6.3 一組真實(shí)的調(diào)優(yōu)前后對(duì)比參考我拿一個(gè)小消息場(chǎng)景每條 1KB JSON舉例壓測(cè)結(jié)果大致如下配置吞吐 (msg/s)P99 端到端延遲 (ms)默認(rèn)acks1, linger.ms0, 無壓縮4120035優(yōu)化Aacks1, linger.ms10, batch.size64KB, lz46680046優(yōu)化Backsall, min.insync.replicas2, 同優(yōu)化A6430048優(yōu)化C再加 zstd7020052同樣是這批消息吞吐從 4.1 萬漲到 7 萬P99 延遲也只從 35ms 漲到 52ms對(duì)于日志采集類業(yè)務(wù)完全可以接受。但如果業(yè)務(wù)要求 P99 必須小于 40ms那就得退回優(yōu)化A甚至把linger.ms降到 5ms 以下。7. 一次延遲毛刺的完整排查鏈路從監(jiān)控告警到根因復(fù)現(xiàn)7.1 現(xiàn)象與第一輪假設(shè)某個(gè)業(yè)務(wù)系統(tǒng)每到晚高峰就報(bào)個(gè)別接口 P99 抖動(dòng)毛刺集中在每小時(shí)的 0 分、15 分、30 分、45 分附近每次持續(xù)幾十秒然后自動(dòng)恢復(fù)。雖然對(duì)絕大多數(shù)請(qǐng)求沒有影響但問題是 P99 詭異地從 30ms 跳到接近 2 秒業(yè)務(wù)方不能接受。剛開始我把懷疑對(duì)象鎖定在 Broker 的 GC 停頓。Kafka 雖然堆內(nèi)存不大但 Full GC 一旦發(fā)生所有請(qǐng)求處理線程都可能暫停P99 毛刺非常符合這個(gè)癥狀。7.2 排除 GC轉(zhuǎn)向磁盤 IO 證據(jù)檢查了 Broker 的 GC 日志和分析結(jié)果結(jié)論是Young GC 確實(shí)每分鐘左右發(fā)生一次但停頓只有 20~40ms和 2 秒的毛刺完全不成比例Full GC 幾乎看不到幾分鐘才一次且耗時(shí)也在 100ms 以內(nèi)。GC 這條假設(shè)被排除了。轉(zhuǎn)看iostat發(fā)現(xiàn)了可疑點(diǎn)磁盤 util 在毛刺出現(xiàn)的時(shí)刻會(huì)從 20% 左右跳到 80% 以上同時(shí)await明顯上升。但 Kafka 的日志讀寫是順序追加理論上不會(huì)出現(xiàn)這種周期性的大起伏。問題更可能出在別的進(jìn)程在搶占磁盤 IO。7.3 抓到真正的元兇一個(gè)老監(jiān)控腳本用lsof查看哪些進(jìn)程在訪問 Kafka 數(shù)據(jù)目錄結(jié)果發(fā)現(xiàn)每隔 15 分鐘就有一個(gè)監(jiān)控采集腳本對(duì) Kafka 日志目錄做遍歷統(tǒng)計(jì)。這個(gè)腳本是歷史遺留的產(chǎn)物作用是統(tǒng)計(jì)每個(gè)目錄的文件數(shù)量和總大小但它遍歷時(shí)會(huì)觸發(fā)大量元數(shù)據(jù)讀和預(yù)讀操作把熱數(shù)據(jù)從 page cache 里擠出去導(dǎo)致 Kafka 后續(xù)讀請(qǐng)求直接打到磁盤。這正是那種只能在生產(chǎn)環(huán)境里碰到、文檔里絕對(duì)翻不到的問題。參數(shù)層面沒有一處是錯(cuò)的但系統(tǒng)層面被一個(gè)不相干的進(jìn)程拖垮了。7.4 修復(fù)方案與驗(yàn)證處理方式分兩步第一步刪掉那個(gè)定時(shí)掃描腳本的邏輯改用已有的指標(biāo)采集接口第二步把 Kafka 的數(shù)據(jù)目錄掛載到獨(dú)立的磁盤上避免其他 IO 任務(wù)和 Kafka 日志讀寫互相干擾。上線后持續(xù)觀察了一周P99 毛刺徹底消失晚高峰也能穩(wěn)定保持在 50ms 以下。這個(gè)案例給我的啟發(fā)是調(diào)優(yōu)不能只盯 Kafka 參數(shù)本身。全鏈路的意思是連監(jiān)控采集、日志切割、系統(tǒng)定時(shí)任務(wù)這些外部干擾也要一起納入視野。8. 全鏈路參數(shù)速查與實(shí)際經(jīng)驗(yàn)清單我把多年實(shí)踐里沉淀下來的常用參考配置整理成一個(gè)速查表適合大多數(shù)通用生產(chǎn)場(chǎng)景。實(shí)際部署時(shí)請(qǐng)根據(jù)業(yè)務(wù)目標(biāo)、機(jī)器規(guī)格、消息大小再做微調(diào)。層級(jí)參數(shù)推薦值調(diào)優(yōu)意圖Produceracks1 或 all1 偏吞吐all 偏可靠性配合 min.insync.replicas2Producerlinger.ms5~20ms攢批量提升吞吐的核心參數(shù)Producerbatch.size16~256KB按單條消息大小和期望批量條數(shù)估算Producercompression.typelz4 或 zstd網(wǎng)絡(luò)/磁盤瓶頸時(shí)的首選優(yōu)化Producerbuffer.memory64~128MB扛突發(fā)流量但降低延遲預(yù)算時(shí)需要減小Brokernum.io.threads核數(shù)一半以上高吞吐機(jī)器適當(dāng)調(diào)大配合壓測(cè)觀察Brokermin.insync.replicas2與 acksall 搭配避免 leader 掛丟數(shù)據(jù)Brokerunclean.leader.election.enablefalse堅(jiān)決不要開Brokerlog.segment.bytes1GB一般保持默認(rèn)Consumerfetch.min.bytes1KB~64KB大值提升吞吐小值降低延遲Consumerfetch.max.wait.ms50~500ms低延遲設(shè)小吞吐優(yōu)先設(shè)大Consumermax.poll.records100~500按單條處理耗時(shí)反推Consumerenable.auto.commitfalse手動(dòng)提交避免自動(dòng)提交時(shí)機(jī)不可控OSvm.swappiness1避免 page cache 被換出OSulimit -n至少 65535分區(qū)多的集群還要再加大OS磁盤掛載noatimeext4 上關(guān)掉 atime 寫入寫到這里再分享一點(diǎn)我自己的體會(huì)。調(diào)優(yōu)這件事最大的陷阱是總想找一個(gè)銀彈參數(shù)其實(shí)大多數(shù)場(chǎng)景下的收益排序都是先看有無硬件和 OS 層干擾再調(diào)攏批和壓縮再考慮副本和分區(qū)設(shè)計(jì)最后才去摳那些邊角參數(shù)。參數(shù)表只是一個(gè)起點(diǎn)真正可靠的標(biāo)準(zhǔn)永遠(yuǎn)是壓測(cè)數(shù)據(jù)。你在任何一個(gè)生產(chǎn)集群上做過的基線記錄都比網(wǎng)上流傳的最優(yōu)配置可信得多。最后再分享一個(gè)小技巧調(diào)優(yōu)過程中每改動(dòng)一個(gè)參數(shù)都在配置注釋里寫下改動(dòng)的日期、原因和實(shí)測(cè)結(jié)果。這樣三個(gè)月后回看你能清楚地知道這套配置是怎么演化來的也方便下次微調(diào)時(shí)快速定位方向。Kafka 的參數(shù)不會(huì)跑跑的是你的集群把這些細(xì)節(jié)管好比臨時(shí)抱佛腳改十個(gè)參數(shù)有用得多。