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