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