去年面了個(gè)候選人提到Kafka為什么快對方張口就是“分區(qū)、順序?qū)?、零拷貝”我順著追問了一句“零拷貝具體省了哪幾步拷貝”他愣了幾秒然后告訴我“就是省了拷貝”。這種回答其實(shí)挺常見的名詞都聽過但再往下一層就空了?！睹嬖嚢斯晌摹废盗袑懙浆F(xiàn)在是第21卷這一期專門聊Kafka。市面上的Kafka面試題匯總一抓一大把但大多數(shù)只是把題目和答案列出來你背完還是會覺得心里沒底。因?yàn)槊嬖嚬僬嬲肼牭膹膩聿皇悄莻€(gè)名詞而是名詞背后的取舍邏輯。這篇文章不打算給你堆題目而是把Kafka面試?yán)镒罡哳l的幾組考點(diǎn)拆開揉碎底層定位、高吞吐原理、可靠性機(jī)制、消費(fèi)者端三大問題、消費(fèi)組與Rebalance、線上積壓排查最后再給一套可以直接上口的表述模板。無論你是準(zhǔn)備面試還是想系統(tǒng)補(bǔ)一下Kafka原理這篇都適用。1. 先把底層定位說清楚Kafka不是“消息隊(duì)列”這么簡單1.1 面試官為什么開口就問“你怎么理解Kafka”面試問“你怎么理解Kafka”其實(shí)是在試探你有沒有自己的知識框架。你要是張嘴就說“Kafka是分布式消息隊(duì)列”不能算錯(cuò)但等于沒說。這個(gè)答案太淺面試官接下來會連著追問它和RabbitMQ有什么區(qū)別它為什么吞吐量高它適合什么場景一個(gè)“消息隊(duì)列”的標(biāo)簽根本撐不住這些追問。我更推薦按三層來理解Kafka第一層是消息系統(tǒng)基于發(fā)布訂閱模型負(fù)責(zé)異步解耦、削峰填谷第二層是存儲系統(tǒng)消息持久化到磁盤保留一段時(shí)間可以回溯消費(fèi)第三層是流處理平臺借助Kafka Streams或者對接Flink做實(shí)時(shí)計(jì)算。面試時(shí)能講到這個(gè)層面面試官至少知道你不是只會背概念。這里面還有一個(gè)比較容易忽略的點(diǎn)Kafka和JMS規(guī)范其實(shí)沒什么關(guān)系它并不遵守JMS那套API標(biāo)準(zhǔn)而是自己定義了一套基于分區(qū)和offset的消費(fèi)模型。很多人拿RabbitMQ那套exchange、queue的邏輯去套Kafka結(jié)果越套越亂。記住一點(diǎn)Kafka的設(shè)計(jì)核心是“分布式日志”不是“消息隊(duì)列”這個(gè)定位直接影響你對后面所有機(jī)制的理解。1.2 從topic、partition到segment一條消息到底存在哪面試官的第二個(gè)追問往往是“消息存到哪里了”。如果你答“存在磁盤上”還不夠他會繼續(xù)問“磁盤上的結(jié)構(gòu)長什么樣”。一條消息從生產(chǎn)到存儲的路徑是這樣的生產(chǎn)者指定topic消息按照分區(qū)策略落入某個(gè)partitionpartition內(nèi)文件按大小切分為多個(gè)segment消息真正寫進(jìn)當(dāng)前活躍segment的.log文件末尾。為了更好地查找消息每個(gè)segment還對應(yīng).index和.timeindex兩個(gè)索引文件。整體結(jié)構(gòu)可以看作一個(gè)“分區(qū)目錄 - segment文件”的樹形布局。這里有個(gè)關(guān)鍵點(diǎn)Kafka不是按topic物理隔離存儲數(shù)據(jù)而是以partition為單位。也就是說一個(gè)topic的多個(gè)分區(qū)是散落在不同broker上的。這是Kafka水平擴(kuò)展的基礎(chǔ)——假設(shè)一個(gè)broker磁盤滿了你加機(jī)器、做分區(qū)遷移就能把壓力分?jǐn)偝鋈ァＣ嬖嚬倏赡軙穯枴盀槭裁匆蟹謪^(qū)”。我習(xí)慣從兩個(gè)角度答從存儲角度看一個(gè)分區(qū)的數(shù)據(jù)文件如果無限增長后續(xù)清理和查詢都是災(zāi)難segment切分機(jī)制恰好解決了這個(gè)問題從計(jì)算角度看分區(qū)是并行度的基礎(chǔ)多個(gè)分區(qū)可以被多個(gè)消費(fèi)者線程同時(shí)消費(fèi)消費(fèi)者的擴(kuò)展性本質(zhì)上是分區(qū)的擴(kuò)展性。1.3 一個(gè)能背下來也能講出來的“Kafka是什么”標(biāo)準(zhǔn)回答我整理了一套自己面試時(shí)常用的回答口徑你可以參考也可以按自己的語言習(xí)慣改先說定位Kafka是一個(gè)基于發(fā)布訂閱模式的分布式流處理平臺核心能力是消息系統(tǒng)、存儲系統(tǒng)和流處理。再說高吞吐的底層支撐分區(qū)并行、順序?qū)懕P、頁緩存、零拷貝、批量發(fā)送和壓縮。接著說可靠性持久化到磁盤、多副本機(jī)制、ISR列表、ack確認(rèn)、HW高水位。最后說落地場景日志收集、埋點(diǎn)數(shù)據(jù)管道、異步削峰、事件驅(qū)動(dòng)架構(gòu)。這套口徑的好處是“總-分”結(jié)構(gòu)清楚面試官無論從哪個(gè)點(diǎn)深入追問你都有一條線可以順下去。背它是不難的難的是每個(gè)節(jié)點(diǎn)都能展開。后面幾節(jié)就是把這條線上最核心的幾個(gè)節(jié)點(diǎn)一個(gè)個(gè)拆開講透。2. 百萬級并發(fā)的底氣順序?qū)?、零拷貝、批量、頁緩?.1 順序?qū)憺槭裁幢入S機(jī)寫快那么多面試題里最熱門的問法就是“Kafka為什么能支撐百萬并發(fā)”。你要真去答先想明白一個(gè)問題Kafka的高吞吐第一功臣是什么答案是順序?qū)懘疟P。很多人以為Kafka是依賴內(nèi)存才能快起來的實(shí)際上它敢把數(shù)據(jù)全量落盤靠的就是順序IO。普通機(jī)械硬盤順序?qū)懙乃俣却蟾旁?00MB/s以上但隨機(jī)寫由于磁頭頻繁尋道速度可能掉到幾MB/s甚至更低。SSD雖然隨機(jī)寫比HDD快不少但和順序?qū)懴啾纫踩杂胁罹唷afka把每條消息追加到分區(qū)文件的末尾不修改任何歷史數(shù)據(jù)天然就是順序IO這就能讓磁盤吞吐逼近硬件上限。僅靠單分區(qū)順序?qū)戇€不夠每個(gè)topic有多個(gè)分區(qū)一個(gè)broker上多個(gè)分區(qū)的日志文件可以并行追加相當(dāng)于把一條磁盤隊(duì)列變成多條隊(duì)列交替寫入。底層是多分區(qū)的并行疊加整體吞吐自然就上去了。面試時(shí)有個(gè)點(diǎn)值得主動(dòng)補(bǔ)充順序?qū)懖⒉淮怼安宦浔P”Kafka默認(rèn)先把數(shù)據(jù)寫進(jìn)頁緩存再異步刷盤。這和“為保證可靠性每條都fsync”是兩種設(shè)計(jì)思路前者為了吞吐后者為了絕對安全。Kafka的取舍是用副本機(jī)制兜底而不是靠每一條都刷盤。2.2 零拷貝在消費(fèi)鏈路里省了什么零拷貝這道題90%的人只記住了“省拷貝”但你要能說清“省了幾次、在哪省的”才算真正過關(guān)。先看傳統(tǒng)的文件傳輸路徑磁盤數(shù)據(jù)先讀入內(nèi)核空間的頁緩存再從內(nèi)核拷貝到用戶態(tài)程序緩沖區(qū)程序處理后再拷到內(nèi)核Socket緩沖區(qū)最后通過網(wǎng)卡發(fā)出。這一趟下來至少4次拷貝、4次用戶態(tài)與內(nèi)核態(tài)切換。Kafka消費(fèi)消息時(shí)走的是sendfile系統(tǒng)調(diào)用底層對應(yīng)Java NIO里的FileChannel.transferTo()。數(shù)據(jù)路徑變?yōu)榇疟P - 頁緩存 - Socket緩沖區(qū) - 網(wǎng)卡中間省掉了用戶態(tài)那一次拷貝。所以Kafka的零拷貝準(zhǔn)確說是“內(nèi)核態(tài)內(nèi)的DMA拷貝和CPU拷貝配合”比傳統(tǒng)的“內(nèi)核到用戶、用戶到內(nèi)核”至少少兩次拷貝。面試官如果追問“為什么零拷貝能提升吞吐”你可以從兩個(gè)角度看一是CPU利用率顯著上升因?yàn)槭〉袅擞脩魬B(tài)和內(nèi)核態(tài)的反復(fù)切換二是內(nèi)存帶寬壓力變小消費(fèi)者拉取高頻大消息時(shí)差距更明顯。一個(gè)容易被忽略的細(xì)節(jié)是零拷貝要求數(shù)據(jù)在頁緩存里命中才能走通這條路徑。如果數(shù)據(jù)不在頁緩存而必須從磁盤先加載性能就會打折這也是Kafka強(qiáng)調(diào)給OS留足夠內(nèi)存做頁緩存的原因之一。2.3 批量與壓縮性能的倍增器順序?qū)懡鉀Q的是存儲吞吐網(wǎng)絡(luò)開銷則要靠批量和壓縮來解決。生產(chǎn)者默認(rèn)并不是一條消息就發(fā)一次請求而是攢一批再發(fā)。batch.size控制每批消息的最大字節(jié)數(shù)默認(rèn)16KBlinger.ms控制等待時(shí)間默認(rèn)0。如果消息量不夠而一直等不到湊滿一塊linger.ms就是兜底保證消息不會無限積壓在發(fā)送端。為什么批量能提升吞吐本質(zhì)上是把多次網(wǎng)絡(luò)往返合并成一次服務(wù)端也只需要解析一次請求體。對Kafka這種海量小消息的場景網(wǎng)絡(luò)往返次數(shù)往往是瓶頸批量直接砍掉了大量RTT開銷。壓縮就更直接了。Kafka支持gzip、snappy、lz4、zstd幾種壓縮算法壓縮發(fā)生在生產(chǎn)者端數(shù)據(jù)在整條鏈路里保持壓縮狀態(tài)消費(fèi)者端解壓。對于JSON文本這類可壓縮性很高的消息體壓縮率經(jīng)常能達(dá)到60%以上。當(dāng)網(wǎng)卡帶寬成為瓶頸時(shí)開壓縮比加機(jī)器性價(jià)比高得多。面試時(shí)可以提一句自己的經(jīng)驗(yàn)如果消息體已經(jīng)很小比如幾字節(jié)的埋點(diǎn)開壓縮反而會浪費(fèi)CPU因?yàn)閴嚎s頭開銷可能比消息本身還大。壓縮不是無腦開的要看數(shù)據(jù)特征。2.4 頁緩存才是Kafka真正的緩存Kafka沒有像很多中間件那樣用堆內(nèi)存做緩存層而是直接依賴操作系統(tǒng)的Page Cache。生產(chǎn)者寫入時(shí)先寫頁緩存由OS決定什么時(shí)候刷盤消費(fèi)者讀取時(shí)優(yōu)先讀頁緩存命中就直接返回完全不走磁盤。這個(gè)設(shè)計(jì)有它的好處第一進(jìn)程自己不用管理緩存淘汰策略交給OS更省心第二JVM堆內(nèi)存壓力小不容易因?yàn)榫彺鎸?dǎo)致GC問題第三進(jìn)程重啟后頁緩存還在不會像進(jìn)程內(nèi)緩存一樣重啟即失。Kafka在“用內(nèi)存”這個(gè)點(diǎn)上選了一條偷懶但特別聰明的路線。這里其實(shí)藏著一個(gè)面試加分點(diǎn)Kafka節(jié)點(diǎn)的可用內(nèi)存往往不是給JVM堆用的而是留給頁緩存用的。很多人調(diào)優(yōu)時(shí)只盯著堆大小其實(shí)生產(chǎn)環(huán)境里Kafka的堆內(nèi)存一般不需要設(shè)置得太大主機(jī)的大部分內(nèi)存應(yīng)該留給頁緩存。如果你能說出這句話面試官會覺得你是有實(shí)操經(jīng)驗(yàn)的。把幾個(gè)點(diǎn)串起來總結(jié)一下順序?qū)懡鉀Q了磁盤瓶頸零拷貝解決了數(shù)據(jù)發(fā)送瓶頸批量壓縮解決了網(wǎng)絡(luò)開銷頁緩存解決了讀寫路徑上的內(nèi)存效率問題。這四件事加在一起才是“Kafka為什么能支撐百萬并發(fā)”的完整答案。3. 可靠性四件套ack、ISR、HW、LEO的連環(huán)考3.1 生產(chǎn)者的acks參數(shù)每個(gè)選項(xiàng)背后的取舍可靠性這一塊面試官特別喜歡從生產(chǎn)者acks參數(shù)切入因?yàn)樗此坪唵螀s能帶出一連串概念。acks有三個(gè)取值取值行為風(fēng)險(xiǎn)適用場景0生產(chǎn)者發(fā)完即返回不等待確認(rèn)丟消息概率最大日志、監(jiān)控、允許丟棄的指標(biāo)1leader副本寫入成功即返回leader宕機(jī)時(shí)已寫消息可能丟失大部分默認(rèn)業(yè)務(wù)場景all等待ISR內(nèi)所有副本都寫入成功最安全但延遲更高交易、訂單、對賬等關(guān)鍵鏈路面試時(shí)只說“all更安全”不夠你要能說清楚為什么。關(guān)鍵在另一個(gè)參數(shù)min.insync.replicas。如果集群只有一個(gè)副本你就算設(shè)了acksallISR里也就它一個(gè)領(lǐng)導(dǎo)者一宕機(jī)數(shù)據(jù)照樣丟。所以生產(chǎn)環(huán)境至少要配3副本再把min.insync.replicas設(shè)成2含義是“至少寫進(jìn)兩個(gè)副本才算成功”。acksall配合min.insync.replicas2才是真正意義上的高可靠寫入。面試官可能會繼續(xù)追問“acksall會不會影響性能”。答案是“有影響但沒那么嚴(yán)重”。副本間的同步走的是內(nèi)網(wǎng)延遲通常很小遠(yuǎn)小于生產(chǎn)端和broker之間的網(wǎng)絡(luò)往返。關(guān)鍵鏈路用all非關(guān)鍵鏈路用1這是比較常見的生產(chǎn)策略。3.2 ISR機(jī)制判斷一個(gè)副本是否“跟得上”ISR全稱是in-sync replicas指的是和leader保持同步的副本集合。Kafka判斷一個(gè)follower是否跟得上靠的不是精確比較offset而是看它能否在replica.lag.time.max.ms這個(gè)時(shí)間窗口內(nèi)持續(xù)拉取消息默認(rèn)是30秒。超過這個(gè)時(shí)間沒拉取就把這個(gè)follower移出ISR。為什么用時(shí)間而不是用offset差距來判斷這是Kafka的一個(gè)設(shè)計(jì)細(xì)節(jié)。早期版本用“落后多少條”來判定結(jié)果在消息流量峰值時(shí)落后的follower很容易被誤踢出ISR導(dǎo)致副本頻繁進(jìn)出ISR穩(wěn)定性很差。后來改成時(shí)間窗口容忍短時(shí)間內(nèi)的領(lǐng)先更平滑。ISR在面試中經(jīng)常和選舉一起考。Kafka的leader選舉只允許ISR里的副本參與目的是保證新leader不會丟失已經(jīng)提交過的消息。你可以在回答里點(diǎn)一句“ISR就是Kafka在一致性和可用性之間做的動(dòng)態(tài)平衡”這會顯得你的認(rèn)知更系統(tǒng)。3.3 HW和LEO定義了消費(fèi)者能看見什么HWHigh Watermark和LEOLog End Offset是Kafka面試?yán)飪蓚€(gè)繞不開的縮寫。LEO是每個(gè)副本日志的最后一條offset位置。HW是ISR中所有副本都同步到的最新位置也叫高水位。消費(fèi)者只能讀到HW之前的消息HW之后的數(shù)據(jù)即使leader上已經(jīng)有了也不能算“已提交”。這個(gè)機(jī)制解決的核心問題是萬一leader掛掉換了一個(gè)新的leader消費(fèi)者之前讀到的消息仍然能對齊。如果消費(fèi)者提前讀了leader上還沒同步到follower的數(shù)據(jù)新leader切換后這些數(shù)據(jù)可能就沒了消費(fèi)者就會看到消息“回滾”。HW就是一道保險(xiǎn)。面試時(shí)可以打一個(gè)比方HW就像多人協(xié)作文檔里的“已同步版本號”大家都在這個(gè)版本號上達(dá)成共識后其他人才能引用這份內(nèi)容。這個(gè)類比面試官通常能秒懂。想再深入一點(diǎn)的話可以提一下Kafka 0.11之后對HW更新機(jī)制的改進(jìn)以及“Leader Epoch”這個(gè)概念。早期版本HW更新依賴follower的第二次fetch請求極端情況下會出現(xiàn)“數(shù)據(jù)丟失但offset不回退”的腦裂問題引入Leader Epoch后徹底解決了。面試中能講到這個(gè)層面差不多就是Kafka可靠性的進(jìn)階水平了。3.4 Leader選舉不是所有副本都能當(dāng)新leader當(dāng)leader宕機(jī)Kafka會從ISR里挑一個(gè)副本頂上。這里的核心參數(shù)是unclean.leader.election.enable默認(rèn)false意思是“不允許ISR之外的副本參與leader選舉”。如果把該參數(shù)設(shè)為true意味著哪怕一個(gè)副本落后得非常遠(yuǎn)它也可能成為新leader這就會導(dǎo)致大量已提交消息丟失。什么時(shí)候會有人舍得開一般是可用性優(yōu)先于一致性的極端場景——比如整個(gè)ISR全部宕機(jī)服務(wù)已經(jīng)不可用你寧愿快速恢復(fù)服務(wù)、接受丟一部分?jǐn)?shù)據(jù)也不愿意一直等ISR里的副本恢復(fù)。但絕大多數(shù)線上場景建議保持false。面試官如果問“Kafka是CP還是AP”你就可以用這個(gè)參數(shù)來回應(yīng)默認(rèn)情況下Kafka在極端故障時(shí)會犧牲可用性、保證數(shù)據(jù)不丟如果改了配置它又偏向可用性。Kafka本身不是簡單的CP或AP它是一套可配置的“最終一致多副本”模型。這一節(jié)如果能把a(bǔ)cks、ISR、HW、LEO四個(gè)概念串成一條線講清楚“生產(chǎn)者寫入 - 副本同步 - 消費(fèi)者可見 - leader切換”的全過程那面試?yán)锟煽啃韵嚓P(guān)的擴(kuò)展題基本都能接住。4. 不丟不重不亂消費(fèi)者端三個(gè)靈魂拷問4.1 消息不丟失要分三端看消費(fèi)端最容易翻車“Kafka消息會不會丟”是一道必考題。但很多人答的時(shí)候只談生產(chǎn)端和broker忘了消費(fèi)者這一側(cè)才是最容易丟消息的地方。完整答法一定要分三段生產(chǎn)者端開啟acksall配合retries重試、開啟冪等enable.idempotencetrue。冪等可以解決生產(chǎn)者重試導(dǎo)致的重復(fù)消息但它只保證單分區(qū)內(nèi)不重不保證跨分區(qū)事務(wù)。Broker端設(shè)置副本數(shù)大于等于2min.insync.replicas設(shè)置為2unclean.leader.election.enable保持false。這些配置配合起來broker層面基本能扛住單節(jié)點(diǎn)故障。消費(fèi)者端核心是“先處理業(yè)務(wù)邏輯再手動(dòng)提交offset”。如果你用自動(dòng)提交enable.auto.committrue消費(fèi)者拉取消息后立即提交offset但業(yè)務(wù)沒處理完進(jìn)程就掛了重啟后offset已經(jīng)提交那批消息就再也讀不到了。面試時(shí)可以直接給一個(gè)踩坑案例某個(gè)消費(fèi)任務(wù)在拉消息后調(diào)外部接口外部接口超時(shí)導(dǎo)致處理時(shí)間很長自動(dòng)提交的offset已經(jīng)到了但消息實(shí)際沒處理成功。后來改成手動(dòng)提交等業(yè)務(wù)邏輯執(zhí)行完再提交offset才把這個(gè)問題解決。這里有一個(gè)概念要澄清手動(dòng)提交offset后如果業(yè)務(wù)邏輯本身有bug導(dǎo)致消息處理失敗還是會“丟”——因?yàn)槟銢]重試就提交了。所以“消費(fèi)者不丟消息”的正確姿勢是業(yè)務(wù)邏輯失敗要主動(dòng)重試或者進(jìn)死信隊(duì)列只有確認(rèn)處理成功才提交offset。這才是工程上的完整閉環(huán)。4.2 重復(fù)消費(fèi)是“必然”冪等才是解法Kafka的默認(rèn)語義是at-least-once也就是至少一次。這意味著消費(fèi)者可能收到重復(fù)消息這是由設(shè)計(jì)決定的不是bug。重復(fù)消費(fèi)的三個(gè)常見來源生產(chǎn)者重試發(fā)送網(wǎng)絡(luò)抖動(dòng)導(dǎo)致生產(chǎn)者重發(fā)同一批消息broker收到重復(fù)數(shù)據(jù)。消費(fèi)者處理成功但沒提交offset就宕機(jī)恢復(fù)后會從舊offset重新消費(fèi)導(dǎo)致重復(fù)。Rebalance觸發(fā)分區(qū)重新分配后新的消費(fèi)者可能重新拉取之前已處理的消息。既然重復(fù)無法從根源上杜絕那解法就在業(yè)務(wù)側(cè)做冪等。面試答這里要舉幾個(gè)具體方案利用數(shù)據(jù)庫唯一鍵訂單號作為唯一索引重復(fù)插入直接報(bào)錯(cuò)忽略。利用Redis去重用SETNX設(shè)置一個(gè)全局唯一ID處理前先判斷是否已處理。狀態(tài)機(jī)校驗(yàn)比如支付回調(diào)場景判斷訂單狀態(tài)是否已經(jīng)“已支付”是則跳過。能答到這里說明你有生產(chǎn)意識。面試官要是再深挖可能會問“Kafka事務(wù)能不能實(shí)現(xiàn)精確一次”。這時(shí)候可以回答Kafka的Transactions API能實(shí)現(xiàn)跨分區(qū)精確一次但使用門檻較高而且對吞吐有影響。大多數(shù)業(yè)務(wù)用“at-least-once 冪等”就夠了沒必要為了精確一次把架構(gòu)復(fù)雜度拉高。4.3 順序性為什么局部有序是常態(tài)全局有序是奢望順序性問題在面試?yán)飵缀跏潜爻龅亩医?jīng)常以“怎么保證消息順序消費(fèi)”來問。先講底層同一個(gè)分區(qū)內(nèi)消息按照追加順序存儲消費(fèi)者默認(rèn)也是按順序拉取所以單分區(qū)是有序的。但一個(gè)topic有多個(gè)分區(qū)不同分區(qū)之間沒有全局順序。不同key的消息進(jìn)不同分區(qū)自然也就沒有順序保障。所以保證順序性的思路就是“讓需要有序的消息進(jìn)同一個(gè)分區(qū)”按業(yè)務(wù)key進(jìn)行分區(qū)比如同一個(gè)訂單號的消息全發(fā)到同一個(gè)分區(qū)。如果業(yè)務(wù)對全局順序有強(qiáng)需求那就把分區(qū)數(shù)設(shè)為1但吞吐會嚴(yán)重受限。消費(fèi)端也要配合即使同一分區(qū)的消息如果消費(fèi)者用多個(gè)線程并行處理順序同樣會被打亂。多線程消費(fèi)時(shí)要么按key做內(nèi)存隊(duì)列分桶每個(gè)key對應(yīng)一個(gè)單線程worker要么干脆串行化。面試官經(jīng)常在此處設(shè)置陷阱“我用單分區(qū)又起了多個(gè)消費(fèi)線程為什么順序還是亂的”這正是上面說的原因——broker里的消息有序但你的并發(fā)處理把順序弄沒了。分桶到內(nèi)存隊(duì)列是多數(shù)流處理框架的解法比如Flink里按key分組后就是并發(fā)處理但保證每個(gè)key內(nèi)部有序。再往深走一點(diǎn)你還可以提“順序性和性能天生沖突”。保序必然犧牲并發(fā)設(shè)計(jì)系統(tǒng)時(shí)要先搞清楚業(yè)務(wù)到底需不需要全局有序。大多數(shù)場景需要的只是“同一個(gè)用戶的動(dòng)作有序”這種級別按key分區(qū)就夠用了。5. 消費(fèi)組和Rebalance擴(kuò)展性的另一面5.1 消費(fèi)組Kafka能橫向擴(kuò)展消費(fèi)者的核心設(shè)計(jì)Kafka的消費(fèi)者是以“消費(fèi)組”為單位組織起來的。同一個(gè)組里的消費(fèi)者共同消費(fèi)一組topic一條消息只能被組內(nèi)的一個(gè)消費(fèi)者處理。不同消費(fèi)組之間互不影響各自維護(hù)自己的消費(fèi)進(jìn)度所以同一份數(shù)據(jù)可以被不同業(yè)務(wù)方消費(fèi)多次。這個(gè)設(shè)計(jì)解決了什么問題舉個(gè)例子一個(gè)訂單系統(tǒng)產(chǎn)生消息訂單服務(wù)消費(fèi)它做庫存扣減風(fēng)控服務(wù)也消費(fèi)它做風(fēng)險(xiǎn)識別。這兩個(gè)業(yè)務(wù)不希望互相干擾就可以各自建一個(gè)消費(fèi)組。批量和獨(dú)立消費(fèi)互不干擾在RabbitMQ那套模型里要麻煩得多。面試還常問“消費(fèi)者數(shù)量和分區(qū)數(shù)的關(guān)系”。答案是消費(fèi)組內(nèi)消費(fèi)者數(shù)量超過分區(qū)數(shù)時(shí)超出的消費(fèi)者會空閑。比如6個(gè)分區(qū)、10個(gè)消費(fèi)者只有6個(gè)能分到分區(qū)其余4個(gè)什么都不干。所以要提高消費(fèi)吞吐先看分區(qū)數(shù)夠不夠只加消費(fèi)者不加分區(qū)是沒用的。5.2 Rebalance的觸發(fā)機(jī)制為什么它常被詬病Rebalance可以說是一把雙刃劍。它保證了消費(fèi)組能自動(dòng)感知成員變化和分區(qū)變化但也是線上故障的常見源頭。觸發(fā)Rebalance的幾種情況消費(fèi)者加入或退出消費(fèi)組。訂閱的topic新增或刪除了分區(qū)。消費(fèi)者心跳超時(shí)被協(xié)調(diào)者判定下線。訂閱關(guān)系發(fā)生變化比如正則訂閱的主題變了。Rebalance的流程涉及一個(gè)關(guān)鍵角色GroupCoordinator也就是協(xié)調(diào)者。所有消費(fèi)者啟動(dòng)后向協(xié)調(diào)者注冊組內(nèi)推選出一個(gè)消費(fèi)者作為Leader由它根據(jù)分配策略生成分區(qū)分配方案再由協(xié)調(diào)者把方案廣播給全組。這個(gè)過程里整個(gè)消費(fèi)組會停止消費(fèi)看起來就是“消費(fèi)暫停、lag飆高”。面試官很可能追問“怎么減少Rebalance對業(yè)務(wù)的影響”。你可以給三個(gè)方向一是把session.timeout.ms和heartbeat.interval.ms配置合理避免因?yàn)樘幚砺徽`判下線二是調(diào)大max.poll.interval.ms給消費(fèi)者更長的處理窗口三是盡量把處理邏輯異步化讓poll線程保持活躍。真正線上出現(xiàn)“頻繁Rebalance”時(shí)十有八九是單條消息處理耗時(shí)超過了心跳閾值導(dǎo)致消費(fèi)者被踢出組。5.3 三種分區(qū)分配策略Range、RoundRobin、Sticky在Rebalance過程中具體怎么分配分區(qū)是由策略決定的這也是面試中常見的細(xì)節(jié)題。RangeAssignor按topic逐一分區(qū)。假設(shè)一個(gè)topic有10個(gè)分區(qū)、3個(gè)消費(fèi)者消費(fèi)者1分到0-3消費(fèi)者2分到4-6消費(fèi)者3分到7-9。如果多個(gè)topic都很大分配可能傾斜消費(fèi)者1總拿更多分區(qū)。RoundRobinAssignor把所有topic的分區(qū)拉平成一個(gè)環(huán)形隊(duì)列逐個(gè)輪詢分配給消費(fèi)者。多topic場景下更均衡。StickyAssignor在RoundRobin基礎(chǔ)上增加“粘性”盡量保留上一個(gè)分配周期中該消費(fèi)者已有的分區(qū)。這樣可以避免Rebalance時(shí)大范圍分區(qū)移動(dòng)降低不必要的消費(fèi)中斷和重復(fù)。Kafka 2.4之后默認(rèn)用的是StickyAssignor。它最核心的優(yōu)勢是“少移動(dòng)”尤其在消費(fèi)組成員頻繁變化的場景下能顯著減少遷移帶來的重復(fù)消費(fèi)。面試作答時(shí)可以補(bǔ)一句自己的判斷如果只有單個(gè)topicRange和RoundRobin差距不大多topic時(shí)RoundRobin更均衡Sticky更穩(wěn)定。實(shí)際團(tuán)隊(duì)都用Sticky因?yàn)樗染庥帜芸剡w移成本。6. 實(shí)戰(zhàn)追問積壓、延遲、集群異常怎么答6.1 消息積壓的定位思路先看生產(chǎn)還是消費(fèi)線上消息積壓是Kafka最常出現(xiàn)的故障類型面試官問“積壓了幾小時(shí)怎么排查”其實(shí)是在考察你有沒有一套可復(fù)用的排障方法。第一步先看有沒有l(wèi)ag。用kafka-consumer-groups.sh --describe --group 消費(fèi)組名可以直觀看到每個(gè)分區(qū)的current-offset和log-end-offset兩者差距就是積壓量。如果lag持續(xù)增長優(yōu)先懷疑消費(fèi)端如果lag沒有增長但消費(fèi)延遲很大再懷疑生產(chǎn)端寫入慢。第二步看消費(fèi)端是否出現(xiàn)了明顯瓶頸。常見的原因有單條消息處理太慢比如回調(diào)外部接口、慢SQL、加鎖競爭。消費(fèi)者并行度不夠分區(qū)數(shù)小于消費(fèi)者數(shù)量部分消費(fèi)者沒活干。消費(fèi)者代碼拋異常導(dǎo)致消息反復(fù)重試消費(fèi)進(jìn)度卡住。下游存儲出現(xiàn)性能問題比如數(shù)據(jù)庫連接池被打滿。第三步才是動(dòng)手解決。應(yīng)急方案不外乎四類加消費(fèi)者實(shí)例并保證消費(fèi)者數(shù)量不超過分區(qū)數(shù)臨時(shí)把積壓消息轉(zhuǎn)發(fā)到新的topic用多組消費(fèi)者并行分?jǐn)偤笤賹懟貎?yōu)化單條消息的處理邏輯批量寫入、異步化如果業(yè)務(wù)允許也可以直接跳過積壓只消費(fèi)最新消息。面試?yán)锬馨堰@些說得有條理就算通過了。不用怕方案不完美面試官想看的是你有沒有排查鏈路意識而不是有沒有一個(gè)“一招鮮”的答案。6.2 消息延遲高的排查順序鏈路三段的檢索法“消息延遲高”和“消息積壓”經(jīng)?；煸谝黄饐柕鼈儾煌耆且换厥?。積壓是存量問題延遲是實(shí)時(shí)性問題?；卮鹧舆t高的排查我更習(xí)慣按生產(chǎn)端、broker、消費(fèi)端三段來檢索生產(chǎn)端延遲看生產(chǎn)者send接口的返回耗時(shí)檢查網(wǎng)絡(luò)帶寬、bootstrap.servers配置、max.block.ms是否設(shè)置過小導(dǎo)致發(fā)送阻塞。Broker端延遲看磁盤IO是否飽和如果log.dirs所在盤IO使用率長期在90%以上寫入就會變慢頁緩存壓力大時(shí)也可能拖慢leader副本的寫入。消費(fèi)端延遲看單次poll返回后到業(yè)務(wù)處理完成的耗時(shí)以及是否有等待鎖、外部接口慢等情況。網(wǎng)絡(luò)鏈路內(nèi)網(wǎng)跨可用區(qū)時(shí)網(wǎng)絡(luò)抖動(dòng)可能導(dǎo)致fetch請求變慢延遲升高。有一個(gè)容易忽略的坑如果消費(fèi)者拉取速度快但處理速度慢lag會持續(xù)上漲如果處理速度快但拉取請求頻率被拉長延遲也會升高但lag不一定大。所以“消息延遲高”一定要先查是“拉得慢”還是“處理得慢”這兩條路的排查方向完全不一樣。補(bǔ)充一個(gè)實(shí)用命令Kafka自帶的kafka-consumer-groups.sh可以看到按分區(qū)細(xì)分的lag再結(jié)合消費(fèi)組日志里的poll耗時(shí)統(tǒng)計(jì)基本能定位到具體是哪個(gè)分區(qū)、哪段邏輯出了問題。6.3 Kafka部署與集群配置聊起來像有經(jīng)驗(yàn)的人面試一般不直接考“怎么敲安裝命令”但會通過“你們生產(chǎn)環(huán)境怎么部署的”“集群怎么規(guī)劃的”這類問題來驗(yàn)證你有沒有真實(shí)落地經(jīng)驗(yàn)。單機(jī)版部署很簡單下載Kafka二進(jìn)制包改config/server.properties里broker.id、log.dirs、listeners這幾個(gè)核心配置啟動(dòng)ZooKeeper和Kafka就行。新版Kafka支持KRaft模式可以不依賴ZooKeeper直接跑適合新項(xiàng)目。用Docker部署則是面試和本地實(shí)驗(yàn)的高頻場景。用bitnami/kafka鏡像時(shí)關(guān)鍵是配置環(huán)境變量KAFKA_CFG_BROKER_ID、KAFKA_CFG_LISTENERS、KAFKA_CFG_ADVERTISED_LISTENERS這些。其中advertised.listeners是個(gè)大坑容器內(nèi)用PLAINTEXT://localhost:9092外部客戶端訪問要用宿主機(jī)IP或者映射后的地址。很多人docker跑通了但外部連不上基本都是這個(gè)配置沒配對。集群部署要說的點(diǎn)更多broker.id必須全局唯一。副本數(shù)不要超過broker數(shù)否則副本會分配失敗。多磁盤環(huán)境log.dirs可以配置成多個(gè)目錄Kafka會自動(dòng)把分區(qū)分散到不同磁盤。內(nèi)外網(wǎng)分離場景要區(qū)分listeners和advertised.listeners否則客戶端拿到錯(cuò)誤的broker地址。版本升級不能跳版本Kafka消息格式和磁盤格式有兼容性要求升級前建議先查官方遷移文檔。這些屬于“沒做過真不知道”的經(jīng)驗(yàn)面試?yán)镏鲃?dòng)講出來比背任何八股文都有說服力。6.4 可視化工具與常用命令給回答加分的好東西面試聊到“排查問題”時(shí)順帶提一下可視化工具有意外收獲。工具本身不復(fù)雜關(guān)鍵是能體現(xiàn)你的實(shí)際運(yùn)維經(jīng)驗(yàn)。Offset Explorer原Kafka Tool桌面客戶端可以瀏覽集群、topic、分區(qū)和消息內(nèi)容適合本地調(diào)試。KafdropWeb界面輕量能看topic和消息適合快速驗(yàn)證。Kafka UI功能更全的Web工具支持查看消費(fèi)組lag、管理topic。命令行的幾個(gè)常備命令也值得熟記kafka-topics.sh --bootstrap-server ... --list / --describekafka-console-producer.sh 和 kafka-console-consumer.sh 用于驗(yàn)證生產(chǎn)和消費(fèi)kafka-consumer-groups.sh --describe --group ... 查看lagkafka-configs.sh --describe --entity-type topics --entity-name ... 查看topic配置面試時(shí)你可以說排查積壓我用kafka-consumer-groups.sh看lag快速驗(yàn)證消息格式用kafka-console-consumer.sh日?？醇籂顟B(tài)用Kafka UI。這句話一出去面試官就知道你不只是紙上談兵。7. 最后再給一套能直接講的“口語化答案”與經(jīng)驗(yàn)收尾7.1 回答面試題時(shí)的節(jié)奏結(jié)論優(yōu)先分層展開很多人面試Kafka時(shí)明明知道答案卻說不好問題大多出在“沒有取舍、沒有節(jié)奏”。一口氣把知道的全倒出來面試官反而覺得你沒重點(diǎn)。我建議的節(jié)奏是“結(jié)論優(yōu)先 分層展開”。比如被問到“Kafka為什么快”你可以直接說“Kafka的高吞吐主要靠四個(gè)機(jī)制分別是順序?qū)?、零拷貝、批量壓縮和頁緩存?！比缓笾饌€(gè)機(jī)制一句話解釋如果面試官感興趣會自己對某個(gè)點(diǎn)繼續(xù)追問。這樣既顯得有框架又給面試官留了互動(dòng)空間。面試本質(zhì)上是對話不是你一個(gè)人的背誦比賽。你再熟的知識點(diǎn)也要學(xué)會“拋出來等追問”而不是一口氣講完然后冷場。7.2 一個(gè)能串起所有考點(diǎn)的完整場景日志數(shù)據(jù)管道如果面試官最后問“有沒有完整的項(xiàng)目案例”或者讓你“設(shè)計(jì)一個(gè)基于Kafka的架構(gòu)”我給你一個(gè)很快能講清楚的場景應(yīng)用日志數(shù)據(jù)管道。具體是多個(gè)微服務(wù)應(yīng)用把運(yùn)行日志和用戶行為埋點(diǎn)發(fā)送到Kafka下游有幾個(gè)獨(dú)立的消費(fèi)組一個(gè)負(fù)責(zé)實(shí)時(shí)日志監(jiān)控告警一個(gè)負(fù)責(zé)把數(shù)據(jù)寫入數(shù)據(jù)倉庫做離線分析還有一個(gè)對接Flink做實(shí)時(shí)大屏統(tǒng)計(jì)。這個(gè)場景能串起Kafka幾乎所有核心考點(diǎn)topic設(shè)計(jì)按業(yè)務(wù)域分topic比如app-log、user-event。分區(qū)與key日志按應(yīng)用名或用戶ID分區(qū)保證同一應(yīng)用或同一用戶的數(shù)據(jù)有序。生產(chǎn)端可靠性關(guān)鍵鏈路acksall普通日志acks1。消費(fèi)者組隔離多個(gè)消費(fèi)組各消費(fèi)各的互不影響。冪等消費(fèi)數(shù)倉寫入用唯一鍵做冪等避免重復(fù)數(shù)據(jù)。積壓排查通過lag監(jiān)控及時(shí)發(fā)現(xiàn)消費(fèi)瓶頸并擴(kuò)容。能在面試現(xiàn)場拿出這樣一個(gè)完整場景和只能零散背題的人相比完全是兩個(gè)層次。7.3 個(gè)人實(shí)操中的幾點(diǎn)體會這節(jié)算是我自己踩坑之后的經(jīng)驗(yàn)總結(jié)分享幾個(gè)對面試和實(shí)戰(zhàn)都有用的體會一是不要一開始就追完美配置。先用默認(rèn)配置把鏈路跑通觀察生產(chǎn)速率、消費(fèi)lag、磁盤IO這些指標(biāo)再根據(jù)實(shí)測結(jié)果去調(diào)batch.size、linger.ms、副本數(shù)這些參數(shù)。沒有數(shù)據(jù)支撐的調(diào)優(yōu)都是拍腦袋。二是lag監(jiān)控一定要做。對Kafka來說消費(fèi)組的lag就是消息系統(tǒng)健康的晴雨表很多故障在lag持續(xù)增長時(shí)就能被提前發(fā)現(xiàn)。哪怕不上監(jiān)控平臺定時(shí)腳本跑一遍kafka-consumer-groups.sh也強(qiáng)過完全不看。三是八股文里的原理和線上問題一旦對照上記憶會非常牢。比如你遇到過消費(fèi)者處理慢導(dǎo)致Rebalance再回去看session.timeout.ms和max.poll.interval.ms這幾個(gè)參數(shù)就再也不會忘記它們的作用了。面試準(zhǔn)備Kafka能背的東西很多但真正值錢的是“能講清楚為什么”的能力。希望這份拆解能幫你把散落的知識點(diǎn)串成體系。第22卷見。