有人問我Kafka到底難不難學(xué)。我的回答一直是環(huán)境搭建這一關(guān)過了后面就順了過不了后面一天到晚都在跟各種報錯打架。Kafka不是那種解壓就能跑的軟件它對操作系統(tǒng)、JDK版本、網(wǎng)絡(luò)配置、磁盤規(guī)劃都有要求任何一個環(huán)節(jié)不合適啟動時可能不報錯但生產(chǎn)環(huán)境一跑就出問題。這篇是Kafka學(xué)習(xí)系列的第二篇我默認(rèn)你已經(jīng)了解了Kafka的基本概念主題、分區(qū)、消費者組、副本這些如果你還不太清楚建議先看系列第一篇把核心概念過一遍。這篇的主要內(nèi)容很聚焦怎么把Kafka環(huán)境從零搭起來每一步該怎么做、為什么這么做、踩過哪些坑全部用實際操作的思路來講。我主要從三個場景來講單機開發(fā)環(huán)境搭建、三節(jié)點集群搭建、以及環(huán)境搭建過程中必踩的坑和排查思路。中間會穿插我在實際項目中總結(jié)的一些經(jīng)驗和教訓(xùn)比如版本怎么選、參數(shù)怎么調(diào)、磁盤怎么規(guī)劃這些常規(guī)文檔里不會細(xì)說的東西。1. 為什么先別急著裝Kafka組件架構(gòu)和版本選擇比下載更重要1.1 從單機玩具到分布式事實Kafka到底需要哪些組件很多人第一次搭Kafka環(huán)境下載完壓縮包就想著趕緊解壓、啟動、跑起來。但如果你對Kafka的運行機制沒有一個整體認(rèn)知后面配置參數(shù)時會非常迷茫出了問題也不知道從哪兒排查。Kafka本身是一個分布式消息系統(tǒng)它最少需要兩類角色才能完整跑起來一類是管理分布式協(xié)調(diào)狀態(tài)的組件另一類是真正存儲和轉(zhuǎn)發(fā)消息的Broker節(jié)點。在過去很長一段時間里這個協(xié)調(diào)組件就是ZooKeeper它負(fù)責(zé)保存Kafka的元數(shù)據(jù)信息包括主題列表、分區(qū)分配情況、消費者組進(jìn)度等。雖然從Kafka 2.8版本開始官方引入了KRaft模式把元數(shù)據(jù)管理從ZooKeeper剝離了但到目前為止ZooKeeper模式依然是大量線上環(huán)境的主流選擇尤其是很多公司內(nèi)部的存量集群一時半會兒遷不過去的。所以環(huán)境搭建這件事本質(zhì)上就是在你選擇的操作系統(tǒng)上把JDK、ZooKeeper如果用的話、Kafka Broker按正確的順序和配置部署好讓它們能互相通信、協(xié)同工作。這里還要特別提一個概念Client和Server要分清楚。Kafka的Server端是Broker集群Client端是生產(chǎn)者和消費者。你搭建的環(huán)境是Server端但驗證環(huán)境是否成功必須用Client端工具或?qū)懸欢未a來測試。很多人搭建完環(huán)境說不知道成功沒有那是因為只啟動了進(jìn)程并沒有實際發(fā)消息、收消息來做驗證。1.2 版本選擇陷阱2.x和3.x的差異不只是版本號Kafka的版本選擇是我見過的最容易讓人踩坑的地方?jīng)]有之一。你去看Kafka的Apache官網(wǎng)或者GitHub Releases頁面會發(fā)現(xiàn)同一時期有多個版本并存而且2.x版本和3.x版本不僅僅是數(shù)字上的差別架構(gòu)上都有了很大的變化。首先說一下版本號的規(guī)則。從Kafka 2.0開始Apache Kafka采用了新的版本命名方式比如2.13-3.6.0這樣的格式前面的2.13是Scala編譯版本后面的3.6.0才是Kafka的版本號。很多初學(xué)者看到2.13-3.6.0就以為這是Kafka 2.13是個舊版本實際上3.6.0才是真正的Kafka版本前面的2.13指的是用Scala 2.13編譯的。如果你下載的時候只看前半段數(shù)字很容易下載到不合適的構(gòu)建版本。然后是Kafka版本和生態(tài)組件版本之間的兼容性。比如你用Kafka 3.x配一個很老的ZooKeeper 3.4.x啟動的時候可能正常但運行一段時間會出現(xiàn)一些奇怪的連接超時或會話過期錯誤。反過來Kafka 2.x配太新的ZooKeeper也會遇到配置項不兼容的問題。我的建議是如果是學(xué)習(xí)或者做技術(shù)預(yù)研首選Kafka 3.x的最新穩(wěn)定版用KRaft模式或者ZooKeeper模式都可以但推薦先用ZooKeeper模式因為網(wǎng)上資料多遇到問題好搜索。如果是公司生產(chǎn)環(huán)境一定要先確認(rèn)公司已有的監(jiān)控體系、運維工具、客戶端版本是否兼容不要盲目上最新版。如果是給老項目升級優(yōu)先考慮跨版本升級路徑比如從2.x升到3.x時建議先看官方的升級文檔里有沒有標(biāo)記為不兼容的變更。表格是版本選擇時最直觀的參考我列一個我常用的簡化對照用途推薦Kafka版本推薦ZooKeeper版本建議模式學(xué)習(xí)/測試3.4.x及以上3.7.x及以上KRaft或ZooKeeper生產(chǎn)小規(guī)模3.2.x或3.3.x3.6.x及以上ZooKeeper優(yōu)先老項目維護(hù)跟隨現(xiàn)網(wǎng)版本跟隨現(xiàn)網(wǎng)版本ZooKeeper模式關(guān)于Scala版本的選擇我個人的習(xí)慣是直接選擇官方推薦的那個不要隨便換。因為Kafka的啟動腳本和部分工具在編譯時是跟Scala版本綁定的你換一個編譯版本可能出現(xiàn)微妙的兼容性問題。2. 前置環(huán)境準(zhǔn)備JDK配置與ZooKeeper安裝2.1 JDK版本怎么選不是越新越好Kafka是基于JVM運行的系統(tǒng)JDK版本直接影響它的運行穩(wěn)定性和性能表現(xiàn)。很多新手上來就裝最新的JDK 17甚至JDK 21結(jié)果發(fā)現(xiàn)Kafka啟動報一堆錯或者明明可以啟動但G1垃圾回收器一直報警告日志。Kafka官方對不同版本的JDK支持情況是有明確聲明的。以Kafka 3.x為例官方博客明確表示支持Java 8、11和17但不同的小版本支持力度不一樣。我自己的實際經(jīng)驗是Kafka 3.0到3.3之間用JDK 8最省心3.4之后的版本用JDK 11或者17更好。但如果你用的是JDK 8u系列的老版本比如8u111之前要注意修一下JCE無限制強度權(quán)限的問題否則加解密相關(guān)的功能會受限。這里有個很重要的認(rèn)識Kafka對JDK版本的要求不只看Kafka本身還要看你使用的客戶端庫。如果你的生產(chǎn)者、消費者代碼是用JDK 8編譯的而Broker跑在JDK 17上雖然大多數(shù)情況能兼容但如果你用的高版本JDK對某些舊庫做了一些安全策略調(diào)整還是可能出現(xiàn)一些奇怪的異常。所以我的建議是環(huán)境統(tǒng)一、版本統(tǒng)一。開發(fā)環(huán)境、測試環(huán)境、生產(chǎn)環(huán)境盡量保持一致。我常用的JDK配置步驟如下下載JDK建議使用tar.gz包而不是rpm或deb包方便自由切換版本并解壓到指定目錄。配置JAVA_HOME和PATH環(huán)境變量。驗證版本java -version。這里有個細(xì)節(jié)值得注意Kafka的啟動腳本kafka-server-start.sh默認(rèn)會找到JAVA_HOME對應(yīng)的java來執(zhí)行如果你配置了多個JDK版本一定要確認(rèn)JAVA_HOME指向了正確的那一個。2.2 ZooKeeper到底能不能省KRaft模式與ZooKeeper模式的取舍關(guān)于ZooKeeper的爭論在Kafka社區(qū)已經(jīng)持續(xù)了好幾年。Kafka 2.8引入KRaft模式時官方說的是逐步去除ZooKeeper依賴到了3.3版本才把KRaft標(biāo)注為生產(chǎn)可用。但即便到今天很多生產(chǎn)環(huán)境依然用的是ZooKeeper模式。先說結(jié)論如果你是新學(xué)Kafka我建議兩種模式都試一遍。先搭ZooKeeper模式理解清楚Kafka的元數(shù)據(jù)管理曾經(jīng)是怎么運作的再搭KRaft模式感受一下新架構(gòu)的簡潔。如果只是出于學(xué)習(xí)目的KRaft模式確實更簡單你只需要下載Kafka一個包不用額外維護(hù)ZooKeeper集群配置也少了一半。但是說到生產(chǎn)環(huán)境我目前的態(tài)度還是偏保守。ZooKeeper模式的積累足夠深很多運維工具、監(jiān)控腳本、故障處理方案都是圍繞這套架構(gòu)寫的KRaft模式雖然簡化了部署但它在一些極端場景下的表現(xiàn)比如控制器切換、元數(shù)據(jù)同步延遲還沒有經(jīng)過足夠長的時間驗證。而且KRaft的配置參數(shù)和ZooKeeper模式差異很大網(wǎng)上能查到的參考資料相對少一些。如果你選擇了ZooKeeper模式那ZooKeeper的安裝和Kafka是兩個獨立的步驟。ZooKeeper本身是一個輕量級的分布式協(xié)調(diào)服務(wù)它也需要JDK配置相對簡單核心就是dataDir、clientPort、tickTime這幾個參數(shù)。我推薦的ZooKeeper部署方式有兩種單機模式學(xué)習(xí)用配置一個dataDir和clientPort就能啟動。集群模式至少三個節(jié)點通過myid文件和zoo.cfg里的server列表來做選舉。不少人在單機環(huán)境里圖省事會把ZooKeeper以單機模式跑Kafka的Broker也只跑一個節(jié)點兩者都在同一臺機器上。這在開發(fā)環(huán)境沒問題但要注意ZooKeeper的數(shù)據(jù)目錄和Kafka的日志目錄不要共用同一個磁盤分區(qū)否則日志量大的時候會把ZooKeeper的數(shù)據(jù)文件擠爆。3. 單節(jié)點Kafka環(huán)境搭建一步步從下載到收發(fā)消息3.1 下載、解壓和目錄結(jié)構(gòu)解析Kafka的二進(jìn)制包可以在Apache官網(wǎng)找到下載時認(rèn)準(zhǔn)帶bin后綴的tar.gz包不要下載source包。解壓之后你會看到一個很典型的目錄結(jié)構(gòu)我來逐個說一下這些目錄的作用bin目錄存放所有的啟動腳本和運維腳本比如kafka-server-start.sh、kafka-topics.sh、kafka-console-producer.sh、kafka-console-consumer.sh。config目錄存放所有配置文件最核心的是server.properties、producer.properties、consumer.properties還有ZooKeeper模式下用到的log4j.properties。libs目錄Kafka運行依賴的所有jar包包括Kafka本身的jar包、Scala標(biāo)準(zhǔn)庫、各種第三方依賴。logs目錄這個目錄默認(rèn)不一定存在Kafka啟動后會創(chuàng)建里面存放的是Kafka運行日志注意這個logs目錄跟Topic消息的數(shù)據(jù)目錄是兩個不同的概念。很多新手會把Kafka的運行日志和數(shù)據(jù)目錄搞混。Kafka默認(rèn)的數(shù)據(jù)目錄由配置文件里的log.dirs指定存儲的是Topic分區(qū)的實際消息文件而logs目錄或者運行時通過log4j配置指定的目錄存的是Kafka自身的運行日志。這兩個一定要分開如果一個磁盤滿了另一個也會被拖累。解壓后第一件事我建議先看一眼config/server.properties文件把所有帶注釋的配置都過一遍心里有個數(shù)。不要急著啟動先理解每個核心參數(shù)是干嘛的。3.2 server.properties核心參數(shù)詳解broker.id、log.dirs、listeners、zookeeper.connectKafka的環(huán)境配置絕大多數(shù)工作量都集中在server.properties這一個文件上。這個文件里的參數(shù)非常多但關(guān)鍵的、需要你來配置的其實就那么十幾個其他的基本可以用默認(rèn)值。下面這些是我在每次搭建環(huán)境時都會逐一確認(rèn)的參數(shù)broker.id這個參數(shù)是Kafka集群里每個Broker節(jié)點的唯一標(biāo)識必須是整數(shù)。單機環(huán)境下默認(rèn)是0集群環(huán)境里每個節(jié)點必須不同。有一點提醒broker.id不要求跟IP綁定但運維上建議做一個IP到broker.id的映射表否則節(jié)點多了以后根本分不清誰是誰。listeners這個參數(shù)決定了Kafka對外提供服務(wù)的地址和端口。默認(rèn)是PLAINTEXT://:9092也就是本機所有網(wǎng)卡的9092端口。如果你是單機測試用默認(rèn)就好但如果你要遠(yuǎn)端的客戶端來連接切記要配置成內(nèi)網(wǎng)IP或者0.0.0.0并且要同時關(guān)注advertised.listeners。我遇到過不止一次Kafka Broker看著啟動成功了客戶端卻連不上最后發(fā)現(xiàn)是advertised.listeners寫成了localhost客戶端拿到的地址自然是本機。log.dirs這個參數(shù)指定了消息數(shù)據(jù)的存儲目錄。默認(rèn)是/tmp/kafka-logs這個強烈建議改掉。原因很簡單很多操作系統(tǒng)會定期清理/tmp下的文件把你的Kafka數(shù)據(jù)當(dāng)垃圾文件清掉。而且/tmp分區(qū)的大小往往受限消息量一大就會爆盤。我一般在規(guī)劃環(huán)境時會單獨掛一塊數(shù)據(jù)盤或者至少用一個專門的目錄比如/data/kafka-logs確保磁盤空間和業(yè)務(wù)數(shù)據(jù)的隔離。zookeeper.connect這是ZooKeeper模式下最重要的參數(shù)指定了Kafka連接ZooKeeper的地址。單機模式就是一個IP加2181端口集群模式可以用逗號分隔多個ZooKeeper節(jié)點比如192.168.1.10:2181,192.168.1.11:2181,192.168.1.12:2181。如果你只有一個ZooKeeper節(jié)點那直接寫一個地址就行。還有一個可選配置chroot路徑比如192.168.1.10:2181/kafka這樣可以讓Kafka的元數(shù)據(jù)都保存在ZooKeeper的/kafka節(jié)點下避免跟其他使用共用ZooKeeper的服務(wù)沖突。num.partitions這個參數(shù)是Topic的默認(rèn)分區(qū)數(shù)默認(rèn)是1。如果你后續(xù)不打算手動為每個Topic指定分區(qū)數(shù)建議提前改成一個合理的值比如3。我見過很多測試環(huán)境因為默認(rèn)分區(qū)數(shù)是1導(dǎo)致消費者并行度上不去還以為是代碼寫錯了。log.retention.hours消息保留時間默認(rèn)是168小時也就是7天。開發(fā)測試環(huán)境下可以縮短比如24小時省磁盤。生產(chǎn)環(huán)境根據(jù)業(yè)務(wù)數(shù)據(jù)保留策略來定不是越長越好因為Kafka清理過期數(shù)據(jù)是定期執(zhí)行的數(shù)據(jù)量大的時候清理線程本身也會占用I/O資源。auto.create.topics.enable這個參數(shù)默認(rèn)是true意思是當(dāng)你往一個不存在的Topic發(fā)送消息時Kafka會自動創(chuàng)建這個Topic。開發(fā)環(huán)境方便但生產(chǎn)環(huán)境我建議改成false。原因是自動創(chuàng)建的Topic用的是默認(rèn)分區(qū)數(shù)和副本數(shù)容易打亂集群的資源規(guī)劃而且一旦有客戶端誤發(fā)了消息就會產(chǎn)生一堆意想不到的Topic增加運維負(fù)擔(dān)。3.3 啟動驗證用兩條命令把數(shù)據(jù)跑起來環(huán)境配置完成后啟動順序必須嚴(yán)格遵守先啟動ZooKeeper再啟動Kafka Broker。ZooKeeper的啟動命令是bin/zookeeper-server-start.sh config/zookeeper.properties注意這個腳本在Kafka的bin目錄下是Kafka自帶的那份ZooKeeper啟動腳本。如果你之前沒裝過ZooKeeper直接用這個就行如果你另外裝了獨立的ZooKeeper那最好用獨立安裝的那個來啟動避免版本不一致帶來問題。Kafka Broker的啟動命令是bin/kafka-server-start.sh config/server.properties如果你希望進(jìn)程在后臺運行可以加上-daemon參數(shù)bin/kafka-server-start.sh -daemon config/server.properties啟動完之后我強烈建議做一次完整的功能驗證而不僅僅是看進(jìn)程在不在。完整驗證分三步走第一步確認(rèn)進(jìn)程存在。用jps或者ps -ef | grep kafka檢查是否有Kafka進(jìn)程同時確認(rèn)ZooKeeper進(jìn)程存在。第二步創(chuàng)建一個測試Topic。在Kafka的bin目錄下執(zhí)行bin/kafka-topics.sh --bootstrap-server localhost:9092 --create --topic test-topic --partitions 3 --replication-factor 1如果沒有報錯再執(zhí)行bin/kafka-topics.sh --bootstrap-server localhost:9092 --describe --topic test-topic這條命令應(yīng)該能看到Topic的分區(qū)分布信息比如Partition 0、Partition 1、Partition 2以及對應(yīng)的Leader和Replicas。第三步用控制臺生產(chǎn)者和消費者實測消息通路。打開一個終端啟動消費者bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic test-topic --from-beginning再開另一個終端啟動生產(chǎn)者bin/kafka-console-producer.sh --bootstrap-server localhost:9092 --topic test-topic在生產(chǎn)者終端輸入一條消息回車切到消費者終端看能不能收到。能收到就說明整個環(huán)境已經(jīng)通了。這里有一個細(xì)節(jié)新版Kafka推薦用--bootstrap-server來連接Broker但很多老教程還在用--zookeeper來操作Topic。如果你用的是3.x版本某些場景下--zookeeper已經(jīng)被標(biāo)記為過度方案比如創(chuàng)建Topic這種操作直接走Broker的API就行不需要再經(jīng)過ZooKeeper。另外消費者用--from-beginning參數(shù)會把歷史消息全部拉下來如果你只想看新消息就不要加這個參數(shù)。4. 三節(jié)點集群環(huán)境搭建高可用不是加一臺機器那么簡單4.1 多節(jié)點配置要點broker.id不能重復(fù)listeners端口不能沖突單節(jié)點環(huán)境跑通之后很多人會想著直接上集群。這個想法很好但集群環(huán)境跟單機環(huán)境有個本質(zhì)區(qū)別單機環(huán)境你只需要關(guān)心參數(shù)能不能跑起來集群環(huán)境你還得關(guān)心節(jié)點之間的網(wǎng)絡(luò)、角色、選舉、數(shù)據(jù)冗余任何一個環(huán)節(jié)沒有配好集群就是假集群表面上三個進(jìn)程都在實際上副本數(shù)一直處于不健康狀態(tài)。我搭建三節(jié)點集群時的規(guī)劃是這樣的三臺虛擬機或三臺物理機上每臺都部署一個ZooKeeper實例和一個Kafka Broker實例。ZooKeeper三節(jié)點組成一個集群Kafka三節(jié)點組成一個Broker集群。如果你機器資源緊張可以把ZooKeeper和Kafka混部在同一批機器上但生產(chǎn)環(huán)境強烈建議分開部署因為ZooKeeper對磁盤延遲比較敏感混部會導(dǎo)致它的選舉和同步性能受影響。先配置ZooKeeper集群。每個ZooKeeper節(jié)點需要一個myid文件存放在dataDir指定的目錄下內(nèi)容就是當(dāng)前節(jié)點的ID比如1、2、3。zoo.cfg里要配置dataDir/data/zookeeper clientPort2181 server.1192.168.1.10:2888:3888 server.2192.168.1.11:2888:3888 server.3192.168.1.12:2888:3888 tickTime2000 initLimit10 syncLimit5三個節(jié)點的zoo.cfg基本一樣唯一的區(qū)別就是myid文件不一樣。2888是ZooKeeper節(jié)點間同步數(shù)據(jù)的端口3888是選舉端口這兩個端口必須在防火墻里放行很多集群搭完發(fā)現(xiàn)ZooKeeper一直處于LOOKING狀態(tài)就是因為這兩個端口被防火墻攔了。Kafka集群的server.properties配置相比單機只多幾個關(guān)鍵點broker.id要分別設(shè)置為0、1、2。zookeeper.connect要配置成三個ZooKeeper地址的列表中間用逗號分隔。log.dirs建議每個節(jié)點用不同的目錄比如本機的/data/kafka-logs不要用共享存儲。listeners和advertised.listeners在每臺機器上要配置本機的內(nèi)網(wǎng)IP。這里最容易出錯的是復(fù)制配置時忘了改IP。4.2 集群啟動驗證Topic副本數(shù)的意義和副本狀態(tài)檢查集群搭建完成后的驗證跟單節(jié)點的驗證不一樣重點從能不能收消息變成了數(shù)據(jù)有沒有副本、副本有沒有同步。啟動完三臺Broker后先看集群狀態(tài)。在任意一臺機器上執(zhí)行bin/kafka-topics.sh --bootstrap-server 192.168.1.10:9092 --describe --topic test-topic如果這個Topic的ReplicationFactor大于1那么輸出結(jié)果里每個分區(qū)的Replicas應(yīng)該有三臺Broker的IDIsrIn-Sync Replicas里的節(jié)點數(shù)量應(yīng)該跟副本數(shù)一致。如果Isr里的節(jié)點數(shù)少了一個說明有一個Broker的同步落后了這通常意味著這個節(jié)點的磁盤I/O或者網(wǎng)絡(luò)有問題需要單獨排查不能簡單重啟了事。創(chuàng)建集群Topic時的副本數(shù)建議設(shè)置成2或者3。副本數(shù)不是越大越好因為每增加一個副本就意味著多一份磁盤空間占用和副本同步的流量開銷。一般三節(jié)點集群副本數(shù)設(shè)2就能容忍單點故障設(shè)3能容忍更極端的故障場景但代價是磁盤占用翻倍。我個人習(xí)慣在測試環(huán)境設(shè)2生產(chǎn)環(huán)境設(shè)3。驗證消息通路時生產(chǎn)者和消費者的--bootstrap-server參數(shù)要指向集群中任意一個Broker的地址即可不用寫三個。Kafka客戶端會自動通過這個Broker拉取整個集群的元數(shù)據(jù)知道哪個分區(qū)在哪個Broker上。關(guān)于集群還有一個常見誤解以為連上集群中任何一個節(jié)點就能保證消息不丟。實際上消息不丟依賴的是副本同步機制生產(chǎn)者要設(shè)置acks參數(shù)。acksall代表等待所有副本都確認(rèn)才返回成功這是保證消息不丟的前提。acks0或acks1雖然性能高但節(jié)點故障時會有丟消息風(fēng)險。這個參數(shù)雖然是在生產(chǎn)者端配置的但搭建環(huán)境時就應(yīng)該想清楚因為后續(xù)所有測試都基于這個前提。4.3 KRaft模式集群搭建去掉ZooKeeper后的配置差異既然前面提到了KRaft模式這里順便補充一下KRaft模式下集群怎么搭。KRaft模式最大的變化是不需要ZooKeeperKafka自身用一組Controller節(jié)點來管理元數(shù)據(jù)。部署KRaft模式的集群首先要做的事跟ZooKeeper模式完全不同你要先格式化存儲目錄生成一個Cluster ID然后每個節(jié)點都要用到這個IDController節(jié)點和Broker節(jié)點的配置分開放到不同文件。KRaft模式下核心的配置項是process.roles這個參數(shù)可以設(shè)置broker、controller或者broker,controller決定了節(jié)點的角色。如果是混部模式就寫broker,controller如果是分角色部署Controller節(jié)點寫controllerBroker節(jié)點寫broker。node.id相當(dāng)于broker.id和controller.id的統(tǒng)一體集群內(nèi)唯一。controller.quorum.voters指定Controller節(jié)點列表的地址和ID類似ZooKeeper的server列表但格式不同比如1192.168.1.10:9093,2192.168.1.11:9093,3192.168.1.12:9093。我第一次試KRaft模式時卡得最久的就是格式化這一步。Kafka提供了一個腳本用于生成Cluster ID和格式化存儲目錄bin/kafka-storage.sh random-uuid bin/kafka-storage.sh format -t uuid -c config/kraft/server.properties如果你漏掉了格式化這一步直接啟動Kafka會報一個Directory is not formatted的錯誤。這個錯倒是很直觀但如果你用的是舊版本的KRaft報錯信息可能不一樣有時候是No meta.properties found這種經(jīng)驗不夠的話很容易誤以為配置寫錯了。KRaft模式解決了ZooKeeper模式的兩個痛點一個是減少了需要維護(hù)的外部依賴另一個是元數(shù)據(jù)的讀寫路徑更短Controller可以直接通過內(nèi)部Raft協(xié)議管理元數(shù)據(jù)不用再跨ZooKeeper同步。但就像我前面說的學(xué)習(xí)理解ZooKeeper模式的核心概念仍然有價值因為很多生產(chǎn)環(huán)境還沒有遷到KRaft。5. 環(huán)境搭建中的高頻問題與排查思路5.1 網(wǎng)絡(luò)和端口問題連不上、超時的常見原因Kafka環(huán)境搭建遇到最多的就是網(wǎng)絡(luò)問題。由于Kafka涉及多端口、多角色任何一個端口沒放行、任何一個IP配置不匹配表現(xiàn)出來的癥狀都是連不上。我先列一個端口清單讓你心里有個數(shù)組件默認(rèn)端口用途ZooKeeper客戶端端口2181Kafka連接ZooKeeperZooKeeper節(jié)點間同步端口2888集群節(jié)點間數(shù)據(jù)同步ZooKeeper選舉端口3888Leader選舉通信Kafka Broker端口9092客戶端生產(chǎn)和消費消息Kafka Controller端口KRaft9093Controller節(jié)點間通信排查網(wǎng)絡(luò)問題的通用思路是先確認(rèn)進(jìn)程監(jiān)聽在哪個端口再確認(rèn)目標(biāo)機器的端口能不能通最后再去查應(yīng)用日志。第一步在Broker節(jié)點上執(zhí)行ss -tlnp | grep 9092確認(rèn)Kafka確實監(jiān)聽在9092。如果這里顯示監(jiān)聽的IP是127.0.0.1而不是0.0.0.0或你的內(nèi)網(wǎng)IP那說明listeners配置有問題。第二步在客戶端機器上執(zhí)行telnet或nc測試到Broker的9092端口是否可通。比如telnet 192.168.1.10 9092如果通了會顯示Connected to...。如果超時要么是防火墻擋了要么是安全組規(guī)則沒放行要么是網(wǎng)絡(luò)不通。第三步查看Kafka的server.log。這個日志文件在logs目錄下里面會記錄Broker的啟動過程、連接的客戶端地址、異常信息。很多網(wǎng)絡(luò)問題都能從日志里找到線索比如Connection refused代表目標(biāo)端口沒監(jiān)聽Connection timed out代表網(wǎng)絡(luò)層就不通。還有一種很隱蔽的情況Broker配置正常、端口也通但客戶端還是報TimeoutException。這種情況大概率是advertised.listeners配置成了127.0.0.1或localhost客戶端從集群元數(shù)據(jù)里拿到的是Broker自己的回環(huán)地址自然無法連接。我在本地用Docker跑Kafka時就經(jīng)常遇到因為容器內(nèi)的localhost跟宿主機的localhost不是同一個概念。5.2 磁盤和內(nèi)存問題爆盤、OOM、垃圾回收異常Kafka對磁盤和內(nèi)存的要求是出了名的高很多環(huán)境搭起來能用但一有流量就掛多半是這兩塊配置沒做好。先說磁盤。Kafka是順序?qū)懴⒌倪@個特性決定了它對磁盤的訴求是順序?qū)懶阅芤枚皇请S機讀性能要多強。所以服務(wù)器選型時機械硬盤不是不能用但一定要確認(rèn)RAID策略和磁盤轉(zhuǎn)速SSD當(dāng)然是更好的選擇尤其是NVMe盤。另外Kafka的數(shù)據(jù)目錄千萬不要放系統(tǒng)盤也不要跟ZooKeeper或數(shù)據(jù)庫的數(shù)據(jù)目錄混在一起。爆盤問題是最常見的。Kafka會在磁盤剩余空間低于一定閾值時報警默認(rèn)的閾值是低于500MB進(jìn)入只讀模式低于200MB甚至無法啟動。這個參數(shù)是log.flush.offset.checkpoint.interval.ms之后的保護(hù)機制實際上不同版本的閾值定義不太一樣。我的經(jīng)驗是給Kafka單獨規(guī)劃一塊盤容量按單日消息量乘以保留天數(shù)再乘以副本數(shù)來估算比如每天100GB流量、保留3天、2副本那至少要600GB空間再留30%的余量就是800GB左右。再說內(nèi)存。Kafka本身是Java應(yīng)用JVM堆內(nèi)存大小通過bin/kafka-server-start.sh里的KAFKA_HEAP_OPTS來控制默認(rèn)是1GB-Xmx1G -Xms1G。開發(fā)測試環(huán)境1GB綽綽有余但生產(chǎn)環(huán)境一般建議8GB到16GB起步。這里有個容易忽視的點Kafka的頁緩存Page Cache是操作系統(tǒng)層面的不占JVM堆內(nèi)存所以不要一味地調(diào)大JVM堆要給操作系統(tǒng)留足夠的內(nèi)存來緩存消息數(shù)據(jù)。我見過有人把JVM堆設(shè)成32GB結(jié)果系統(tǒng)內(nèi)存全被JVM吃掉了頁緩存幾乎為0Kafka的吞吐量反而下降因為大量讀操作要走磁盤而不是走內(nèi)存緩存。如果Kafka進(jìn)程在啟動后不久就報OutOfMemoryError優(yōu)先檢查KAFKA_HEAP_OPTS是不是太小。如果是GC時間過長導(dǎo)致的暫停可以先看GC日志判斷是堆太小還是有大對象的分配問題。實用的做法是先保持默認(rèn)的G1收集器不變把堆內(nèi)存調(diào)到合適范圍然后觀察一段時間不要急著換GC算法。5.3 高并發(fā)環(huán)境下的JVM參數(shù)優(yōu)化聊到環(huán)境搭建很多人以為配置完就完事了實際上Broker的JVM參數(shù)對高并發(fā)場景的影響非常大。我在壓測Kafka環(huán)境時習(xí)慣在啟動前就把JVM的GC日志打開這樣就算后面出問題也有據(jù)可查。默認(rèn)的bin/kafka-server-start.sh腳本里JVM參數(shù)是通過KAFKA_HEAP_OPTS和KAFKA_JVM_PERFORMANCE_OPTS兩個環(huán)境變量注入的。KAFKA_JVM_PERFORMANCE_OPTS默認(rèn)內(nèi)容大概是這樣-server -XX:UseG1GC -XX:MaxGCPauseMillis20 -XX:InitiatingHeapOccupancyPercent35 -XX:DisableExplicitGCG1GC是默認(rèn)的收集器MaxGCPauseMillis控制目標(biāo)停頓時間InitiatingHeapOccupancyPercent控制G1并發(fā)標(biāo)記的觸發(fā)閾值。這些參數(shù)不需要你去改但建議你理解它們的作用。如果遇到GC停頓時間飆升除了調(diào)參更要先找代碼層面有沒有問題比如消費者客戶端頻繁創(chuàng)建新的Consumer實例、生產(chǎn)者端批量參數(shù)沒設(shè)置好都會導(dǎo)致Broker端負(fù)載異常。一個非常多人忽略的參數(shù)是num.network.threads和num.io.threadsnum.network.threads默認(rèn)是3負(fù)責(zé)處理網(wǎng)絡(luò)請求。num.io.threads默認(rèn)是8負(fù)責(zé)處理實際的讀寫請求。當(dāng)你的生產(chǎn)者、消費者連接數(shù)很多或者請求量很大的時候這兩個線程數(shù)可能會出現(xiàn)瓶頸。我在壓測環(huán)境里一般會先調(diào)到num.network.threads8、num.io.threads16再根據(jù)監(jiān)控逐步調(diào)整。不過提醒一句調(diào)線程數(shù)不是越多越好線程多了會帶來線程切換的額外開銷反而降低性能。5.4 安全認(rèn)證配置的基礎(chǔ)注意事項如果搭建的Kafka環(huán)境要暴露到不受信任的網(wǎng)絡(luò)或者公司內(nèi)部有安全合規(guī)要求那SSL認(rèn)證和SASL認(rèn)證就是繞不開的話題。Kafka的安全配置涉及兩個鏈路客戶端到Broker、Broker到ZooKeeper如果是ZooKeeper模式。配置不當(dāng)會導(dǎo)致一個詭異的現(xiàn)象客戶端能用telnet連上9092端口但一執(zhí)行消費命令就報認(rèn)證失敗。配置SSL時核心步驟是生成服務(wù)端證書和客戶端證書然后分別配置到server.properties的ssl.keystore.location和ssl.truststore.location客戶端則在連接參數(shù)里配置ssl.truststore.location。這一步的坑在于證書的CNCommon Name必須和Broker的主機名匹配否則SSL握手時會因為主機名校驗失敗而拒絕連接。如果是IP直連方式的客戶端需要在證書里配置subjectAlternativeName的IP否則一樣會失敗。如果你只是想簡單驗證SASL配置可以用Kafka自帶的配置模板config目錄下有kafka_server_jaas.conf等文件可以直接參考。不過請記住一個原則安全認(rèn)證先在內(nèi)網(wǎng)測試環(huán)境驗證完整流程再上生產(chǎn)不要在生產(chǎn)環(huán)境直接開啟認(rèn)證后才發(fā)現(xiàn)客戶端全部連不上。6. 可視化工具與后續(xù)學(xué)習(xí)建議6.1 常用監(jiān)控工具從命令行到可視化的過渡環(huán)境搭好之后純命令行操作效率太低了尤其是多個主題、多個消費者組的情況下用眼睛看命令輸出根本盯不過來。我通常會搭一個可視化的監(jiān)控界面把集群狀態(tài)、Topic列表、消費者Lag這些關(guān)鍵指標(biāo)集中展示出來。常見的方案有三種Kafka UI舊稱UI for Apache Kafka界面清爽支持多集群管理能直接查看Topic、分區(qū)、消費者組、消息內(nèi)容對新手很友好是我首推的學(xué)習(xí)工具。Kafdrop輕量級Spring Boot項目一條命令就能啟動但功能相對簡單適合快速查看消息。Prometheus Grafana這是生產(chǎn)環(huán)境的主流監(jiān)控方案通過JMX Exporter暴露Kafka指標(biāo)然后在Grafana上配置看板。對新手前期不推薦因為學(xué)習(xí)曲線比較陡但你遲早要接觸它。如果你只是想快速看消息內(nèi)容Kafdrop的啟動非常簡單一條jar命令就行java -jar kafdrop.jar --kafka.brokerConnect192.168.1.10:9092如果你希望功能更全Kafka UI會是一個更完整的選擇。它支持通過配置文件來管理多個Kafka集群還能展示某個消費者組的消費進(jìn)度和Lag。但注意Kafka UI本身是Java應(yīng)用部署時同樣要注意JDK版本兼容。6.2 從環(huán)境搭建到生產(chǎn)級安裝要補的功課環(huán)境搭建只是第一步從能跑到生產(chǎn)可用中間差的功課還有很多。我總結(jié)幾個優(yōu)先級比較高的事項第一參數(shù)基線化。把搭建環(huán)境的參數(shù)記錄下來打包成標(biāo)準(zhǔn)配置模板不要再每次手動改。Kafka的參數(shù)實在太多今天改了一個明天忘了是誰改的后面排查問題全靠猜。用配置文件管理工具把server.properties作為代碼管理記錄變更歷史這會省下無數(shù)時間。第二日志和監(jiān)控的打通。Kafka本身的運行日志需要采集Broker的指標(biāo)需要暴露。生產(chǎn)環(huán)境至少要保證進(jìn)程級別的存活監(jiān)控、磁盤使用率監(jiān)控、Topic級別的消息積壓監(jiān)控。任何一個維度缺失線上問題都會難定位。第三消息發(fā)送的可靠性驗證。環(huán)境搭好之后不要只測一條消息能不能通。要測異常場景殺掉一個Broker看消息會不會丟、消費者能不能繼續(xù)消費把磁盤空間占滿看Kafka的表現(xiàn)是什么重啟一個節(jié)點看分區(qū)副本能不能自動恢復(fù)。這些測試沒有一個會白做它們才是環(huán)境真正可用的證明。7. 寫在最后的幾點經(jīng)驗Kafka環(huán)境搭建這件事看起來就是個安裝配置流程但在實際操作中真正花時間的往往不是安裝本身而是對Kafka運行機制的理解和對各種邊界情況的處理。我陸陸續(xù)續(xù)搭過開發(fā)環(huán)境、測試環(huán)境和生產(chǎn)環(huán)境每一次都會踩到不一樣的坑但有幾個經(jīng)驗是通用的第一啟動順序永遠(yuǎn)不要亂。ZooKeeper模式先啟ZooKeeper再啟KafkaKRaft模式雖然不需要ZooKeeper但每個節(jié)點要保證controller角色先就緒再啟動broker角色。順序錯了表面上不會有立刻的崩潰但后臺的錯誤日志會持續(xù)報。第二版本統(tǒng)一是一個硬性原則。Kafka、ZooKeeper、JDK、客戶端庫、可視化工具的版本盡量在同一個兼容矩陣?yán)镞x。不要小看版本差異我在測試環(huán)境遇到過因為客戶端庫版本太低連不上3.x版本的Broker報的是UnsupportedVersionException根本讓人摸不著頭腦。第三日志和監(jiān)控從第一天就做好。哪怕只是單機測試環(huán)境也把Kafka的日志級別調(diào)整好把關(guān)鍵目錄的空間監(jiān)控加好。等到出了大問題再來加監(jiān)控往往已經(jīng)晚了。如果你正在搭Kafka環(huán)境我的建議是先按這篇的步驟把單機環(huán)境跑通再把三節(jié)點集群跑通最后再考慮安全認(rèn)證和監(jiān)控完善。不要一上來就追求完美架構(gòu)先把基礎(chǔ)鏈路跑起來你才能真正理解Kafka的每一個組件在干什么。