說(shuō)實(shí)話Kafka這個(gè)題目我已經(jīng)被問(wèn)過(guò)太多次了。每次帶新人或者幫朋友排查線上問(wèn)題只要聊到消息中間件Kafka幾乎是繞不開的那個(gè)名字。很多人一開始覺得它就是一個(gè)性能很好的消息隊(duì)列但真正上手之后才發(fā)現(xiàn)它的架構(gòu)里藏著大量和傳統(tǒng)隊(duì)列完全不同的設(shè)計(jì)思路。如果你只是把Kafka當(dāng)RabbitMQ用那大概率會(huì)在消費(fèi)順序、堆積處理、分區(qū)擴(kuò)容這些環(huán)節(jié)吃大虧。這篇東西我不會(huì)去貼官方文檔那玩意已經(jīng)夠全了。我按照自己從零搭建集群、壓測(cè)、排查線上故障的經(jīng)驗(yàn)把Kafka的基礎(chǔ)架構(gòu)拆開揉碎講一遍。適合兩類人看一是剛接觸分布式消息系統(tǒng)、想系統(tǒng)搞懂Kafka核心概念的開發(fā)者二是已經(jīng)在用Kafka、但遇到分區(qū)、副本、Rebalance、積壓等問(wèn)題時(shí)只能靠猜的運(yùn)維和后端同學(xué)?？赐昴隳芙⒁粡埻暾募軜?gòu)地圖再用這張地圖去對(duì)照實(shí)際代碼和參數(shù)很多困惑會(huì)迎刃而解。1. 為什么選型時(shí)最終落在了Kafka身上先把Kafka擺在它該在的位置。它不是一個(gè)普通的消息隊(duì)列而是一個(gè)分布式流處理平臺(tái)。這個(gè)定位決定了它的一切架構(gòu)設(shè)計(jì)。傳統(tǒng)消息隊(duì)列的核心訴求是把生產(chǎn)者和消費(fèi)者解耦消息被消費(fèi)完就刪除完了。Kafka則把消息當(dāng)成不可變的日志流寫入之后按序追加消費(fèi)者不是取出一條消息而是讀取到某個(gè)位置的數(shù)據(jù)。同一個(gè)主題的數(shù)據(jù)可以反復(fù)讀、按需讀由消費(fèi)者自己維護(hù)進(jìn)度。這個(gè)差異帶來(lái)的連鎖反應(yīng)是吞吐量上限完全不同因?yàn)镵afka可以做順序?qū)懘疟P消費(fèi)者天然支持多組并行因?yàn)楸舜嘶ゲ桓蓴_消息堆積成了家常便飯而不是事故因?yàn)镵afka本來(lái)就是為大日志場(chǎng)景設(shè)計(jì)的。我見過(guò)不少團(tuán)隊(duì)從RabbitMQ遷到Kafka最大的感受是心智模型要換一遍。在RabbitMQ里你考慮的是隊(duì)列、exchange、routing key在Kafka里你考慮的是主題Topic怎么分片、分區(qū)Partition怎么分布、副本怎么冗余、消費(fèi)者組怎么分配。這不是語(yǔ)法層面的區(qū)別是架構(gòu)哲學(xué)的區(qū)別。選型建議也比較直接如果你需要的是每秒鐘幾萬(wàn)條消息的推送單條消息延遲毫秒級(jí)且允許一定的批量緩沖Kafka非常適合如果你需要復(fù)雜的路由規(guī)則、按優(yōu)先級(jí)處理、每一條消息都必須準(zhǔn)確投遞到指定業(yè)務(wù)方那RabbitMQ這類傳統(tǒng)隊(duì)列更順手。我自己做技術(shù)方案時(shí)的判斷標(biāo)準(zhǔn)是看消息流是否線性、是否會(huì)被多個(gè)下游重復(fù)消費(fèi)——只要這兩個(gè)問(wèn)題的答案偏向是Kafka基本就是最優(yōu)解。2. Topic、Partition、Offset這套物理世界觀很多資料喜歡把Topic叫主題但把它理解為一類事件的集合更準(zhǔn)確。比如訂單系統(tǒng)里有訂單創(chuàng)建、支付完成、退款成功三類事件那就建order-created、order-paid、order-refunded三個(gè)Topic。Topic里面存的不是結(jié)構(gòu)化表格而是一個(gè)個(gè)帶時(shí)間戳、帶key的字節(jié)數(shù)組消息沒(méi)人在這一層去約束字段結(jié)構(gòu)。真正撐起Kafka架構(gòu)的是Partition。一個(gè)Topic會(huì)被分割成若干個(gè)分區(qū)每個(gè)分區(qū)是一個(gè)有序的、不可變更的日志文件。消息寫入分區(qū)后在分區(qū)內(nèi)部按順序排列位置由Offset偏移量來(lái)標(biāo)識(shí)。Offset是一個(gè)只增不減的64位整數(shù)它從0開始每條新消息都會(huì)拿到當(dāng)前分區(qū)內(nèi)最新的Offset值。2.1 Partition到底在物理上是什么如果只從邏輯上理解分區(qū)你可能會(huì)覺得分區(qū)就是一堆消息文件。實(shí)際在磁盤上一個(gè)分區(qū)對(duì)應(yīng)一個(gè)目錄目錄名規(guī)則是主題名-分區(qū)編號(hào)比如order-paid-0、order-paid-1。目錄里存放的是一組分段的日志文件每個(gè)segments文件大小默認(rèn)到1GB就會(huì)滾動(dòng)生成新的。文件命名很有意思命名規(guī)則是該segment消息的最小Offset作為文件名比如文件名叫00000000000000000000.log意味著這個(gè)文件里的第一條消息Offset是0。分區(qū)內(nèi)消息順序有保證但Topic整體沒(méi)有順序。如果你需要全局順序最粗暴的做法是讓整個(gè)Topic只有一個(gè)分區(qū)——但這樣吞吐量會(huì)被限制在一個(gè)分區(qū)的寫入能力上。Kafka給出的折中是按key路由同一條業(yè)務(wù)鏈路上的消息比如同一個(gè)訂單ID對(duì)應(yīng)的所有事件通過(guò)指定key哈希到同一個(gè)分區(qū)內(nèi)這樣就能保證這個(gè)訂單的事件順序是全局有序的。這在實(shí)際業(yè)務(wù)里已經(jīng)覆蓋90%的場(chǎng)景沒(méi)必要追求整個(gè)Topic的全局有序。2.2 Offset消費(fèi)者的進(jìn)度書簽每個(gè)消費(fèi)者組在消費(fèi)某個(gè)分區(qū)時(shí)會(huì)記錄自己已經(jīng)消費(fèi)到的Offset。你可以把它理解為一本書的書簽生產(chǎn)者不斷在末尾寫新頁(yè)消費(fèi)者從書簽位置繼續(xù)往后讀讀完再更新書簽。這個(gè)設(shè)計(jì)的關(guān)鍵好處是消費(fèi)者可以隨時(shí)回退——比如你寫了一個(gè)bug把數(shù)據(jù)消費(fèi)錯(cuò)了只要把Offset調(diào)回去就能重新消費(fèi)一遍數(shù)據(jù)不會(huì)因?yàn)楸蛔x走就消失。Offset的存儲(chǔ)經(jīng)歷了變化。老版本里它被存在ZooKeeper中但ZK不是為高頻寫設(shè)計(jì)的消費(fèi)者一多就會(huì)出現(xiàn)性能瓶頸。所以后來(lái)的版本把Offset提交到了一個(gè)叫__consumer_offsets的內(nèi)部Topic里默認(rèn)50個(gè)分區(qū)副本數(shù)跟隨broker數(shù)量。這個(gè)Topic不在業(yè)務(wù)層面暴露但排查堆積問(wèn)題時(shí)經(jīng)常需要關(guān)注它。我第一次排查大集群消費(fèi)異常時(shí)就是在這個(gè)內(nèi)部Topic上發(fā)現(xiàn)某個(gè)segment文件所在的磁盤快滿了才定位到問(wèn)題源頭。2.3 消息可以重復(fù)讀這才是日志的魅力說(shuō)一個(gè)和傳統(tǒng)隊(duì)列體驗(yàn)差異最大的點(diǎn)Kafka刪消息不是消費(fèi)完就刪而是按時(shí)間保留。默認(rèn)log.retention.hours168也就是消息保留7天。在這7天內(nèi)任何消費(fèi)者組都可以從任意Offset開始重新讀數(shù)據(jù)哪怕它之前已經(jīng)消費(fèi)到了最新的位置。有一次某公司的數(shù)據(jù)團(tuán)隊(duì)做數(shù)倉(cāng)重算需要重新拉取過(guò)去三天某個(gè)用戶行為Topic的全部數(shù)據(jù)。如果是傳統(tǒng)隊(duì)列這個(gè)消息早就被消費(fèi)刪除了根本沒(méi)法補(bǔ)數(shù)。但在Kafka里只需要給消費(fèi)者組指定一個(gè)初始Offset或者直接用一個(gè)全新的消費(fèi)者組去消費(fèi)數(shù)據(jù)就隨便讀。日志可回放這個(gè)特性對(duì)于離線和準(zhǔn)實(shí)時(shí)場(chǎng)景來(lái)說(shuō)價(jià)值極高這是Kafka和大量傳統(tǒng)MQ最本質(zhì)的功能區(qū)別之一。概念邏輯含義物理對(duì)應(yīng)關(guān)鍵屬性Topic事件的類別多個(gè)分區(qū)目錄的集合可通過(guò)partitions參數(shù)分區(qū)Partition消息的有序日志流一個(gè)目錄下的segments文件分區(qū)內(nèi)有序跨分區(qū)無(wú)序Offset消息在分區(qū)內(nèi)的序號(hào)持久化于__consumer_offsets支持手動(dòng)重置以實(shí)現(xiàn)重放Replica分區(qū)的冗余副本同一分區(qū)的多個(gè)副本目錄一個(gè)Leader多個(gè)Follower這段物理世界觀是整個(gè)Kafka的基礎(chǔ)后續(xù)所有細(xì)節(jié)——寫入路徑、高可用、消費(fèi)組、存儲(chǔ)清理——都是圍繞它展開的。3. Producer寫入鏈路一條消息是如何落盤的看完了存儲(chǔ)模型現(xiàn)在沿著一條消息的生產(chǎn)鏈路走一遍。這個(gè)路徑上有三個(gè)最容易踩坑的環(huán)節(jié)分區(qū)器選分區(qū)、緩沖區(qū)攢批量、發(fā)送確認(rèn)與重試。3.1 分區(qū)器為什么你的消息去了它該去的地方Producer在發(fā)送一條消息時(shí)會(huì)先經(jīng)過(guò)分區(qū)器決定這條消息放進(jìn)哪個(gè)Partition。默認(rèn)的分區(qū)策略是如果消息指定了partition字段直接用指定分區(qū)如果沒(méi)有指定分區(qū)但指定了key對(duì)key做哈希取模落到某個(gè)分區(qū)如果key也沒(méi)指定使用粘性分區(qū)策略在同一個(gè)批次內(nèi)隨機(jī)選一個(gè)分區(qū)用完一輪再換。第一項(xiàng)和第二項(xiàng)比較好懂重點(diǎn)說(shuō)第三項(xiàng)。早期的Kafka是每次發(fā)送都做一次隨機(jī)分區(qū)這樣每條消息都單獨(dú)一個(gè)分區(qū)批次零散吞吐量上不去。后來(lái)改進(jìn)成Sticky Partition一批消息先落在同一個(gè)分區(qū)的緩沖區(qū)里攢滿了或者到時(shí)間了再一起發(fā)出去這樣batch利用率高吞吐量提升非常明顯。實(shí)測(cè)下來(lái)如果你的業(yè)務(wù)消息沒(méi)有天然key但又想盡量均勻分布粘性分區(qū)已經(jīng)足夠好。真有全局均衡的強(qiáng)迫癥可以自己做分區(qū)器但絕大多數(shù)場(chǎng)景沒(méi)必要。3.2 batch.size和linger.ms一對(duì)容易顧此失彼的參數(shù)Kafka的高吞吐密碼是批量發(fā)送而不是單條送達(dá)。Producer內(nèi)存里有一塊緩沖區(qū)buffer.memory默認(rèn)32MB消息先放進(jìn)緩沖區(qū)由發(fā)送線程按批次調(diào)起發(fā)送。batch.size默認(rèn)16KB表示一個(gè)批次占滿16KB就立即發(fā)送linger.ms默認(rèn)0表示即使批次沒(méi)滿也立即發(fā)送。這兩參數(shù)放在一起看很有意思。linger.ms0時(shí)消息進(jìn)緩沖區(qū)就馬上發(fā)延遲低但batch通常很小吞吐上不去。linger.ms5時(shí)消息會(huì)在緩沖區(qū)多等5毫秒讓更多消息湊成批次再發(fā)吞吐提升明顯代價(jià)是延遲多了幾毫秒。生產(chǎn)經(jīng)驗(yàn)是高吞吐場(chǎng)景優(yōu)先調(diào)大batch.size到32KB~64KBlinger.ms設(shè)到5~10毫秒這個(gè)組合在絕大多數(shù)場(chǎng)景下效果好。有一個(gè)誤區(qū)我得提一下如果單條消息本身就很大比如超過(guò)1MBbatch.size設(shè)置再大也沒(méi)用這種場(chǎng)景應(yīng)該先考慮壓縮或者調(diào)整消息體設(shè)計(jì)而不是調(diào)Batch參數(shù)。我見過(guò)一個(gè)團(tuán)隊(duì)把batch.size調(diào)到5MB結(jié)果OOM了問(wèn)題是他們單條消息有800KB。3.3 acks、重試與冪等數(shù)據(jù)不丟也不能亂序發(fā)送確認(rèn)有三級(jí)acks0發(fā)出去就算成功有可能丟acks1Leader寫入就算成功acksall所有ISR副本都寫入才算成功。默認(rèn)值是acksall在不能丟數(shù)據(jù)的場(chǎng)景下建議保持這個(gè)配置。但acksall也有代價(jià)。如果ISR只有一個(gè)Leader沒(méi)有Follower那all和1沒(méi)區(qū)別。所以需要把min.insync.replicas設(shè)為2意思是至少有兩個(gè)副本確認(rèn)成功才返回。這樣即使Leader宕機(jī)Follower手上還有完整數(shù)據(jù)。這個(gè)參數(shù)組合看起來(lái)簡(jiǎn)單但很多生產(chǎn)事故都是因?yàn)橹慌淞薬cksall卻沒(méi)配min.insync.replicas等于白配。重試機(jī)制要特別小心。retries默認(rèn)是一個(gè)較大的值比如INT_MAX附近而enable.idempotence決定是否開啟冪等。強(qiáng)烈建議開啟冪等它保證Producer在重試時(shí)不會(huì)產(chǎn)生重復(fù)數(shù)據(jù)。而且開啟冪等之后Producer內(nèi)部會(huì)自動(dòng)把a(bǔ)cks調(diào)整為all把max.in.flight.requests.per.connection調(diào)整為5這些參數(shù)是配套的我第一次手動(dòng)配置時(shí)沒(méi)注意這些聯(lián)動(dòng)關(guān)系導(dǎo)致重復(fù)消息暴增。重試還有個(gè)隱藏問(wèn)題重試可能導(dǎo)致亂序。比如你連著發(fā)了兩條消息到同一個(gè)分區(qū)第一條發(fā)送超時(shí)第二條已經(jīng)發(fā)出去了此時(shí)第一條重試順序就變成2、1。解決方案就是開啟冪等它會(huì)保證單個(gè)Producer對(duì)單個(gè)分區(qū)的消息順序不亂。理解了這一點(diǎn)你就知道為什么在很多生產(chǎn)配置里enable.idempotencetrue是缺省推薦。4. 副本機(jī)制與Broker高可用從多副本到ISR的演進(jìn)Broker層的高可用本質(zhì)上是把分區(qū)數(shù)據(jù)復(fù)制多份當(dāng)某臺(tái)物理機(jī)掛了另一臺(tái)上還有數(shù)據(jù)可用。這部分如果理解不到位你會(huì)遇到明明配置了3副本數(shù)據(jù)還是丟了的詭異情況。4.1 Leader與Follower不是主從復(fù)制而是追日志每個(gè)分區(qū)有一個(gè)Leader副本和多個(gè)Follower副本。所有生產(chǎn)者和消費(fèi)者的讀寫都走LeaderFollower只是從Leader那里拉取數(shù)據(jù)、跟上進(jìn)度。這里關(guān)鍵點(diǎn)有兩個(gè)第一Follower拉取數(shù)據(jù)不是靠Leader推送而是Follower主動(dòng)發(fā)請(qǐng)求去拉。拉取的頻率由replica.fetch.wait.max.ms控制默認(rèn)500毫秒一次。這個(gè)設(shè)計(jì)讓Follower的負(fù)載變成可控的自適應(yīng)節(jié)奏不會(huì)像推模式那樣Leader耗盡全力。第二Leader處理Follower拉請(qǐng)求的方式是返回從Leader當(dāng)前寫到的位置開始的數(shù)據(jù)。如果Follower一直跟不上它和Leader的Offset差距越來(lái)越大。什么時(shí)候判定一個(gè)Follower跟不上由replica.lag.time.max.ms控制默認(rèn)10秒。如果Follower超過(guò)10秒沒(méi)有向Leader請(qǐng)求數(shù)據(jù)或者請(qǐng)求的Offset一直落后太多它就會(huì)被移出ISR。4.2 ISR只有跟上節(jié)奏的副本才有資格做后備ISR全稱是In-Sync Replicas指和Leader保持同步的副本集合。這個(gè)概念很多人第一次看會(huì)忽略但它是Kafka可靠性模型的核心。不要求所有副本都同步只要求ISR內(nèi)同步。舉個(gè)實(shí)際場(chǎng)景。一個(gè)Topic有3個(gè)副本分別落在機(jī)器A、B、C上Leader在A。如果C機(jī)器發(fā)生了長(zhǎng)時(shí)間GCFull GC了5分鐘它的Follower線程暫停了5分鐘拉取此時(shí)Leader的replica.lag.time.max.ms超時(shí)判定生效C被移出ISR。此時(shí)ISR只有A和B。如果A在這時(shí)宕機(jī)Kafka會(huì)從B中選出新LeaderB上的數(shù)據(jù)是完整的消息不丟。但如果連B也宕機(jī)了ISR里只剩一個(gè)不可用的A那這個(gè)時(shí)候還能不能繼續(xù)寫取決于unclean.leader.election.enable。默認(rèn)為false表示寧可分區(qū)不可用也不允許不同步的副本上位成為L(zhǎng)eader。這個(gè)參數(shù)不要輕易改成true一旦改成trueC這種落后大截的副本就能被選成Leader所有在故障期間寫入A的數(shù)據(jù)全部丟失這在金融、結(jié)算類業(yè)務(wù)里是致命的。我曾在生產(chǎn)環(huán)境遇到過(guò)ISR收縮的事故。某個(gè)大Topic的寫入量翻了三倍Follower拉取線程跟不上ISR從3縮成了1。當(dāng)時(shí)數(shù)據(jù)沒(méi)丟但可用性已變成單點(diǎn)風(fēng)險(xiǎn)好在排查及時(shí)把Topic的分區(qū)數(shù)從12擴(kuò)到24同時(shí)給Follower所在的機(jī)器加了帶寬限制ISR才穩(wěn)定回到3。日常巡檢一定盯著ISR數(shù)量只要小于配置副本數(shù)就得往Follower拉取跟不上這個(gè)方向去查。4.3 從ZooKeeper到KRaft控制面的簡(jiǎn)化在Kafka 2.8之前Controller的角色由ZooKeeper承擔(dān)。Broker的上下線、Leader選舉、元數(shù)據(jù)變更都要經(jīng)過(guò)ZK。ZK本身也是一個(gè)獨(dú)立系統(tǒng)維護(hù)它等于集群里多養(yǎng)一個(gè)調(diào)度中心運(yùn)維成本不低。從3.3版本引入、在3.x版本開始快速成熟的KRaft模式把Controller和元數(shù)據(jù)直接內(nèi)置進(jìn)Kafka自身不再依賴ZK。KRaft模式下的Controller還是那個(gè)Controller但不再需要獨(dú)立的ZK集群元數(shù)據(jù)通過(guò)內(nèi)部日志復(fù)制協(xié)議同步。我自己的建議是如果是新項(xiàng)目Kafka版本在3.5以上就直接用KRaft模式少一套組件少一些故障點(diǎn)。已經(jīng)在用ZK的老集群如果業(yè)務(wù)穩(wěn)定可以慢慢遷移不急著動(dòng)但新集群完全沒(méi)必要再引入ZK。5. Consumer消費(fèi)鏈路冪等的推進(jìn)器和Rebalance風(fēng)暴消費(fèi)端是一個(gè)大坑密集區(qū)幾乎所有消息堆積和重復(fù)消費(fèi)的故障都出在這一層。先看Consumer的基礎(chǔ)模型以消費(fèi)者組為單位組內(nèi)成員共同消費(fèi)一個(gè)Topic的所有分區(qū)每個(gè)分區(qū)在同一時(shí)刻只能被組內(nèi)的一個(gè)Consumer消費(fèi)。5.1 Consumer如何決定自己消費(fèi)哪些分區(qū)同一組內(nèi)的多個(gè)Consumer在啟動(dòng)時(shí)會(huì)觸發(fā)一次分區(qū)分配分配算法默認(rèn)是RangeAssignor按分區(qū)范圍和Consumer數(shù)量均分。后來(lái)有了RoundRobinAssignor和更推薦的StickyAssignor。我當(dāng)時(shí)帶團(tuán)隊(duì)遷移時(shí)把默認(rèn)的RangeAssignor改成了StickyAssignor因?yàn)镽ange策略在Consumer數(shù)量變化時(shí)會(huì)導(dǎo)致全量分區(qū)重新分配。比如原來(lái)4個(gè)Consumer各拿3個(gè)分區(qū)其中一個(gè)Consumer掛了Range會(huì)觸發(fā)所有分區(qū)全部重新分配3個(gè)存活的Consumer要把6個(gè)分區(qū)全部重新認(rèn)領(lǐng)一遍這個(gè)過(guò)程就叫Rebalance。StickyAssignor會(huì)盡量保有原來(lái)的分配關(guān)系只把掛掉Consumer的分區(qū)勻給其他存活成員觸發(fā)面小很多。Rebalance的破壞性可能超出你的直覺。在Rebalance期間整個(gè)消費(fèi)組的所有Consumer都會(huì)暫停消費(fèi)直至分配完成。如果集群很大、分區(qū)數(shù)很多Rebalance耗時(shí)可能拉長(zhǎng)到幾十秒甚至分鐘級(jí)。我曾經(jīng)在3000個(gè)分區(qū)的Topic上觸發(fā)過(guò)錯(cuò)誤類型的Rebalance消費(fèi)暫停了近3分鐘業(yè)務(wù)側(cè)立刻報(bào)警。5.2 兩個(gè)心跳參數(shù)決定了你多久被判定死亡session.timeout.ms和heartbeat.interval.ms是一對(duì)容易設(shè)置失衡的參數(shù)。心跳就是Consumer定時(shí)告訴Broker我還活著。如果Broker在session.timeout.ms內(nèi)沒(méi)有收到心跳就判定該Consumer失效觸發(fā)Rebalance。heartbeat.interval.ms建議設(shè)為session.timeout.ms的三分之一比如timeout是10秒heartbeat設(shè)為3秒左右這樣能在最大時(shí)間內(nèi)及時(shí)發(fā)現(xiàn)故障。但后來(lái)Kafka加了一個(gè)更重要的參數(shù)max.poll.interval.ms。它和心跳沒(méi)有關(guān)系它管的是Consumer實(shí)際處理消息有沒(méi)有超時(shí)。比如默認(rèn)值是5分鐘如果Consumer處理一批消息的時(shí)間超過(guò)了5分鐘比如這批消息里有大JSON需要調(diào)用遠(yuǎn)程服務(wù)即使Consumer心跳正常也會(huì)被判定失聯(lián)踢出消費(fèi)組觸發(fā)Rebalance。很多消費(fèi)堆積但日志顯示Consumer還在跑的怪現(xiàn)象根源就在這里——處理慢被誤判為失聯(lián)分區(qū)被分給別人自己的Consumer還在獨(dú)立處理舊批次然后兩邊開始重復(fù)消費(fèi)。處理方案有兩條路一是調(diào)大max.poll.interval.ms給業(yè)務(wù)處理留夠時(shí)間二是配合使用max.poll.records把單次poll返回的消息數(shù)量從默認(rèn)的500條往下降。實(shí)踐里我更推薦后者把max.poll.records調(diào)成100左右既控制單次處理時(shí)長(zhǎng)又不至于讓poll頻率過(guò)高。很多人寧愿堆線程也懶得拉這兩個(gè)參數(shù)但真相是這兩個(gè)參數(shù)直接決定消費(fèi)端穩(wěn)定性。5.3 Offset提交位置自動(dòng)提交的坑和手動(dòng)提交的優(yōu)雅消費(fèi)完一條消息后Consumer需要把Offset提交給Broker。自動(dòng)提交enable.auto.committrue默認(rèn)每5秒提交一次auto.commit.interval.ms5000。自動(dòng)提交的問(wèn)題在于它是定時(shí)提交不是處理完就提交。如果在兩次提交之間Consumer宕機(jī)重啟后它會(huì)從上一次提交的位置重新消費(fèi)這一段必然產(chǎn)生重復(fù)消息。在大多數(shù)允許至少一次語(yǔ)義的業(yè)務(wù)里重復(fù)消費(fèi)可以靠?jī)绲认M(fèi)來(lái)解決——也就是消費(fèi)邏輯本身具備處理重復(fù)數(shù)據(jù)的能力。但如果業(yè)務(wù)對(duì)重復(fù)敏感比如扣款、發(fā)券就需要手動(dòng)提交Offset并且嚴(yán)格保證拉取一批消息→處理完這批→再提交這批的Offset。這里最容易被忽略的細(xì)節(jié)是提交的Offset應(yīng)該是本批最后一條消息的下一條位置而不是當(dāng)前已經(jīng)拉取到的位置。因?yàn)槿绻M(fèi)者在處理中途掛了下一次從已提交位置開始會(huì)重復(fù)整個(gè)未完成批次而如果你提交得太靠前會(huì)造成丟失提交得太靠后會(huì)造成跳過(guò)。實(shí)際代碼里我用的是處理完本批后將offset參數(shù)設(shè)為nextOffset的方式來(lái)避免這個(gè)坑。6. 存儲(chǔ)層的時(shí)間輪盤Segment、保留策略與Compact CompactionKafka的存儲(chǔ)層設(shè)計(jì)是被很多人忽略但性價(jià)比極高的一塊。你把Topic當(dāng)成一個(gè)永遠(yuǎn)增長(zhǎng)的大目錄但物理上它不能無(wú)限長(zhǎng)必須有一套清理機(jī)制。Kafka提供兩種清理策略delete按時(shí)間或大小刪除和compact按key保留最新值。6.1 從文件名看懂Segment的滾動(dòng)機(jī)制分區(qū)目錄里那些xxx.log文件門口都有一個(gè)xxx.index稀疏索引和xxx.timeindex時(shí)間索引。index文件記錄Offset和物理文件位置的映射關(guān)系用于快速定位timeindex則用于按時(shí)間戳查找消息。這兩個(gè)索引不是逐條建立而是稀疏索引每隔固定字節(jié)數(shù)建立一條映射節(jié)省內(nèi)存。日志文件的滾動(dòng)由log.segment.bytes和log.roll.hours兩個(gè)參數(shù)控制達(dá)到1GB或超過(guò)一定時(shí)長(zhǎng)就滾動(dòng)生成新Segment。滾動(dòng)的好處是舊的Segment可以被安全清理不會(huì)影響正在寫入的最新Segment。當(dāng)你執(zhí)行刪除Topic數(shù)據(jù)之類的操作本質(zhì)上是讓Kafka刪除整個(gè)分區(qū)目錄而不是逐條刪消息這也是它能快速清理海量數(shù)據(jù)的原因。6.2 retention策略7天不是唯一答案按場(chǎng)景調(diào)默認(rèn)的log.retention.hours168對(duì)大部分業(yè)務(wù)夠用但要注意兩組場(chǎng)景的取舍。一是高吞吐日志型Topic比如用戶行為埋點(diǎn)數(shù)據(jù)量極大長(zhǎng)時(shí)間保留會(huì)占滿磁盤可以調(diào)到24小時(shí)甚至6小時(shí)。二是金融交易、審計(jì)鏈路合規(guī)要求保留一年以上就得把保留時(shí)間拉長(zhǎng)同時(shí)確保磁盤容量按峰值寫入量乘以保留天數(shù)來(lái)規(guī)劃。我在某團(tuán)隊(duì)做容量評(píng)估時(shí)他們一個(gè)埋點(diǎn)Topic每天寫入1.5TB保留7天需要至少11TB磁盤空間而他們集群?jiǎn)喂?jié)點(diǎn)只有2TB。最后方案是Topic按天分區(qū)、平時(shí)只保留3天、離線任務(wù)在消息落入Kafka后同步把數(shù)據(jù)轉(zhuǎn)存到對(duì)象存儲(chǔ)里。保留策略要的是夠用留一件備份副本在便宜存儲(chǔ)而不是一味拉長(zhǎng)Kafka內(nèi)的保留時(shí)間。6.3 compact策略只留每個(gè)key的最新值如果你維護(hù)的不是事件流而是狀態(tài)快照比如用戶畫像的當(dāng)前版本、配置項(xiàng)的最新值那么delete策略就不合適了因?yàn)榕f版本消息已經(jīng)沒(méi)用了留著只是占空間。這時(shí)啟用log.cleanup.policycompact。壓縮的過(guò)程是由后臺(tái)的Cleaner線程完成的它掃描日志對(duì)于相同key的消息只保留最新的一條。注意壓縮是惰性的不是實(shí)時(shí)清理而且壓縮不能精確控制某條消息什么時(shí)候被清理。所以如果你需要按key唯一且最新通常還得配合外部的狀態(tài)存儲(chǔ)比如用Kafka Streams的RocksDB狀態(tài)存儲(chǔ)來(lái)解決而不是指望Kafka的Compact能給你實(shí)時(shí)秒查的效果。我第一次用Compact時(shí)指望它做實(shí)時(shí)配置中心結(jié)果發(fā)現(xiàn)配置變更后舊值還殘留了好幾分鐘。后來(lái)才明白Compact只保證壓縮完成之后的狀態(tài)不保證壓縮的時(shí)間點(diǎn)。用它做長(zhǎng)期存儲(chǔ)的尾部?jī)?yōu)化可以但實(shí)時(shí)一致性還是要靠應(yīng)用層自己設(shè)計(jì)。7. 性能神話背后順序?qū)?、?yè)緩存與零拷貝Kafka單Broker能支撐每秒幾十萬(wàn)甚至上百萬(wàn)條消息的寫入很多人都聽說(shuō)過(guò)這個(gè)數(shù)字但少有人真正理解它是怎么做到的。拆開來(lái)看主要是三個(gè)設(shè)計(jì)共同撐起了這個(gè)性能天花板。7.1 順序?qū)懘疟PSSD都未必干得過(guò)順序?qū)懕P傳統(tǒng)消息隊(duì)列把消息隨機(jī)落到內(nèi)存或者隨機(jī)寫文件隨機(jī)寫性能極差。Kafka把每個(gè)分區(qū)在磁盤上的目錄設(shè)計(jì)成一個(gè)順序追加的日志新消息永遠(yuǎn)寫到文件末尾。順序?qū)懕P在機(jī)械硬盤上可以達(dá)到每秒200MB以上在SSD上更是能輕松跑滿接口帶寬而隨機(jī)寫的速率可能只有它的十分之一甚至更低。這里有個(gè)反直覺的點(diǎn)很多人覺得外加一層內(nèi)存緩存才是高性能方案Kafka卻反其道而行之直接寫磁盤。因?yàn)轫樞驅(qū)憶](méi)有隨機(jī)尋道寫盤不但不慢反而規(guī)避了Java堆內(nèi)存的管理與GC開銷。用日志做存儲(chǔ)介質(zhì)讓Kafka不需要復(fù)雜的隨機(jī)讀寫索引簡(jiǎn)化了整體設(shè)計(jì)。7.2 頁(yè)緩存操作系統(tǒng)替你緩存了熱點(diǎn)數(shù)據(jù)Kafka寫入不直接調(diào)用fsync刷盤而是先寫入操作系統(tǒng)頁(yè)緩存Page Cache由操作系統(tǒng)在合適時(shí)機(jī)異步刷盤。消費(fèi)者讀數(shù)據(jù)時(shí)如果數(shù)據(jù)還在頁(yè)緩存中根本不會(huì)發(fā)生磁盤I/O直接走內(nèi)存。這個(gè)特性解釋了一個(gè)常見的現(xiàn)象你剛生產(chǎn)了一批消息馬上消費(fèi)它速度極快幾乎感覺不到磁盤的存在但隔了一天再去消費(fèi)舊數(shù)據(jù)速度就明顯降下來(lái)了因?yàn)轫?yè)緩存已經(jīng)淘汰掉了那些老數(shù)據(jù)真正觸發(fā)了磁盤讀。這套機(jī)制和Redis緩存熱數(shù)據(jù)是一樣的思路只是Kafka把這一層完全交給了操作系統(tǒng)。7.3 零拷貝Sendfile消費(fèi)者讀取時(shí)省掉兩次內(nèi)存復(fù)制普通的數(shù)據(jù)讀流程磁盤→內(nèi)核Buffer→用戶空間Buffer→socket內(nèi)核Buffer→網(wǎng)卡。這里涉及四次上下文切換和兩次內(nèi)存復(fù)制。Kafka在消費(fèi)者讀取時(shí)使用sendfile系統(tǒng)調(diào)用數(shù)據(jù)直接從內(nèi)核Buffer進(jìn)入到網(wǎng)卡發(fā)送隊(duì)列用戶空間完全碰不到數(shù)據(jù)。這就叫零拷貝。零拷貝帶來(lái)的性能提升在消費(fèi)大消息體時(shí)非常明顯。用同樣的Topic、同樣的分區(qū)數(shù)對(duì)比壓測(cè)打開零拷貝的consumer吞吐量通常提升15%~25%CPU占用率也明顯更低。這個(gè)機(jī)制不需要業(yè)務(wù)側(cè)改任何代碼開箱即得。7.4 一份夠用的生產(chǎn)配置基線最后給一份最基礎(chǔ)的參數(shù)基線覆蓋了小規(guī)模集群3~5個(gè)Broker到中等規(guī)模10~20個(gè)Broker的生產(chǎn)環(huán)境。YMMV但大致方向不會(huì)錯(cuò)。參數(shù)推薦設(shè)置說(shuō)明num.partitions業(yè)務(wù)寫入峰值的1/2左右分區(qū)數(shù)不是越多越好過(guò)多會(huì)放大Rebalance成本replication.factor3保證一個(gè)Broker掛掉不影響可用性min.insync.replicas2和acksall配合使用才真正可靠log.retention.hours業(yè)務(wù)合規(guī)要求默認(rèn)168小時(shí)金融場(chǎng)景可提高到720batch.size32KB~64KB高吞吐場(chǎng)景調(diào)大linger.ms5~10批量攢發(fā)調(diào)吞吐enable.idempotencetrueProducer冪等防重防亂序max.poll.records100~200控制單次處理時(shí)長(zhǎng)防誤判max.poll.interval.ms與單批處理耗時(shí)的3倍設(shè)太小會(huì)踢出組設(shè)太大Rebalance感知慢session.timeout.ms10s左右配套心跳間隔3s心跳和會(huì)話超時(shí)的黃金比例這些參數(shù)你不需要永遠(yuǎn)不變但它是你知道該往哪個(gè)方向調(diào)的起點(diǎn)。調(diào)整之后務(wù)必用生產(chǎn)流量或壓測(cè)腳本驗(yàn)證不要只靠感覺。我在實(shí)際項(xiàng)目中最大的體會(huì)是Kafka的基礎(chǔ)架構(gòu)并不復(fù)雜復(fù)雜的是每一個(gè)機(jī)制都互相牽連——改了Producer的linger.ms會(huì)影響吞吐改了Consumer的max.poll.records會(huì)影響Rebalance頻率改了Topic的partitions會(huì)影響歷史消息的順序保證動(dòng)了任何一個(gè)開關(guān)都牽一發(fā)動(dòng)全身。給你的最后一條建議別急著改參數(shù)先確保你的腦海里有一張完整的存儲(chǔ)模型圖再去動(dòng)任何配置。如果你現(xiàn)在只能記住一件事那就記住——Partition是有序日志Offset是進(jìn)度書簽ISR是可靠底線的守衛(wèi)其他的翻文檔就行。