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