給赫茲威客項(xiàng)目準(zhǔn)備測(cè)試環(huán)境那段時(shí)間我一直在找一個(gè)既貼近真實(shí)集群、又不用真開三臺(tái)服務(wù)器的 Kafka 部署方式。直接裝單機(jī)版吧Topic 的分區(qū)、副本、消費(fèi)者組這些分布式語義都驗(yàn)證不到位真去搭三節(jié)點(diǎn)集群資源成本和維護(hù)成本對(duì)測(cè)試環(huán)境來說又明顯超標(biāo)。后來我理清思路把 Kafka 跑成“偽分布式”——在一臺(tái)機(jī)器上啟動(dòng)多個(gè)進(jìn)程來模擬多節(jié)點(diǎn)集群再把配置、驗(yàn)證、排障鏈路完整走一遍很多問題在動(dòng)手之前就已經(jīng)清楚了。這篇就把這套方案完整寫出來包括新版 KRaft 模式、經(jīng)典 ZooKeeper 模式、同一臺(tái)機(jī)器上模擬多 Broker、可視化工具連接、常見報(bào)錯(cuò)排查以及 Spring Boot 對(duì)接的最小配置。1. 偽分布式到底是什么先搞清楚它和單機(jī)、真集群的邊界很多剛接觸 Kafka 的人會(huì)把“單機(jī)版”和“偽分布式”混為一談這在測(cè)試場(chǎng)景里其實(shí)會(huì)造成很嚴(yán)重的誤判。單機(jī)部署通常指只啟動(dòng)一個(gè) broker 進(jìn)程而偽分布式是在同一臺(tái)物理機(jī)上啟動(dòng)多個(gè) broker/controller 進(jìn)程模擬出多個(gè)節(jié)點(diǎn)同時(shí)工作的效果。它跟真正的分布式集群之間的差別就好比“單人劇組在同一個(gè)攝影棚拍完所有外景”和“多個(gè)拍攝組在不同城市實(shí)地取景”的區(qū)別——前者能拍完但拍不出真實(shí)外景的天氣、光線和網(wǎng)絡(luò)延遲。1.1 單機(jī)、偽分布式、真集群三個(gè)概念的差異為了不繞彎子我先用一張表把三種形式的邊界劃清楚部署形態(tài)進(jìn)程數(shù)量網(wǎng)絡(luò)拓?fù)溥m合場(chǎng)景單機(jī)1 個(gè) broker本機(jī)回環(huán)驗(yàn)證 API、跑通代碼、學(xué)習(xí)基礎(chǔ)概念偽分布式多個(gè) broker / controller同一臺(tái)機(jī)器不同端口測(cè)試分區(qū)副本、消費(fèi)組、故障轉(zhuǎn)移邏輯真集群多個(gè) broker多臺(tái)機(jī)器真實(shí)網(wǎng)絡(luò)壓測(cè)、高可用演練、生產(chǎn)前驗(yàn)證為什么測(cè)試環(huán)境更適合偽分布式因?yàn)槟阏嬲?yàn)證的并不是 Kafka 本身能不能啟動(dòng)而是你的 Topic 數(shù)據(jù)分布策略、消費(fèi)者組在 broker 宕機(jī)后的 rebalance 行為、副本同步等分布式特性。這些特性只需要多個(gè)進(jìn)程就能觸發(fā)不需要真的跨機(jī)房。1.2 偽分布式測(cè)試能驗(yàn)證到什么程度我實(shí)測(cè)下來偽分布式可以覆蓋以下場(chǎng)景多分區(qū)消息路由producer 按 key 或輪詢寫入不同分區(qū)、生產(chǎn)副本 ISR 收縮與恢復(fù)、消費(fèi)者組內(nèi)再均衡、手動(dòng)提交 offset 以及重復(fù)消費(fèi)問題的模擬。這些在單機(jī)環(huán)境下完全暴露不出來。但它也有天然遮蔽層同一臺(tái)機(jī)器上的進(jìn)程共享 CPU 和內(nèi)存無法模擬真實(shí)網(wǎng)絡(luò)分區(qū)、磁盤故障或機(jī)房斷電。如果你要做的是故障演練偽分布式只能騙過邏輯層騙不過物理層這一點(diǎn)要心里有數(shù)后面也少踩坑。1.3 架構(gòu)選型Zookeeper 還是 KRaft早期版本必須依賴 ZooKeeper 管理元數(shù)據(jù)所以很多老教程的偽分布式都要先起一個(gè) ZK 再起 Kafka。但從 Kafka 2.8 引入 KRaft 模式開始Kafka 可以不再依賴 ZK3.3 以后 KRaft 已經(jīng)可以作為新集群的生產(chǎn)模式使用4.0 更是徹底移除了 ZK 相關(guān)代碼。對(duì)于現(xiàn)在的新項(xiàng)目尤其是本地測(cè)試我建議直接用 KRaft。它少一個(gè)進(jìn)程、少一層元數(shù)據(jù)同步延遲配置也簡(jiǎn)單不少?？紤]到很多生產(chǎn)環(huán)境還在跑舊版本、網(wǎng)上大量教程還是 ZK 模式我還是會(huì)把兩種方式都寫出來你可以按實(shí)際需求選擇。2. 環(huán)境準(zhǔn)備JDK、二進(jìn)制包和主機(jī)規(guī)劃里容易被忽略的細(xì)節(jié)我看到不少人的 Kafka 啟動(dòng)失敗并不是寫錯(cuò)了配置而是環(huán)境準(zhǔn)備階段就出了問題。這些問題通常很隱蔽基礎(chǔ)到大家都默認(rèn)“我不會(huì)犯”但實(shí)際排查起來反而最耗時(shí)間。2.1 JDK 版本不匹配Kafka 是用 Java 寫的對(duì) JDK 版本有明確要求。以 Kafka 3.x 為例一般要求 Java 8 或 11部分新版本需要 Java 17。我見過有人在 JDK 8 環(huán)境下直接跑 Kafka 3.6啟動(dòng)時(shí)會(huì)拋 UnsupportedClassVersionError日志里打了一段 class file version 不支持的報(bào)錯(cuò)。建議在啟動(dòng)前先確認(rèn)java -version實(shí)測(cè)中最穩(wěn)的是 JDK 11 配合 Kafka 3.5/3.6JDK 17 配合更新的版本也沒問題。2.2 二進(jìn)制包與目錄規(guī)劃Kafka 官方二進(jìn)制包解壓后是一個(gè)完整的目錄結(jié)構(gòu)包含 bin、config、libs 等子目錄。需要注意兩個(gè)目錄一個(gè)是解壓根目錄一個(gè)是數(shù)據(jù)目錄。默認(rèn)配置里 log.dirs 指向 /tmp/kafka-logs經(jīng)典模式或 /tmp/kraft-combined-logsKRaft 模式如果你不修改重啟機(jī)器數(shù)據(jù)就沒了而且測(cè)試中切換配置時(shí)容易遺留舊元數(shù)據(jù)導(dǎo)致后續(xù)啟動(dòng)報(bào)錯(cuò)。我的習(xí)慣是專門建一個(gè)目錄比如 /data/kafka把所有測(cè)試過程產(chǎn)生的日志和數(shù)據(jù)統(tǒng)一放在那里方便清理和備份。2.3 端口與主機(jī)名規(guī)劃偽分布式的端口規(guī)劃很重要。常見的規(guī)劃是進(jìn)程端口ZooKeeper經(jīng)典模式2181Kafka ControllerKRaft 專用9093Broker 19092Broker 2偽集群9094Broker 3偽集群9095另外建議不要全程用 localhost。雖然本機(jī)測(cè)試都一樣但你會(huì)遇到 advertised.listeners 配置問題這個(gè)問題在 Docker 或者其他容器環(huán)境里會(huì)無限放大。我更推薦先在 /etc/hosts 里加一行映射127.0.0.1 kafka1后續(xù)配置里統(tǒng)一用 kafka1 而不是 localhost這樣從偽分布式遷移到真實(shí)多機(jī)集群時(shí)只需要把 IP 改掉配置結(jié)構(gòu)不用動(dòng)。3. 用 KRaft 模式搭建無 Zookeeper 的偽分布式 Kafka如果你不想再伺候 ZooKeeper這條路徑最合適。整個(gè)流程就三件事生成集群 ID、格式化存儲(chǔ)目錄、啟動(dòng)服務(wù)。但每一步都有關(guān)鍵細(xì)節(jié)操作錯(cuò)了不會(huì)立刻報(bào)錯(cuò)而是下次啟動(dòng)時(shí)給你埋雷。3.1 KRaft 模式的核心邏輯在 KRaft 模式里每個(gè)節(jié)點(diǎn)可以只做 broker也可以同時(shí)扮演 controller甚至同一個(gè)進(jìn)程既能管元數(shù)據(jù)又能處理消息讀寫。對(duì)測(cè)試環(huán)境來說最省事的組合是單進(jìn)程同時(shí)擔(dān)任 broker 和 controller也就是合并節(jié)點(diǎn)。當(dāng)你需要模擬多 Broker 時(shí)可以只讓一個(gè)進(jìn)程做 controller其他進(jìn)程做純 broker結(jié)構(gòu)上會(huì)更清晰后面第 5 章我會(huì)專門講。3.2 生成集群 ID 并格式化存儲(chǔ)目錄進(jìn)入 Kafka 解壓根目錄后先執(zhí)行KAFKA_CLUSTER_ID$(bin/kafka-storage.sh random-uuid) echo $KAFKA_CLUSTER_ID這個(gè) ID 相當(dāng)于集群的唯一標(biāo)識(shí)所有節(jié)點(diǎn)必須使用同一個(gè) ID 才能組成集群。拿到 ID 之后格式化存儲(chǔ)在 log.dirs 里的元數(shù)據(jù)目錄bin/kafka-storage.sh format -t $KAFKA_CLUSTER_ID -c config/kraft/server.properties注意這一步是破壞性操作。如果你在同一個(gè)目錄上重復(fù)執(zhí)行格式化上一次集群的元數(shù)據(jù)會(huì)被清空所以測(cè)試中切換不同 Kafka 版本或配置時(shí)要記得清空 log.dirs 再格式化否則會(huì)出現(xiàn)各種“莫名其妙”的元數(shù)據(jù)錯(cuò)亂。3.3 修改單節(jié)點(diǎn)配置config/kraft/server.properties 中最關(guān)鍵的幾項(xiàng)是這樣的我按最小可運(yùn)行配置裁剪過process.rolesbroker,controller node.id1 controller.quorum.voters1kafka1:9093 listenersPLAINTEXT://:9092,CONTROLLER://:9093 inter.broker.listener.namePLAINTEXT advertised.listenersPLAINTEXT://kafka1:9092 controller.listener.namesCONTROLLER listener.security.protocol.mapCONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT log.dirs/data/kafka/kraft-combined-logs num.partitions1 offsets.topic.replication.factor1 transaction.state.log.replication.factor1簡(jiǎn)單解釋一下process.roles 決定了這個(gè)進(jìn)程干哪些活broker,controller 表示兩者都干node.id 是節(jié)點(diǎn)唯一標(biāo)識(shí)controller.quorum.voters 把控制器參與者列表寫清楚。advertised.listeners 是給客戶端看的地址如果你用 localhost 啟動(dòng)客戶端就連不上正常服務(wù)這個(gè)坑在偽分布式里非常常見。3.4 啟動(dòng)與驗(yàn)證配置沒問題就可以啟動(dòng)了bin/kafka-server-start.sh config/kraft/server.properties看到類似 “Kafka Server started” 的日志后再開一個(gè)終端執(zhí)行bin/kafka-broker-api-versions.sh --bootstrap-server kafka1:9092如果返回一堆 API 版本信息說明 broker 存活了。如果你啥也沒看到或者卡住多半還是 advertised.listeners 不對(duì)。4. 經(jīng)典 ZooKeeper 模式的啟動(dòng)順序錯(cuò)一步整個(gè)集群都起不來老版本 Kafka 還在生產(chǎn)環(huán)境里大批量存在尤其是企業(yè)內(nèi)部維護(hù)了很久的集群基本都是 ZK 模式。即使你平時(shí)用 KRaft也一定要會(huì) ZK 模式的基本操作因?yàn)槟闳e人團(tuán)隊(duì)做支持時(shí)大概率碰到的就是它。4.1 為什么老教程都在強(qiáng)調(diào)“先起 ZK 再起 Kafka”早期 Kafka 的集群元數(shù)據(jù)、broker 注冊(cè)、Controller 選舉、Topic 配置等全部存在 ZooKeeper 上Kafka 啟動(dòng)時(shí)要向 ZK 注冊(cè)自己。如果你先起 Kafka它連不上 ZK 就會(huì)反復(fù)重試甚至直接退出等 ZK 起來了再手動(dòng)啟動(dòng) Kafka 才正常。很多老工程師把“先 ZK 后 Kafka”當(dāng)作肌肉記憶根因就在這里。4.2 修改兩個(gè)配置文件ZooKeeper 的配置在 config/zookeeper.properties測(cè)試環(huán)境里通常只要數(shù)據(jù)目錄正確即可dataDir/data/kafka/zookeeper clientPort2181Kafka 的經(jīng)典配置在 config/server.properties以下內(nèi)容必須關(guān)注broker.id0 listenersPLAINTEXT://:9092 advertised.listenersPLAINTEXT://kafka1:9092 log.dirs/data/kafka/kafka-logs zookeeper.connectkafka1:2181 offsets.topic.replication.factor1 transaction.state.log.replication.factor1 transaction.state.log.min.isr14.3 啟動(dòng)順序與驗(yàn)證嚴(yán)格按照下面的順序操作bin/zookeeper-server-start.sh config/zookeeper.properties看到 ZooKeeper 監(jiān)聽 2181 端口后再啟動(dòng) Kafkabin/kafka-server-start.sh config/server.properties驗(yàn)證仍然可以用 kafka-broker-api-versions.sh。如果 Kafka 在啟動(dòng)日志里反復(fù)出現(xiàn) Unable to connect to zookeeper 之類的字樣不要硬等先回去看 ZK 是否真的起來了、2181 端口是否被占用。4.4 Docker 里跑舊版本的常見坑很多人圖省事直接用 docker run 拉鏡像跑。這里有個(gè)隱蔽問題有些鏡像把 ZK 和 Kafka 進(jìn)程合在一起但健康檢查邏輯寫得不嚴(yán)謹(jǐn)有些鏡像默認(rèn)配置里的 advertised.listeners 寫的是容器 ID宿主機(jī)上的客戶端根本連不上。所以如果你在 Docker 里跑經(jīng)典模式盡量用官方鏡像或明確區(qū)分 KAFKA_ADVERTISED_LISTENERS 的環(huán)境變量把宿主可視地址手動(dòng)指定清楚。這個(gè)坑跟聚類方式無關(guān)純粹是容器網(wǎng)絡(luò)模型導(dǎo)致的遇到時(shí)報(bào)錯(cuò)大多集中在連接超時(shí)或 metadata 拉取失敗。5. 一臺(tái)機(jī)器模擬多 Broker真正的偽集群玩法單節(jié)點(diǎn)跑通只是開始偽集群的價(jià)值要在多個(gè) Broker 同時(shí)運(yùn)行的時(shí)候才真正體現(xiàn)出來。這一章我用 KRaft 模式演示因?yàn)槟悴恍枰獮榱硕鄠€(gè) broker 再單獨(dú)跑多個(gè) ZK 實(shí)例。5.1 偽集群規(guī)劃假設(shè)我在一臺(tái)機(jī)器上模擬 3 個(gè)節(jié)點(diǎn)1 個(gè) controller 3 個(gè) broker。為了簡(jiǎn)單我把 controller 和 broker1 合并成一個(gè)節(jié)點(diǎn)再單獨(dú)開 broker2、broker3。三份配置的核心區(qū)別在下面這張表配置項(xiàng)broker1合并 Controllerbroker2broker3node.id123process.rolesbroker,controllerbrokerbrokerlistenersPLAINTEXT://:9092,CONTROLLER://:9093PLAINTEXT://:9094PLAINTEXT://:9095advertised.listenersPLAINTEXT://kafka1:9092PLAINTEXT://kafka1:9094PLAINTEXT://kafka1:9095controller.quorum.voters1kafka1:90931kafka1:90931kafka1:9093log.dirs/data/kafka/broker1/data/kafka/broker2/data/kafka/broker3注意三份配置必須使用同一個(gè)集群 ID 格式化過否則它們互相不認(rèn)會(huì)形成各自獨(dú)立的“單節(jié)點(diǎn)集群”。5.2 啟動(dòng)三個(gè) Broker 并驗(yàn)證副本分配先格式化存儲(chǔ)目錄這里假設(shè)集群 ID 已經(jīng)生成并存在變量 $KAFKA_CLUSTER_ID 里bin/kafka-storage.sh format -t $KAFKA_CLUSTER_ID -c config/kraft/server-1.properties bin/kafka-storage.sh format -t $KAFKA_CLUSTER_ID -c config/kraft/server-2.properties bin/kafka-storage.sh format -t $KAFKA_CLUSTER_ID -c config/kraft/server-3.properties bin/kafka-server-start.sh config/kraft/server-1.properties bin/kafka-server-start.sh config/kraft/server-2.properties bin/kafka-server-start.sh config/kraft/server-3.properties等三個(gè)日志都輸出 started 之后創(chuàng)建一個(gè)有 3 個(gè)分區(qū)、2 個(gè)副本的 Topicbin/kafka-topics.sh --bootstrap-server kafka1:9092 --create --topic test-cluster --partitions 3 --replication-factor 2 bin/kafka-topics.sh --bootstrap-server kafka1:9092 --describe --topic test-clusterdescribe 的輸出里會(huì)看到每個(gè)分區(qū)的 Leader 和 Replicas 分布在不同的 broker 上這就說明偽集群真的“合體”了。5.3 偽集群的局限停一個(gè) Broker 看會(huì)發(fā)生什么你可以在運(yùn)行中 CtrlC 停掉 broker3再執(zhí)行 describe會(huì)看到相應(yīng)分區(qū) leader 發(fā)生切換ISR 列表收縮。這個(gè)行為能驗(yàn)證副本故障轉(zhuǎn)移邏輯。但它只能驗(yàn)證“進(jìn)程掛掉”這一種故障同一臺(tái)機(jī)器上的內(nèi)存溢出、磁盤 IO 毛刺、網(wǎng)絡(luò)中斷都無法模擬因?yàn)樗羞M(jìn)程共用一套物理資源。測(cè)試結(jié)果只能作為功能驗(yàn)證不能作為高可用性能指標(biāo)。6. 連接驗(yàn)證與可視化確認(rèn)消息真的被生產(chǎn)并消費(fèi)了服務(wù)起來了Topic 也建了下一步就是用真實(shí)消息把鏈路跑通。命令行三件套是基礎(chǔ)可視化工具是效率工具兩者結(jié)合能快速定位大多數(shù)測(cè)試問題。6.1 命令行三板斧先寫一條消息進(jìn)去bin/kafka-console-producer.sh --bootstrap-server kafka1:9092 --topic test-cluster hello kafka test message再開一個(gè)消費(fèi)者bin/kafka-console-consumer.sh --bootstrap-server kafka1:9092 --topic test-cluster --from-beginning注意加了 --from-beginning 才會(huì)從頭消費(fèi)已有消息不加的話消費(fèi)者加入后再生產(chǎn)的新消息才能看到因?yàn)樗?offset 默認(rèn)從 latest 開始。測(cè)試中經(jīng)常有人問“為什么我剛生產(chǎn)的消息沒被消費(fèi)到”十有八九是沒加這個(gè)參數(shù)然后誤以為集群有問題。6.2 Offset Explorer 連接本地單機(jī) Kafka 的操作細(xì)節(jié)命令行的體驗(yàn)有限我更推薦用可視化工具觀察集群結(jié)構(gòu)。Offset Explorer也就是老牌的 Kafka Tool是不少人習(xí)慣的工具但很多人不知道新版怎么連本地 Kafka。方法很簡(jiǎn)單啟動(dòng)后點(diǎn) Add ClusterCluster name 隨便填然后在 Properties 面板里選擇 Kafka 集群類型ZooKeeper Host 那一欄只適合老版本當(dāng)代 Kafka 尤其是 KRaft 模式必須在 Bootstrap servers 里填 kafka1:9092。填完之后點(diǎn) Test Connection看到成功提示再點(diǎn) OK。這里有個(gè)細(xì)節(jié)如果你之前用 localhost 啟動(dòng)且 advertised.listeners 也寫 localhost那第一步填 localhost 也沒問題一旦你改了主機(jī)名映射所有客戶端、工具包括 Offset Explorer 里的地址都要跟著改否則連接失敗。如果沒有 Setup Offset Explorer 也行Kafdrop、Kafka UI 這類社區(qū)工具通過 Docker 啟動(dòng)也很方便核心原理一致都是連 bootstrap server。6.3 用命令行檢查消費(fèi)者組和 Lag在偽集群場(chǎng)景里消費(fèi)組狀態(tài)和 Lag 是最值得觀察的指標(biāo)。先用下面的命令列出消費(fèi)者組bin/kafka-consumer-groups.sh --bootstrap-server kafka1:9092 --list然后查看某個(gè)組的具體情況bin/kafka-consumer-groups.sh --bootstrap-server kafka1:9092 --describe --group my-group輸出會(huì)顯示每個(gè)分區(qū)的 Current-offset、Log-end-offset 和 Lag。Lag 一直增長(zhǎng)說明消費(fèi)速度跟不上生產(chǎn)速度這時(shí)候你要排查的不是 Kafka而是消費(fèi)者邏輯或 poll 參數(shù)。這個(gè)點(diǎn)非常重要很多人一看到“消息延遲”就去調(diào) broker 配置方向完全錯(cuò)了。7. 本地測(cè)試最常見的幾個(gè)報(bào)錯(cuò)完整排查鏈路偽分布式測(cè)試環(huán)境里錯(cuò)誤信息本身往往很簡(jiǎn)短但背后原因卻是五花八門。以下是我踩坑最多、也是網(wǎng)上經(jīng)常被問到的三類問題。7.1 Error while fetching metadata with correlation id這個(gè)報(bào)錯(cuò)幾乎人人都遇到過典型表現(xiàn)是 producer 或消費(fèi)者啟動(dòng)后日志里刷出 Error while fetching metadata with correlation id 1。嚴(yán)格來說它并不是一個(gè)“故障”而是客戶端向 bootstrap server 請(qǐng)求元數(shù)據(jù)失敗/超時(shí)之后的統(tǒng)一提示。我的排查鏈路是順序執(zhí)行以下五步先確認(rèn) broker 進(jìn)程真的活著jps 或 ps -ef | grep kafka。確認(rèn)端口監(jiān)聽正常netstat -an | grep 9092本地回環(huán)地址是否監(jiān)聽。確認(rèn)客戶端和 broker 之間的地址可達(dá)ping kafka1或直接用 nc -vz kafka1 9092。查看 advertised.listeners 是否指向客戶端可見地址。這是最常見的原因尤其在容器環(huán)境里broker 注冊(cè)的是容器內(nèi) IP宿主機(jī)的客戶端當(dāng)然連不上。確認(rèn)客戶端用的 bootstrap server 地址是同一個(gè)不是被防火墻或代理劫持。按這個(gè)順序走完絕大多數(shù) metadata 問題都能定位。7.2 Cluster authorization failed這個(gè)報(bào)錯(cuò)和 ACL 強(qiáng)相關(guān)。Kafka 默認(rèn)情況下如果不配置 ACL 相關(guān)監(jiān)聽器并不會(huì)強(qiáng)制鑒權(quán)但如果你引入了某些管理工具、鏡像或自定義配置打開了 authorizer 又不小心把 allow.everyone.if.no.acl.found 設(shè)成了 false導(dǎo)致沒有 ACL 的用戶全被拒絕。測(cè)試環(huán)境里最直接的恢復(fù)辦法是在 server.properties或 Docker 環(huán)境變量里設(shè)置allow.everyone.if.no.acl.foundtrue并重啟 broker。如果你的目的是測(cè)試權(quán)限控制那就反過來顯式配置 super.users然后通過 kafka-acls.sh 給指定用戶添加權(quán)限。注意Cluster authorization failed 消息里通常不會(huì)告訴你哪個(gè)用戶被拒所以一旦出現(xiàn)這個(gè)錯(cuò)優(yōu)先檢查配置里是否引入了 authorizer 或安全協(xié)議。7.3 消費(fèi)延遲 30 分鐘這類問題怎么在測(cè)試?yán)飶?fù)現(xiàn)和排查熱搜詞里“kafka 如何延遲30分鐘消費(fèi)”這種提問嚴(yán)格說不是配置項(xiàng)能一步搞定的。它可能有幾種形態(tài)一是消費(fèi)者進(jìn)程被掛起 30 分鐘后才去拉消息二是生產(chǎn)者把消息帶了一個(gè) 30 分鐘后的時(shí)間戳消費(fèi)端按業(yè)務(wù)時(shí)間過濾三是消費(fèi)組長(zhǎng)期 rebalance 不上導(dǎo)致消息在中間卡了 30 分鐘。在偽分布式環(huán)境里我建議把“延遲”拆開看如果只是延遲消費(fèi)可以在消費(fèi)者邏輯里主動(dòng) sleep或使用 KafkaConsumer 的 poll 超時(shí)控制來觀察消息何時(shí)被處理。如果是系統(tǒng)性的消費(fèi)滯后用 kafka-consumer-groups.sh --describe 觀察 Lag 增長(zhǎng)再檢查 max.poll.records 和 max.poll.interval.ms 是否太小。比如 max.poll.interval.ms 默認(rèn) 3000005 分鐘如果消費(fèi)者一次處理消息超過 5 分鐘就會(huì)被判定為離開消費(fèi)組觸發(fā) rebalance表現(xiàn)為“越處理越慢”。如果是生產(chǎn)者側(cè)追求低延遲可以關(guān)注 linger.ms 和 batch.size。測(cè)試時(shí)不要盲目調(diào)小 linger.ms因?yàn)檫@會(huì)犧牲批量效率壓測(cè)數(shù)據(jù)會(huì)非常難看。7.4 Spring Boot 接入偽分布式 Kafka 的最小配置偽分布式環(huán)境的另一個(gè)高頻用途是給 Spring Boot 項(xiàng)目提供本地消息隊(duì)列。網(wǎng)上搜“springboot kafka配置詳解”能出來一大堆文章但你要在本地跑通其實(shí)只需要在 application.yml 里配置最小項(xiàng)spring: kafka: bootstrap-servers: kafka1:9092 producer: key-serializer: org.apache.kafka.common.serialization.StringSerializer value-serializer: org.apache.kafka.common.serialization.StringSerializer consumer: group-id: demo-group key-deserializer: org.apache.kafka.common.serialization.StringDeserializer value-deserializer: org.apache.kafka.common.serialization.StringDeserializer auto-offset-reset: earliest然后注入 KafkaTemplate 即可Autowired private KafkaTemplateString, String kafkaTemplate; public void send(String topic, String message) { kafkaTemplate.send(topic, message); }這里必須強(qiáng)調(diào) bootstrap-servers 要和 broker 的 advertised.listeners 保持一致。你有多個(gè) Spring Boot 服務(wù)需要對(duì)接多個(gè) Kafka 地址時(shí)也可以配置多個(gè) KafkaTemplate但本地測(cè)試階段沒必要偽分布式環(huán)境同一個(gè) bootstrap 地址夠用了。8. 測(cè)試完事了說點(diǎn)偽分布式替代不了的事偽分布式幫我解決了很多“只想驗(yàn)證邏輯、不想租機(jī)器”的場(chǎng)景但它終究不是真正的分布式。如果你要測(cè)的是網(wǎng)絡(luò)抖動(dòng)下的客戶端重試、跨機(jī)房的副本同步延遲、大規(guī)模分區(qū)的性能瓶頸偽分布式給不了你任何可信數(shù)據(jù)。它最大的價(jià)值是在寫代碼和跑測(cè)試之間提供一個(gè)低成本驗(yàn)證層讓你在提交代碼之前把明顯的問題過濾掉。我在實(shí)際使用中形成的小習(xí)慣有幾個(gè)值得分享。一是把啟動(dòng)命令收進(jìn)腳本不要每次手動(dòng)開三個(gè)終端腳本里先檢查端口占用再啟動(dòng)日志統(tǒng)一重定向到文件這樣排查時(shí)直接看日志追問題。二是偽集群測(cè)試完務(wù)必清理 log.dirs否則下次換配置啟動(dòng)時(shí)殘留元數(shù)據(jù)會(huì)讓你產(chǎn)生“明明改好了為什么還報(bào)錯(cuò)”的錯(cuò)覺。三是所有配置里的主機(jī)名都統(tǒng)一替換成 /etc/hosts 里的映射不要一會(huì)兒 localhost 一會(huì)兒 kafka1工具和客戶端連接能少踩一半的坑。這套偽分布式方案后續(xù)如果還要擴(kuò)展方向有兩個(gè)一是把三個(gè) Broker 配置改成容器化編排用編排工具管理依賴和啟動(dòng)順序二是把消費(fèi)者組測(cè)試擴(kuò)展到多服務(wù)實(shí)例用真實(shí)業(yè)務(wù)代碼在偽集群上跑一遍完整的消息閉環(huán)。測(cè)試環(huán)境的復(fù)雜度應(yīng)該匹配你當(dāng)下要驗(yàn)證的問題過了那個(gè)臨界點(diǎn)第一時(shí)間遷移到真集群才算對(duì)項(xiàng)目負(fù)責(zé)。