我接觸Kafka的時(shí)間不算短從最早為了給日志系統(tǒng)找個(gè)高吞吐通道到后來在多個(gè)項(xiàng)目里用它做訂單事件、用戶行為追蹤、實(shí)時(shí)數(shù)倉的中間層踩過的坑和填過的坑都不少。經(jīng)常有人問我Kafka到底怎么學(xué)或者更直接一點(diǎn)——Kafka集群怎么搭、為什么我發(fā)了一條1MB的消息就被拒了、消息延遲高得讓人抓狂該怎么辦、Kafka到底有沒有可視化界面可以看。這些問題我在真實(shí)項(xiàng)目里都遇到過而且網(wǎng)上很多教程把原理講得太玄把配置講得太碎看完還是不知道該怎么落地。所以這篇就按我自己的復(fù)盤思路來寫從定位到原理從安裝到排查從日常運(yùn)維到面試考點(diǎn)把Kafka這條線完整捋一遍。1. 先把Kafka的定位搞清楚它不只是一個(gè)消息隊(duì)列很多人學(xué)Kafka上來就背“分布式消息隊(duì)列”然后對(duì)照著RabbitMQ、RocketMQ去理解這個(gè)起點(diǎn)其實(shí)有點(diǎn)偏。Kafka的設(shè)計(jì)基因里第一身份是分布式提交日志Distributed Commit Log其次才是消息系統(tǒng)。這個(gè)差異決定了它為什么快、為什么能回溯消費(fèi)、為什么在流處理領(lǐng)域地位這么穩(wěn)。1.1 三合一的產(chǎn)品本質(zhì)Kafka最初是LinkedIn為了處理海量日志和指標(biāo)數(shù)據(jù)開發(fā)的2011年開源。它解決的問題不是簡簡單單把消息從A送到B而是讓“源源不斷產(chǎn)生的數(shù)據(jù)”有一股穩(wěn)定、可擴(kuò)展、可回放的“管道”。所以它的本質(zhì)是三個(gè)東西疊加在一起消息系統(tǒng)具備生產(chǎn)者和消費(fèi)者模型支持發(fā)布訂閱這是它的基礎(chǔ)能力。存儲(chǔ)系統(tǒng)消息一旦寫入分區(qū)日志文件就會(huì)按照配置保留一段時(shí)間默認(rèn)7天或達(dá)到指定大小才刪除。也就是說Kafka本身就是一個(gè)高吞吐、順序讀寫的分布式存儲(chǔ)系統(tǒng)。流處理平臺(tái)基于存儲(chǔ)能力它能做數(shù)據(jù)的重新計(jì)算、聚合、連接、去重等操作。Kafka Streams和ksqlDB就是干這個(gè)的。這三層身份對(duì)應(yīng)了三種典型用法業(yè)務(wù)系統(tǒng)之間解耦和異步通信、日志和指標(biāo)數(shù)據(jù)的集中收集、實(shí)時(shí)數(shù)倉和流式計(jì)算的底層支撐。你帶著這個(gè)視角去看Kafka就不會(huì)再拿著它跟RabbitMQ死磕“誰能把消息更可靠地一對(duì)一送達(dá)”這種問題了。1.2 日志即存儲(chǔ)理解Kafka快的原因Kafka的高吞吐不是靠什么黑魔法靠的是“把存儲(chǔ)當(dāng)成本能”。當(dāng)你往一個(gè)分區(qū)里寫消息時(shí)它做的是消息追加到分區(qū)文件末尾順序?qū)懘疟P。順序?qū)懘疟P的速度遠(yuǎn)比隨機(jī)寫要快配合操作系統(tǒng)頁緩存吞吐量可以跑得很高。讀取時(shí)利用零拷貝Zero Copy技術(shù)數(shù)據(jù)從磁盤到頁緩存再到網(wǎng)卡不需要經(jīng)過用戶態(tài)拷貝省掉了很多開銷。消息一旦寫入就帶上了唯一的offset偏移量消費(fèi)者可以基于這個(gè)offset任意回溯就像可以快進(jìn)倒退的播放器。把Kafka當(dāng)作一個(gè)“有目錄、有索引、能回放的日志系統(tǒng)”來理解比當(dāng)作消息隊(duì)列來理解要準(zhǔn)確得多。這也是為什么Kafka能支持“重跑數(shù)據(jù)”——不是把消息再發(fā)一遍而是讓消費(fèi)者把offset調(diào)回去重新讀。1.3 分區(qū)、副本和Leader切換的基本盤Kafka的高可用建立在分區(qū)Partition和副本Replica機(jī)制上。一個(gè)Topic的消息被分成多個(gè)分區(qū)每個(gè)分區(qū)可以有多個(gè)副本。副本之間是一主多從寫請(qǐng)求全部打到LeaderFollowers異步拉取同步。如果Leader掛了Controller會(huì)從ISRIn-Sync Replica里選舉出新的Leader。這里有幾個(gè)常見誤區(qū)需要糾正副本數(shù)越多越好不是。副本越多同步成本越高磁盤占用也會(huì)成倍增加。生產(chǎn)環(huán)境常用副本數(shù)2或者3追求高可用就3副本對(duì)一致性沒那么強(qiáng)就2副本甚至1副本。分區(qū)數(shù)越多越能提升吞吐不是線性關(guān)系。分區(qū)數(shù)增加會(huì)帶來文件句柄、選舉時(shí)間和客戶端內(nèi)存的開銷過多分區(qū)反而會(huì)降低整體性能。ISR是硬指標(biāo)ISR里都是跟Leader保持同步的副本如果Follower落后太多就會(huì)被踢出ISR。這個(gè)機(jī)制直接關(guān)系到“消息會(huì)不會(huì)丟”理解它比背一堆參數(shù)有用得多。帶著“日志系統(tǒng)分區(qū)副本”這個(gè)底子去看后面的安裝和調(diào)優(yōu)很多參數(shù)就不用死記硬背了。2. Kafka安裝部署的實(shí)操記錄從Windows單機(jī)到集群搭建要點(diǎn)“Windows安裝kafka”和“kafka集群安裝”都是評(píng)論區(qū)高頻詞。我自己最早學(xué)Kafka時(shí)也是先在Windows上跑了個(gè)單機(jī)版做實(shí)驗(yàn)后來才在Linux上搭正式集群。兩套環(huán)境的坑我都踩過這里一起講。2.1 Windows環(huán)境安裝下載、解壓、啟動(dòng)三板斧新版Kafka已經(jīng)把ZooKeeper剝離出來了從3.0起引入KRaft模式可以完全脫離ZooKeeper運(yùn)行。如果你只是為了本地學(xué)習(xí)驗(yàn)證我建議直接用KRaft模式的單節(jié)點(diǎn)。本地安裝大致流程去Apache官網(wǎng)下載二進(jìn)制包比如kafka_2.13-3.6.2.tgz解壓到一個(gè)不帶空格的路徑比如 D:\kafka。進(jìn)入config目錄KRaft模式下核心配置文件是server.properties需要先生成集群ID并格式化存儲(chǔ)目錄。用自帶腳本生成一個(gè)UUID寫入配置文件再執(zhí)行 kafka-storage.sh format 命令完成格式化。啟動(dòng) kafka-server-start.bat然后再按需啟動(dòng)生產(chǎn)者、消費(fèi)者腳本驗(yàn)證。我在Windows上踩過的坑是這幾個(gè)JAVA_HOME沒配好啟動(dòng)腳本一閃而過。必須先確認(rèn) JDK 8 已裝好且 環(huán)境變量JAVA_HOME 指向正確。路徑帶空格導(dǎo)致腳本報(bào)錯(cuò)。裝Kafka的目錄不要放在帶空格或者中文的路徑下。啟動(dòng)腳本一閃就退多半是配置文件里 listeners 和 advertised.listeners 沒改對(duì)。本地單機(jī)一般用 localhost:9092 就行。2.2 真正的集群部署哪些配置必須提前想清楚集群部署通常有兩種KRaft模式新和ZooKeeper模式老。如果你還在用2.x版本那是ZooKeeper模式新項(xiàng)目建議直接上KRaft部署更輕量也不需要單獨(dú)維護(hù)ZooKeeper集群。集群搭建的幾個(gè)關(guān)鍵點(diǎn)broker.id每個(gè)節(jié)點(diǎn)必須是全局唯一的整數(shù)不能重復(fù)。listeners 和 advertised.listeners前者配置broker監(jiān)聽地址后者是告訴客戶端“怎么訪問我”。很多部署問題最后都查到這里——advertised.listeners配錯(cuò)了消費(fèi)者永遠(yuǎn)連不上。log.dirs數(shù)據(jù)目錄如果有多個(gè)磁盤可以配置成逗號(hào)分隔的列表Kafka會(huì)自動(dòng)做分區(qū)目錄的分配。建議不要跟系統(tǒng)盤放一起。num.partitionsTopic默認(rèn)分區(qū)數(shù)生產(chǎn)環(huán)境一般不指望這個(gè)默認(rèn)值建Topic時(shí)顯式指定。default.replication.factor默認(rèn)副本因子如果希望自動(dòng)創(chuàng)建的Topic安全一點(diǎn)建議設(shè)成2或3。min.insync.replicas配合acksall使用保證至少有幾個(gè)副本確認(rèn)寫入后才返回成功這是“消息不丟”的重要保障。我給一個(gè)適用于中小規(guī)模集群的參考配置不是說照抄就行而是給你一個(gè)找感覺的起點(diǎn)配置項(xiàng)參考值說明broker.id1/2/3每節(jié)點(diǎn)唯一log.dirs/data/kafka-logs數(shù)據(jù)目錄建議單獨(dú)磁盤num.partitions3業(yè)務(wù)Topic建表時(shí)顯式指定default.replication.factor2允許掛一個(gè)節(jié)點(diǎn)min.insync.replicas1與acksall搭配建議2log.retention.hours168默認(rèn)7天auto.create.topics.enablefalse生產(chǎn)建議關(guān)閉自動(dòng)建Topicoffset.topic.replication.factor3__consumer_offsets必須高可用2.3 啟動(dòng)后必須做的三件驗(yàn)證事集群起來不是看進(jìn)程活著就完事一定要做功能驗(yàn)證創(chuàng)建測試Topic指定分區(qū)數(shù)和副本數(shù)比如 3分區(qū)2副本觀察分區(qū)Leader是否均勻分布。啟動(dòng)生產(chǎn)者腳本生產(chǎn)一批消息再啟動(dòng)消費(fèi)者腳本消費(fèi)驗(yàn)證端到端通了。掛掉一臺(tái)broker再次生產(chǎn)消費(fèi)看業(yè)務(wù)是否持續(xù)可用確認(rèn)Leader切換正常。我自己在集群部署時(shí)印象最深的一個(gè)“坑”是配置沒問題進(jìn)程也活著但客戶端就是連不上。查到最后是云服務(wù)器的安全組沒放開9092端口advertised.listeners也沒改成公網(wǎng)地址。這類問題你不用懷疑Kafka配置先看防火墻和安全組會(huì)不會(huì)更快一點(diǎn)。3. 消息延遲高與1MB大消息限制兩個(gè)幾乎是必踩的性能坑熱搜詞里“kafka接收1m”和“kafka消息延遲高”每個(gè)都代表一大類真實(shí)事故。這兩個(gè)問題我也都處理過分開講因?yàn)榕挪樗悸吠耆煌?.1 大消息被拒max.request.size只是其中一環(huán)先說一個(gè)項(xiàng)目里的真實(shí)例子。運(yùn)營同學(xué)要往Kafka里塞一條接近1.5MB的JSON數(shù)據(jù)生產(chǎn)者一直報(bào)錯(cuò)消息太大。很多人第一反應(yīng)是改max.request.size以為把這個(gè)調(diào)大就完事結(jié)果改了還是失敗。原因是大消息能不能正常收發(fā)是一連串參數(shù)共同決定的結(jié)果。涉及的參數(shù)有這么幾組生產(chǎn)者端 max.request.size單個(gè)請(qǐng)求的最大大小默認(rèn)1MB1048576字節(jié)。要收1MB以上的消息這里必須調(diào)大。broker端 message.max.bytesbroker允許接收的單條消息最大大小默認(rèn)也是1MB左右不改就會(huì)在broker層拒絕。broker端 replica.fetch.max.bytesFollower拉取同步的最大字節(jié)數(shù)如果這條不調(diào)大Follower同步大消息會(huì)失敗導(dǎo)致數(shù)據(jù)不同步甚至ISR收縮。消費(fèi)者端 fetch.max.bytes消費(fèi)者拉取的最大字節(jié)數(shù)默認(rèn)50MB一般不用動(dòng)但如果消息太大拉不完也可能要調(diào)。所以如果你要支持單條1MB消息至少要保證 message.max.bytes ≥ max.request.size同時(shí)把 replica.fetch.max.bytes 也調(diào)大。我當(dāng)時(shí)的處理方案是# broker端 message.max.bytes5242880 replica.fetch.max.bytes5242880 # 生產(chǎn)者端 max.request.size5242880調(diào)完之后還得提醒大消息會(huì)嚴(yán)重拖慢吞吐量因?yàn)槊織l消息都要占用更多的網(wǎng)絡(luò)帶寬、磁盤IO和內(nèi)存。能用拆分的方案就別硬扛實(shí)在無法避免再考慮調(diào)參。3.2 消息延遲高先別急著怪Kafka給足數(shù)據(jù)再說“消息延遲高”這個(gè)問題我在排查時(shí)的第一步不是看Kafka而是先確認(rèn)“延遲”具體發(fā)生在哪個(gè)階段。生產(chǎn)到消費(fèi)的整體鏈路是生產(chǎn)者發(fā)送 → broker寫入 → 消費(fèi)者拉取延遲可能出現(xiàn)在任意一段。我習(xí)慣按這個(gè)順序排查先看生產(chǎn)端發(fā)送是同步還是異步batch.size 和 linger.ms 設(shè)了多少如果linger.ms100等于每條消息進(jìn)來都故意等100ms才發(fā)出去從生產(chǎn)視角看延遲就是100ms起步。對(duì)延遲敏感的場景把linger.ms調(diào)小或者關(guān)掉批處理。再看broker端磁盤IO和網(wǎng)絡(luò)IO有沒有打滿出現(xiàn)很多慢日志打開監(jiān)控看下請(qǐng)求處理時(shí)延。最后看消費(fèi)端是不是消費(fèi)者處理不過來導(dǎo)致堆積還是fetch.min.bytes設(shè)太大導(dǎo)致拉取條件難以滿足我遇到過一個(gè)很典型的隱藏問題業(yè)務(wù)方把生產(chǎn)者配成了同步發(fā)送然后每個(gè)請(qǐng)求都用flush看著消息一條條發(fā)是穩(wěn)了吞吐起不來延遲自然高。后來改成合適的批量參數(shù)延遲和吞吐同時(shí)改善。批量參數(shù)可以參考這么配# 生產(chǎn)者端 batch.size16384 linger.ms5 buffer.memory33554432 acksall compression.typelz4壓縮這一項(xiàng)很多人會(huì)忽略。實(shí)測開lz4或zstd壓縮之后體量大的JSON數(shù)據(jù)能省下不少網(wǎng)絡(luò)帶寬對(duì)延遲和吞吐都有幫助代價(jià)是增加一點(diǎn)點(diǎn)CPU消耗。CPU不緊張的場景強(qiáng)烈建議開。3.3 消費(fèi)堆積和延遲的關(guān)系一個(gè)容易被忽略的計(jì)算思路消費(fèi)者處理不過來會(huì)造成堆積堆積意味著從生產(chǎn)到消費(fèi)的端到端延遲越來越大。這就是為什么排查延遲時(shí)一定要看消費(fèi)者組的 lag滯后量。lag的計(jì)算其實(shí)很直白當(dāng)前Largest offset生產(chǎn)到的最新位置與當(dāng)前消費(fèi)位置的差就是該分區(qū)的滯后消息數(shù)。如果單條消息不小滯后1萬條就已經(jīng)可能拖幾十秒。常見的處理方式有幾個(gè)方向增加消費(fèi)者實(shí)例參與同一個(gè)group消費(fèi)分區(qū)數(shù)不夠加分區(qū)——注意消費(fèi)者數(shù)大于分區(qū)數(shù)時(shí)多余的消費(fèi)者是閑置的。優(yōu)化消費(fèi)者內(nèi)部的邏輯減少每條消息的處理耗時(shí)。適當(dāng)調(diào)大消費(fèi)端的 max.poll.records讓每次拉取的數(shù)量更大減少網(wǎng)絡(luò)往返開銷。我之前碰到一個(gè)消費(fèi)者處理特別慢的問題每條消息都要調(diào)用兩個(gè)外部接口單線程處理根本追不上生產(chǎn)速度。最后把外部調(diào)用改成異步批量處理lag在幾分鐘內(nèi)明顯回落。延遲問題很多時(shí)候不是Kafka本身慢而是你給它安排了慢流程。4. Kafka可視化工具怎么選UI界面到底該看什么“kafka有沒有ui界面”這個(gè)問題下的需求通常分兩種一種是想要圖形化地查看消息、Topic、分區(qū)和消費(fèi)組方便學(xué)習(xí)和演示另一種是想要監(jiān)控Kafka集群健康狀態(tài)用于日常運(yùn)維。兩者對(duì)應(yīng)的工具不一樣。4.1 幾款常見可視化工具的實(shí)際體驗(yàn)Kafka UI是當(dāng)下比較推薦的選擇界面現(xiàn)代功能全面。它支持通過Docker快速啟動(dòng)一個(gè)Web服務(wù)能查看Topic列表、分區(qū)詳情、消息內(nèi)容、消費(fèi)者組和offset情況還能模擬生產(chǎn)消息。部署簡單Java環(huán)境或者Docker跑一下就行適合大部分開發(fā)和運(yùn)維場景。Offset Explorer原來叫Kafka Tool桌面客戶端Windows下用得比較多。它連接集群后能很直觀地看到有哪些Topic、分區(qū)Leader在哪、每條消息的offset區(qū)間適合快速查看某個(gè)Topic的消息。Kafka Eagle算老牌開源監(jiān)控系統(tǒng)功能偏監(jiān)控有告警能力能看到lag和集群健康狀態(tài)。如果你的集群節(jié)點(diǎn)多、業(yè)務(wù)量大這類監(jiān)控工具會(huì)比單純看消息的工具更有價(jià)值。結(jié)合熱搜詞里還出現(xiàn)了qt kafka mingw這個(gè)場景應(yīng)該是有人想用Qt寫桌面工具去操作Kafka我猜是在Windows上用MinGW編譯librdkafka或者cppkafka這類庫。以我個(gè)人經(jīng)驗(yàn)Qt Kafka的坑主要在編譯依賴上librdkafka對(duì)SSL和SASL的依賴鏈有點(diǎn)復(fù)雜建議先用官方預(yù)編譯包驗(yàn)證再考慮自己編譯。這塊沒有太多詳細(xì)資料只能給你這個(gè)方向性建議。4.2 可視化界面解決不了的核心監(jiān)控項(xiàng)UI工具解決的是“能看到”但“看到什么才有用”需要自己心里有數(shù)。日常運(yùn)維我重點(diǎn)盯這幾項(xiàng)Under-Replicated Partitions分區(qū)副本同步不正常說明有副本落后或節(jié)點(diǎn)異常。這個(gè)值長期不為0就意味著你的數(shù)據(jù)存在丟失風(fēng)險(xiǎn)。Consumer Lag消費(fèi)者組落后的消息數(shù)。這個(gè)數(shù)應(yīng)該穩(wěn)定而不持續(xù)增長持續(xù)增長等于消費(fèi)能力不夠。Active Controller Count正常情況下只有一個(gè)活躍Controller多個(gè)說明元數(shù)據(jù)出問題了。Broker端口健康度broker有沒有頻繁Full GC網(wǎng)絡(luò)連接數(shù)有沒有異常增大。這些指標(biāo)在工具頁面里都能看到但不一定一眼就能定位問題。比如某個(gè)Topic的ISR收縮了你要先看是哪個(gè)broker的問題如果一臺(tái)機(jī)器上同時(shí)出現(xiàn)大量分區(qū)ISR收縮優(yōu)先懷疑那臺(tái)機(jī)器的磁盤或網(wǎng)絡(luò)出了問題而不是業(yè)務(wù)側(cè)的問題。4.3 記錄一次靠UI排查的故障有一回我們的Topic突然生產(chǎn)報(bào)錯(cuò) NOT_LEADER_OR_FOLLOWER 或者 OFFSET_OUT_OF_RANGE。一堆業(yè)務(wù)方同時(shí)來問。我打開UI看集群節(jié)點(diǎn)發(fā)現(xiàn)有一個(gè)broker反復(fù)重啟Controller在不停切換部分分區(qū)的ISR列表在收縮。排查方向立即從業(yè)務(wù)代碼轉(zhuǎn)到了那臺(tái)broker的磁盤——結(jié)果還真是數(shù)據(jù)盤IO異常導(dǎo)致broker自動(dòng)選下臺(tái)了。這就是可視化的意義它不是用來炫的而是幫你在混亂局面下快速縮小排查范圍。工具本身不是重點(diǎn)結(jié)合工具看懂集群狀態(tài)才是重點(diǎn)。5. 消費(fèi)者端實(shí)操從offset管理到重復(fù)消費(fèi)和漏消費(fèi)生產(chǎn)者和broker的問題相對(duì)集中消費(fèi)者端的坑更多更碎而且一旦出問題通常都是數(shù)據(jù)一致性問題。這個(gè)章節(jié)專門講消費(fèi)者端的實(shí)操包括offset怎么管理、分區(qū)怎么分配、重復(fù)消費(fèi)和漏消費(fèi)到底怎么防。5.1 消費(fèi)者組與分區(qū)分配機(jī)制消費(fèi)者組是Kafka一個(gè)很核心的概念。同一組內(nèi)的多個(gè)消費(fèi)者實(shí)例共同消費(fèi)一個(gè)Topic的消息但每個(gè)分區(qū)只會(huì)被組內(nèi)的一個(gè)消費(fèi)者負(fù)責(zé)。這個(gè)機(jī)制決定了兩個(gè)結(jié)果消費(fèi)者數(shù)量大于分區(qū)數(shù)時(shí)多出來的消費(fèi)者會(huì)閑著。消費(fèi)者數(shù)量小于分區(qū)數(shù)時(shí)可能有消費(fèi)者要負(fù)責(zé)多個(gè)分區(qū)。消費(fèi)者數(shù)量變化、訂閱Topic變化、分區(qū)數(shù)變化都會(huì)觸發(fā)再平衡Rebalance。分區(qū)分配策略有三種主要的RangeAssignor按Topic逐個(gè)分配分區(qū)大家瓜分有消費(fèi)者可能會(huì)多承擔(dān)一個(gè)分區(qū)的職責(zé)。RoundRobinAssignor把所有分區(qū)攤平輪流分配多出的分區(qū)盡量均勻分配。StickyAssignor在保留現(xiàn)有分配的基礎(chǔ)上做最小變動(dòng)盡量避免不必要的分區(qū)重排。Sticky多數(shù)場景是比較實(shí)用的默認(rèn)選擇因?yàn)樗鼫p少分區(qū)在消費(fèi)者之間遷移的次數(shù)。再平衡是消費(fèi)者端最影響穩(wěn)定性的因素之一每次再平衡時(shí)消費(fèi)者會(huì)暫停消費(fèi)整個(gè)組處于rebalance狀態(tài)。所以盡量降低再平衡的頻率能明顯減少延遲抖動(dòng)。5.2 offset的三種提交方式和適用場景offset表示消費(fèi)者消費(fèi)到的位置而提交offset則是向Kafka匯報(bào)“我已經(jīng)消費(fèi)到哪里了”。提交的方式直接決定你是可能重復(fù)消費(fèi)還是漏消費(fèi)自動(dòng)提交enable.auto.committrue默認(rèn)每隔 auto.commit.interval.ms 自動(dòng)提交最近的offset。實(shí)現(xiàn)簡單但可能在消費(fèi)者進(jìn)程掛掉后出現(xiàn)重復(fù)消費(fèi)。手動(dòng)提交enable.auto.commitfalse由業(yè)務(wù)代碼在合適時(shí)機(jī)調(diào)用commitSync或commitAsync方法。在消息處理成功后提交能把重復(fù)消費(fèi)的窗口壓縮得很小。手動(dòng)異步提交commitAsync會(huì)在提交失敗時(shí)不會(huì)阻塞主流程適合追求吞吐的場景但要配合回調(diào)處理失敗情況。我個(gè)人的習(xí)慣是消息處理有副作用的系統(tǒng)一律手動(dòng)提交并把提交時(shí)機(jī)放在業(yè)務(wù)處理成功之后。流程大概是拉取一批消息。逐條處理處理失敗的單獨(dú)記錄并嘗試補(bǔ)償。該批處理完成后提交offset。如果進(jìn)程掛掉未提交的offset會(huì)導(dǎo)致重復(fù)消費(fèi)所以消費(fèi)者側(cè)邏輯要設(shè)計(jì)成冪等或者通過消息主鍵去重。強(qiáng)調(diào)一下Kafka默認(rèn)的至少一次at-least-once語義特點(diǎn)就決定了重復(fù)消費(fèi)一定會(huì)出現(xiàn)只能通過應(yīng)用層的冪等去消化。千萬不要指望Kafka幫你完全消除重復(fù)。5.3 重平衡導(dǎo)致全體暫停一個(gè)必須警惕的性能陷阱重平衡發(fā)生時(shí)整個(gè)消費(fèi)者組會(huì)短暫地“停頓”——所有消費(fèi)者停止消費(fèi)等待分區(qū)分配完成。如果消費(fèi)者在處理耗時(shí)長的任務(wù)超過了 max.poll.interval.ms默認(rèn)5分鐘broker會(huì)認(rèn)為這個(gè)消費(fèi)者掛了強(qiáng)行踢出組再觸發(fā)一次新的重平衡。這個(gè)場景我踩過一次。當(dāng)時(shí)消費(fèi)者里有一段數(shù)據(jù)庫批量寫入邏輯偶爾會(huì)遇到鎖等待個(gè)別批次處理超過5分鐘結(jié)果消費(fèi)者被判定失聯(lián)消費(fèi)者組不斷重平衡整個(gè)鏈路基本癱瘓。后面的處理方案是把 max.poll.interval.ms 調(diào)大比如10分鐘給處理邏輯留出緩沖。單次拉取的數(shù)據(jù)量調(diào)小一點(diǎn)比如 max.poll.records200避免一次處理太多。對(duì)耗時(shí)操作設(shè)置超時(shí)超時(shí)后斷言失敗不要讓進(jìn)程一直卡住。理解消費(fèi)者組的暫停機(jī)制比只調(diào)參數(shù)更關(guān)鍵。你只有知道重平衡期間整個(gè)組是不干活的才能在突發(fā)延遲時(shí)快速想到是這個(gè)問題。6. 面試?yán)颣afka問得最多的幾個(gè)問題我自己的答案版本熱搜詞里有“kafka面試題及答案”這里挑四個(gè)出現(xiàn)頻率最高的問題講一講。這些問題光背八股文沒用結(jié)合前面的原理和實(shí)操理解著答才是真有說服力的版本。6.1 Kafka為什么這么快這個(gè)問題我喜歡用三個(gè)關(guān)鍵詞回答順序?qū)憽㈨摼彺?、零拷貝。生產(chǎn)者追加消息到分區(qū)文件是順序?qū)懭攵皇请S機(jī)寫入這是Kafka在磁盤上快的原因。讀寫利用操作系統(tǒng)的頁緩存消息在內(nèi)存里就能被消費(fèi)者讀取命中率高時(shí)根本不用落盤。零拷貝讓數(shù)據(jù)從磁盤到網(wǎng)卡全程不用經(jīng)過用戶態(tài)減少了拷貝次數(shù)和上下文切換。再配上分區(qū)的并行寫入、批量發(fā)送吞吐自然就上去了。6.2 如何保證消息不丟失這個(gè)問題必須分角色回答否則就是背答案。生產(chǎn)者端要把 acksall并且設(shè)置 min.insync.replicas 為合理值發(fā)送方式不要用fire-and-forget必要時(shí)等待發(fā)送結(jié)果。broker端關(guān)鍵是關(guān)閉自動(dòng)創(chuàng)建Topic配置足夠的副本因子和 ISR閾值還沒寫完的數(shù)據(jù)不會(huì)丟。消費(fèi)者端手動(dòng)提交offset并在業(yè)務(wù)處理成功后提交不然可能丟消費(fèi)位置。把這套鏈路講清楚比背誦“可靠性三兄弟”有說服力得多。6.3 如何保證消息的順序Kafka只在分區(qū)內(nèi)部保證順序跨分區(qū)無順序保證。所以回答這個(gè)問題的核心是把需要保證順序的消息都發(fā)到同一個(gè)分區(qū)。最簡單的做法是消息帶一個(gè)訂單ID生產(chǎn)者端按訂單ID哈希指定分區(qū)消費(fèi)者端在單分區(qū)內(nèi)順序處理。如果想跨分區(qū)還保持全局順序那就失去Kafka的并行優(yōu)勢(shì)了絕大多數(shù)場景不需要這么做。6.4 分區(qū)數(shù)應(yīng)該怎么定分區(qū)數(shù)沒有一個(gè)萬能公式但我可以給一個(gè)經(jīng)驗(yàn)判斷路徑先預(yù)估你的目標(biāo)吞吐量再算單個(gè)分區(qū)能扛多少吞吐用前者除后者得到分區(qū)數(shù)下限。同時(shí)考慮消費(fèi)者的并行度——分區(qū)數(shù)最好大于消費(fèi)者組內(nèi)消費(fèi)者的數(shù)量否則有消費(fèi)者閑置。最后再留一些冗余應(yīng)對(duì)未來業(yè)務(wù)增長。我的習(xí)慣是先按平均吞吐量的3倍左右確定分區(qū)數(shù)后續(xù)再根據(jù)監(jiān)控情況調(diào)整。這里也要提醒分區(qū)數(shù)可以增加但一般不減少因?yàn)闇p少分區(qū)的操作成本很高。剛開始定小一點(diǎn)留好調(diào)整空間才是成熟的做法。這幾個(gè)問題答下來面試官大概率會(huì)繼續(xù)追問一兩個(gè)細(xì)節(jié)比如Controller是怎么選出來的、消費(fèi)組重平衡的流程。只要你真理解分區(qū)副本和消費(fèi)者組的運(yùn)作機(jī)制就能順藤摸瓜把這些細(xì)節(jié)也都撈出來比純背誦靠得住。寫到這里Kafka從原理到實(shí)踐再到面試應(yīng)對(duì)的主線都已經(jīng)完整過了一遍。無論你是準(zhǔn)備第一次搭建集群還是正在被延遲問題困擾建議先從理解“Kafka是日志系統(tǒng)”這一點(diǎn)開始然后再去動(dòng)手配參數(shù)。我自己是踩過“把Kafka當(dāng)消息中間件用結(jié)果配置全是按消息中間件調(diào)的”的彎路等你真的把它當(dāng)作一套分布式日志系統(tǒng)來使用很多決策就會(huì)自然變得順暢。