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