1. 從“會(huì)用的中間件”到“懂原理的工程師”為什么我要啃 Kafka Raft很多人用 Kafka 用了好幾年日常就是寫 Producer、調(diào) Consumer、偶爾看看 Lag覺得這套東西“會(huì)用就行”。但一旦集群出現(xiàn) Controller 頻繁切換、元數(shù)據(jù)不一致、Partition Leader 選舉卡住這類問題光靠翻文檔和重啟大法就完全不夠用了。我真正下決心把 Kafka Raft 從頭到尾捋一遍就是因?yàn)橐淮尉€上事故一個(gè)三節(jié)點(diǎn)的元數(shù)據(jù)集群在滾動(dòng)重啟后Controller 反復(fù)易主日志里全是選舉超時(shí)和日志截?cái)嘞嚓P(guān)的報(bào)錯(cuò)當(dāng)時(shí)團(tuán)隊(duì)里沒人能說清楚底層到底發(fā)生了什么。Kafka Raft準(zhǔn)確說是KRaftKafka Raft Metadata Mode是 Kafka 用來替代 ZooKeeper 做元數(shù)據(jù)管理的共識(shí)協(xié)議實(shí)現(xiàn)。它把原本托管在外部協(xié)調(diào)組件里的元數(shù)據(jù)——比如 Broker 注冊(cè)、Topic 配置、分區(qū)副本分配、ACL、ISR 變更——全部收回到 Kafka 自己內(nèi)部通過一個(gè) Raft 共識(shí)組來維護(hù)。這件事的意義不只是“少部署一個(gè)組件”而是讓元數(shù)據(jù)的讀寫路徑、一致性模型、故障恢復(fù)邏輯都統(tǒng)一到同一套體系里。這篇文章適合三類人看第一類是把 Kafka 當(dāng)黑盒用、但想搞清楚元數(shù)據(jù)層到底怎么運(yùn)轉(zhuǎn)的開發(fā)和運(yùn)維第二類是正在做 Kafka 版本升級(jí)、考慮從 ZooKeeper 模式遷移到 KRaft 的架構(gòu)同學(xué)第三類是準(zhǔn)備面試、被問到“Kafka 為什么能去掉 ZooKeeper”卻答不深的朋友。我會(huì)從設(shè)計(jì)思路、核心概念、實(shí)操部署、故障排查幾個(gè)角度把 KRaft 這套東西拆開講透盡量做到看完能自己搭一套、出問題能自己定位。2. KRaft 的整體設(shè)計(jì)與核心思路拆解2.1 為什么非要干掉 ZooKeeper要理解 KRaft得先理解 ZooKeeper 模式下的痛點(diǎn)。在舊架構(gòu)里Kafka 的元數(shù)據(jù)分成兩半一部分存在 ZooKeeper 的 znode 里比如 Broker 列表、Topic 配置、Controller 選舉另一部分存在 Controller 的內(nèi)存里比如分區(qū)狀態(tài)機(jī)、副本分配。這兩半之間靠 Controller 監(jiān)聽 ZooKeeper 事件來同步問題就出在這個(gè)“同步”上。當(dāng)集群規(guī)模變大比如上千個(gè) Broker、幾萬個(gè)分區(qū)Controller 需要處理的元數(shù)據(jù)變更事件會(huì)急劇膨脹。ZooKeeper 的 watch 機(jī)制在大量事件同時(shí)觸發(fā)時(shí)Controller 會(huì)收到海量通知然后串行處理很容易成為瓶頸。更麻煩的是Controller 切換時(shí)新 Controller 必須先從 ZooKeeper 全量拉取元數(shù)據(jù)再重建內(nèi)存狀態(tài)這個(gè)過程中整個(gè)集群的元數(shù)據(jù)操作基本處于半停滯狀態(tài)。我見過一個(gè)中等規(guī)模集群Controller 切換一次要花好幾分鐘期間新建 Topic、分區(qū)重分配全部卡住。KRaft 的思路是把元數(shù)據(jù)當(dāng)成一條日志流來管理。所有元數(shù)據(jù)變更都寫成一條條記錄追加到一個(gè) Raft 日志里然后由 Raft 協(xié)議保證這條日志在多個(gè)節(jié)點(diǎn)之間一致復(fù)制。每個(gè)節(jié)點(diǎn)都按相同順序回放這條日志最終得到完全一致的狀態(tài)機(jī)。這樣一來元數(shù)據(jù)不再有“兩半”而是單一事實(shí)來源Controller 也不再是單點(diǎn)瓶頸因?yàn)樵獢?shù)據(jù)日志本身就是高可用的。2.2 Raft 在 Kafka 里的角色定位Raft 本身是一個(gè)共識(shí)算法核心解決的是“多個(gè)節(jié)點(diǎn)如何就一系列操作達(dá)成一致”。它把問題拆成三塊Leader 選舉、日志復(fù)制、安全性約束。Kafka 并沒有直接照搬某個(gè)現(xiàn)成的 Raft 庫而是自己實(shí)現(xiàn)了一套原因在于 Kafka 的元數(shù)據(jù)場(chǎng)景有特殊需求。第一個(gè)特殊點(diǎn)是元數(shù)據(jù)日志和消息日志的分離。KRaft 里的 Raft 日志只存元數(shù)據(jù)不存用戶消息。用戶消息還是走原來的 Partition 副本機(jī)制。這樣 Raft 組的負(fù)載相對(duì)可控不會(huì)被消息流量拖垮。第二個(gè)特殊點(diǎn)是快照機(jī)制。Raft 日志不能無限增長否則重啟回放會(huì)越來越慢。KRaft 會(huì)定期對(duì)狀態(tài)機(jī)做快照然后把快照之前的日志截?cái)??？煺绽锎娴氖钱?dāng)前完整的元數(shù)據(jù)狀態(tài)新加入的節(jié)點(diǎn)或者落后太多的節(jié)點(diǎn)可以直接拉快照不用從第一條日志開始回放。第三個(gè)特殊點(diǎn)是動(dòng)態(tài)成員變更。KRaft 支持在運(yùn)行中調(diào)整 Controller 節(jié)點(diǎn)集合比如從三節(jié)點(diǎn)擴(kuò)到五節(jié)點(diǎn)。這個(gè)過程中要保證不出現(xiàn)兩個(gè) Leader 同時(shí)存在的情況Raft 用聯(lián)合共識(shí)joint consensus的思路來處理Kafka 的實(shí)現(xiàn)里叫“動(dòng)態(tài) Quorum 重配置”。2.3 Controller、Broker、Quorum 三者的關(guān)系在 KRaft 模式下節(jié)點(diǎn)角色可以分成兩類Controller和Broker。Controller 負(fù)責(zé)元數(shù)據(jù)管理Broker 負(fù)責(zé)消息讀寫。一個(gè)節(jié)點(diǎn)可以同時(shí)扮演兩個(gè)角色也可以只做其中一個(gè)。生產(chǎn)環(huán)境里通常會(huì)把 Controller 和 Broker 分開部署避免元數(shù)據(jù)操作和消息流量互相干擾。Controller 們組成一個(gè)Quorum也就是 Raft 組。Quorum 里有一個(gè) Active ControllerLeader其余是 Standby。所有元數(shù)據(jù)寫請(qǐng)求都發(fā)給 Active Controller它把變更寫成日志條目復(fù)制給多數(shù)派然后應(yīng)用到自己的狀態(tài)機(jī)。Standby 們持續(xù)從 Leader 拉日志保持狀態(tài)同步。一旦 Leader 掛了Standby 里會(huì)重新選出一個(gè) Leader整個(gè)過程通常在秒級(jí)完成。Broker 則通過一個(gè)叫BrokerRegistration的機(jī)制向 Quorum 注冊(cè)自己定期發(fā)送心跳。如果 Broker 長時(shí)間不心跳Quorum 會(huì)把它標(biāo)記為下線并觸發(fā)分區(qū) Leader 重選舉。這里的關(guān)鍵是Broker 不直接參與 Raft 共識(shí)它只是元數(shù)據(jù)的消費(fèi)者和生產(chǎn)者通過 Controller 來間接操作元數(shù)據(jù)。3. 核心概念與關(guān)鍵機(jī)制深度解析3.1 日志、任期、索引Raft 的三塊基石Raft 日志里的每一條記錄都有一個(gè)偏移量Offset從 0 開始單調(diào)遞增。這個(gè)偏移量是全局唯一的所有節(jié)點(diǎn)上的同一條日志必須有相同的偏移量。日志條目里除了元數(shù)據(jù)變更內(nèi)容還帶著一個(gè)任期號(hào)Term。任期號(hào)是個(gè)單調(diào)遞增的整數(shù)每次 Leader 選舉都會(huì)加一。任期號(hào)的作用是區(qū)分不同 Leader 的日志防止舊 Leader 的殘留日志被誤認(rèn)為有效。選舉過程中候選人會(huì)把自己的任期號(hào)加一然后向其他節(jié)點(diǎn)拉票。其他節(jié)點(diǎn)如果發(fā)現(xiàn)候選人的任期號(hào)比自己大就更新自己的任期號(hào)并投票如果發(fā)現(xiàn)候選人的日志不如自己新就拒絕投票。這里“日志新不新”的比較規(guī)則是先比最后一條日志的任期號(hào)任期號(hào)大的更新任期號(hào)相同再比偏移量偏移量大的更新。這個(gè)規(guī)則保證了新選出的 Leader 一定擁有最完整的日志不會(huì)丟失已經(jīng)提交的條目。索引Index在 KRaft 里有兩個(gè)層面。一個(gè)是日志偏移量另一個(gè)是快照索引?？煺帐菍?duì)狀態(tài)機(jī)在某個(gè)偏移量上的完整記錄。當(dāng)節(jié)點(diǎn)重啟時(shí)它會(huì)先加載最新的快照然后從快照對(duì)應(yīng)的偏移量之后開始回放日志。這樣就不用從零開始重建狀態(tài)啟動(dòng)速度大幅提升。3.2 Leader 選舉什么時(shí)候選、怎么選、選不出來怎么辦Leader 選舉的觸發(fā)條件主要有三個(gè)集群啟動(dòng)時(shí)沒有 Leader、Leader 心跳超時(shí)、Leader 主動(dòng)退位。心跳超時(shí)時(shí)間由controller.quorum.election.timeout.ms控制默認(rèn)是 1000 毫秒。也就是說如果 Follower 超過 1 秒沒收到 Leader 的心跳就會(huì)認(rèn)為 Leader 掛了開始新一輪選舉。選舉過程是這樣的Follower 先變成 Candidate任期號(hào)加一投自己一票然后向其他所有節(jié)點(diǎn)發(fā)送 RequestVote 請(qǐng)求。其他節(jié)點(diǎn)收到請(qǐng)求后先比較任期號(hào)再比較日志新舊決定是否投票。如果 Candidate 拿到了多數(shù)派的票就變成 Leader開始發(fā)送心跳。如果這一輪沒選出來就等待一個(gè)隨機(jī)超時(shí)controller.quorum.election.backoff.max.ms然后任期號(hào)再加一重新發(fā)起選舉。選不出來最常見的原因是網(wǎng)絡(luò)分區(qū)或者節(jié)點(diǎn)數(shù)不滿足多數(shù)派。比如三節(jié)點(diǎn) Quorum 掛了一個(gè)剩下兩個(gè)還能選掛兩個(gè)剩下一個(gè)永遠(yuǎn)選不出來因?yàn)槟貌坏蕉鄶?shù)派。這時(shí)候集群會(huì)進(jìn)入不可用狀態(tài)元數(shù)據(jù)寫操作全部阻塞。所以生產(chǎn)環(huán)境里 Quorum 節(jié)點(diǎn)數(shù)必須是奇數(shù)三節(jié)點(diǎn)能容忍一個(gè)故障五節(jié)點(diǎn)能容忍兩個(gè)。3.3 日志復(fù)制與提交數(shù)據(jù)怎么寫進(jìn)去、什么時(shí)候算寫成功客戶端發(fā)來的元數(shù)據(jù)寫請(qǐng)求比如創(chuàng)建 Topic會(huì)先到 Active Controller。Controller 把請(qǐng)求轉(zhuǎn)成一條日志條目追加到自己的本地日志末尾然后并行發(fā)送給所有 Follower。Follower 收到后先寫入本地日志然后返回確認(rèn)。當(dāng) Leader 收到多數(shù)派的確認(rèn)后就把這條日志標(biāo)記為已提交Committed然后應(yīng)用到狀態(tài)機(jī)最后返回給客戶端成功。這里有個(gè)關(guān)鍵點(diǎn)已提交的日志一定會(huì)被所有未來的 Leader 包含。Raft 通過選舉限制來保證這一點(diǎn)——只有擁有最完整日志的節(jié)點(diǎn)才能當(dāng)選 Leader。所以即使某個(gè) Follower 落后很多它也不可能在落后狀態(tài)下當(dāng)選從而避免了已提交數(shù)據(jù)丟失。日志復(fù)制是流水線式的Leader 會(huì)維護(hù)每個(gè) Follower 的nextIndex和matchIndex。nextIndex是下一條要發(fā)給該 Follower 的日志偏移量matchIndex是該 Follower 已經(jīng)確認(rèn)復(fù)制的最高偏移量。如果 Follower 的日志和 Leader 不一致Leader 會(huì)逐步回退nextIndex直到找到一致點(diǎn)然后從那里開始覆蓋 Follower 的沖突日志。這個(gè)過程叫日志修復(fù)。3.4 快照機(jī)制日志不能無限長怎么截?cái)郣aft 日志如果一直不清理磁盤會(huì)爆重啟回放也會(huì)慢到無法接受。KRaft 的解決辦法是定期做快照?？煺盏膬?nèi)容是當(dāng)前狀態(tài)機(jī)的完整序列化比如所有 Topic 的配置、所有分區(qū)的副本分配、所有 Broker 的注冊(cè)信息?？煺丈珊髮?duì)應(yīng)的日志就可以被截?cái)嘀槐Ａ艨煺拯c(diǎn)之后的日志?？煺盏挠|發(fā)條件由controller.quorum.snapshot.interval.ms控制默認(rèn)是 10 分鐘。也就是說每隔 10 分鐘Controller 會(huì)把當(dāng)前狀態(tài)機(jī)做一次快照。如果日志增長太快也可以基于日志條數(shù)觸發(fā)由controller.quorum.snapshot.interval.records控制。新節(jié)點(diǎn)加入 Quorum 時(shí)如果它的日志落后太多Leader 會(huì)直接發(fā)一個(gè)快照給它而不是逐條回放日志。這個(gè)機(jī)制叫InstallSnapshot?？煺諅鬏斒欠謮K的避免一次性傳輸大文件導(dǎo)致網(wǎng)絡(luò)阻塞。節(jié)點(diǎn)收到快照后先加載快照再從快照點(diǎn)開始拉后續(xù)日志。4. 實(shí)操部署從零搭一套 KRaft 集群4.1 環(huán)境準(zhǔn)備與版本選擇KRaft 模式從 Kafka 2.8 開始有實(shí)驗(yàn)性支持3.3 之后基本穩(wěn)定3.5 以后生產(chǎn)可用。我建議至少用 3.6 或更高版本因?yàn)樵缙诎姹驹趧?dòng)態(tài) Quorum 重配置和快照恢復(fù)上還有一些邊界問題。JDK 用 17 或 21 都行Kafka 對(duì) JDK 17 的支持已經(jīng)很成熟。假設(shè)我們要搭一個(gè)三節(jié)點(diǎn) Quorum 三節(jié)點(diǎn) Broker 的集群但為了演示方便先用三個(gè)節(jié)點(diǎn)同時(shí)扮演 Controller 和 Broker 角色。每臺(tái)機(jī)器配置 4 核 8G 起步磁盤用 SSD因?yàn)?Raft 日志對(duì) fsync 性能比較敏感。網(wǎng)絡(luò)延遲要低Quorum 節(jié)點(diǎn)之間最好在同一個(gè)機(jī)房或同一個(gè)可用區(qū)跨機(jī)房部署會(huì)顯著增加選舉超時(shí)和日志復(fù)制延遲。4.2 關(guān)鍵配置項(xiàng)逐條解讀KRaft 模式下server.properties里最核心的幾個(gè)配置如下process.rolescontroller,broker node.id1 controller.quorum.voters1node1:9093,2node2:9093,3node3:9093 listenersPLAINTEXT://node1:9092,CONTROLLER://node1:9093 controller.listener.namesCONTROLLER listener.security.protocol.mapCONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT log.dirs/data/kafka-logs controller.quorum.election.timeout.ms1000 controller.quorum.election.backoff.max.ms1000 controller.quorum.fetch.timeout.ms2000process.roles決定這個(gè)節(jié)點(diǎn)是 Controller、Broker 還是兩者兼有。生產(chǎn)環(huán)境建議分開用獨(dú)立的 Controller 節(jié)點(diǎn)避免 Broker 的 IO 壓力影響元數(shù)據(jù)一致性。controller.quorum.voters是靜態(tài) Quorum 配置格式是idhost:port所有節(jié)點(diǎn)必須配置一致。controller.listener.names指定 Controller 通信用的監(jiān)聽器名稱必須和listeners里的對(duì)應(yīng)。controller.quorum.election.timeout.ms是選舉超時(shí)默認(rèn) 1000 毫秒。如果網(wǎng)絡(luò)延遲高可以適當(dāng)調(diào)大比如 2000 毫秒。但調(diào)太大意味著故障發(fā)現(xiàn)變慢Leader 掛了之后要等更久才能重新選出來。controller.quorum.fetch.timeout.ms是 Follower 拉日志的超時(shí)默認(rèn) 2000 毫秒通常不用改。4.3 格式化與啟動(dòng)流程第一次啟動(dòng)前必須對(duì)每個(gè)節(jié)點(diǎn)做格式化生成初始的元數(shù)據(jù)目錄。命令是bin/kafka-storage.sh random-uuid這個(gè)命令會(huì)生成一個(gè)集群 UUID所有節(jié)點(diǎn)必須用同一個(gè) UUID。然后對(duì)每個(gè)節(jié)點(diǎn)執(zhí)行bin/kafka-storage.sh format -t cluster-uuid -c config/kraft/server.properties格式化會(huì)創(chuàng)建log.dirs下的meta.properties文件里面記錄了集群 ID 和節(jié)點(diǎn) ID。注意格式化只能在集群第一次啟動(dòng)前做如果已經(jīng)有數(shù)據(jù)重新格式化會(huì)清空所有元數(shù)據(jù)相當(dāng)于把集群重置了。啟動(dòng)順序上先啟動(dòng)所有 Controller 節(jié)點(diǎn)等 Quorum 選出一個(gè) Active Controller 后再啟動(dòng) Broker 節(jié)點(diǎn)。可以用bin/kafka-metadata-quorum.sh --bootstrap-server node1:9092 describe --status查看 Quorum 狀態(tài)確認(rèn) Leader 是誰、Follower 是否同步。4.4 驗(yàn)證集群是否正常集群起來后先創(chuàng)建一個(gè)測(cè)試 Topicbin/kafka-topics.sh --bootstrap-server node1:9092 --create --topic test-kraft --partitions 3 --replication-factor 3然后查看 Topic 描述確認(rèn)分區(qū) Leader 和 ISR 都正常。再往 Topic 里發(fā)幾條消息用 Console Consumer 消費(fèi)出來驗(yàn)證消息鏈路沒問題。最后可以手動(dòng) kill 掉 Active Controller 進(jìn)程觀察 Quorum 是否在幾秒內(nèi)重新選出 LeaderBroker 是否正常重新注冊(cè)。這個(gè)過程能幫你直觀感受 KRaft 的故障恢復(fù)能力。5. 常見問題與排查技巧實(shí)錄5.1 Quorum 選不出 Leader 怎么辦這是最常見的問題表現(xiàn)是元數(shù)據(jù)操作全部超時(shí)日志里反復(fù)出現(xiàn)Election timeout和RequestVote相關(guān)記錄。第一步先確認(rèn) Quorum 節(jié)點(diǎn)數(shù)和存活數(shù)。三節(jié)點(diǎn) Quorum 掛兩個(gè)剩下一個(gè)永遠(yuǎn)選不出來這是數(shù)學(xué)上的必然不是 bug。用kafka-metadata-quorum.sh describe --status看當(dāng)前 Quorum 里有多少節(jié)點(diǎn)在線。如果節(jié)點(diǎn)都在線但選不出來檢查網(wǎng)絡(luò)連通性。Controller 之間的通信端口默認(rèn) 9093必須互通防火墻、安全組、DNS 解析都要確認(rèn)。我遇到過一次三臺(tái)機(jī)器里有一臺(tái)的 hostname 解析到了錯(cuò)誤的 IP導(dǎo)致另外兩臺(tái)收不到它的投票響應(yīng)選舉一直失敗。還有一次是 MTU 不匹配小包能通大包被丟日志復(fù)制正常但選舉請(qǐng)求偶爾超時(shí)。5.2 日志復(fù)制卡住或延遲高如果 Follower 的matchIndex長時(shí)間不推進(jìn)說明日志復(fù)制出了問題。先看 Leader 和 Follower 的磁盤 IORaft 日志寫入是 fsync 的磁盤慢會(huì)直接拖垮復(fù)制速度。用iostat看await和%util如果磁盤利用率長期 100%考慮換 SSD 或降低日志寫入頻率。另一個(gè)常見原因是日志修復(fù)循環(huán)。如果 Follower 的日志和 Leader 差異太大Leader 會(huì)不斷回退nextIndex試圖找到一致點(diǎn)這個(gè)過程可能很慢。如果差異超過快照范圍Leader 應(yīng)該直接發(fā)快照而不是逐條回退。檢查controller.quorum.snapshot.interval.ms是否設(shè)置合理太小會(huì)導(dǎo)致頻繁快照太大又會(huì)導(dǎo)致日志修復(fù)變慢。5.3 快照生成失敗或加載慢快照生成失敗通常是因?yàn)榇疟P空間不足或者狀態(tài)機(jī)太大。快照文件默認(rèn)存在log.dirs下的__cluster_metadata-0目錄里如果磁盤滿了快照寫不進(jìn)去日志就無法截?cái)嘧罱K磁盤徹底爆掉。監(jiān)控磁盤使用率預(yù)留至少 30% 的余量?？煺占虞d慢一般發(fā)生在節(jié)點(diǎn)重啟時(shí)。如果快照文件很大加載需要時(shí)間期間節(jié)點(diǎn)無法參與選舉?？梢哉{(diào)大controller.quorum.election.timeout.ms給節(jié)點(diǎn)更多時(shí)間完成加載。另外快照文件是二進(jìn)制格式不要手動(dòng)修改否則會(huì)導(dǎo)致狀態(tài)機(jī)不一致。5.4 動(dòng)態(tài)擴(kuò)縮容 Quorum 的注意事項(xiàng)KRaft 支持動(dòng)態(tài)調(diào)整 Quorum 成員但操作必須謹(jǐn)慎。擴(kuò)容時(shí)先把新節(jié)點(diǎn)格式化并啟動(dòng)然后用kafka-metadata-quorum.sh add-controller把它加入 Quorum。縮容時(shí)用remove-controller把節(jié)點(diǎn)移出。每次變更都會(huì)觸發(fā)一次聯(lián)合共識(shí)過程期間 Quorum 對(duì)多數(shù)派的要求會(huì)臨時(shí)變化必須確保網(wǎng)絡(luò)穩(wěn)定否則容易卡在中間狀態(tài)。我踩過的一個(gè)坑是縮容時(shí)一次性移除兩個(gè)節(jié)點(diǎn)結(jié)果剩下的節(jié)點(diǎn)數(shù)不滿足多數(shù)派整個(gè) Quorum 卡死。正確做法是一次只動(dòng)一個(gè)節(jié)點(diǎn)等 Quorum 穩(wěn)定后再動(dòng)下一個(gè)。另外動(dòng)態(tài)變更期間不要做其他元數(shù)據(jù)操作比如創(chuàng)建 Topic避免加重 Quorum 負(fù)擔(dān)。5.5 常見問題速查表問題現(xiàn)象可能原因排查手段解決方向元數(shù)據(jù)操作全部超時(shí)Quorum 無 Leader查看 Quorum 狀態(tài)和節(jié)點(diǎn)存活數(shù)恢復(fù)多數(shù)派節(jié)點(diǎn)檢查網(wǎng)絡(luò)選舉反復(fù)失敗網(wǎng)絡(luò)分區(qū)或時(shí)鐘漂移檢查 Controller 間連通性和 NTP修復(fù)網(wǎng)絡(luò)同步時(shí)鐘日志復(fù)制延遲高磁盤 IO 瓶頸iostat 看磁盤利用率換 SSD降低 fsync 頻率快照生成失敗磁盤空間不足df -h 看磁盤使用率清理空間或擴(kuò)容節(jié)點(diǎn)重啟后無法加入快照加載超時(shí)看日志里的快照加載記錄調(diào)大選舉超時(shí)檢查快照文件動(dòng)態(tài)擴(kuò)縮容卡住多數(shù)派不滿足查看 Quorum 成員列表逐個(gè)操作確保多數(shù)派在線6. 一些實(shí)操心得與避坑建議6.1 監(jiān)控指標(biāo)別只看 BrokerQuorum 才是重點(diǎn)很多人監(jiān)控 Kafka 只看 Broker 的請(qǐng)求延遲、消息吞吐、Consumer Lag但在 KRaft 模式下Quorum 的健康狀況才是元數(shù)據(jù)穩(wěn)定性的根基。必須監(jiān)控的指標(biāo)包括Active Controller 是否頻繁切換、選舉耗時(shí)、日志復(fù)制延遲、快照生成耗時(shí)和大小、Quorum 節(jié)點(diǎn)間的網(wǎng)絡(luò) RTT。這些指標(biāo)在 Kafka 的 JMX 里都有暴露比如kafka.controller:typeKafkaController,nameActiveControllerCount和kafka.server:typeMetadataQuorum,nameCurrentLeader。我建議給 Quorum 相關(guān)指標(biāo)單獨(dú)配告警。比如 Active Controller 在 5 分鐘內(nèi)切換超過 3 次或者日志復(fù)制延遲超過 500 毫秒就應(yīng)該立即介入。元數(shù)據(jù)層的問題會(huì)迅速放大到整個(gè)集群等到 Broker 開始報(bào)錯(cuò)再查就晚了。6.2 生產(chǎn)環(huán)境一定要 Controller 和 Broker 分離雖然 KRaft 允許一個(gè)節(jié)點(diǎn)同時(shí)做 Controller 和 Broker但生產(chǎn)環(huán)境強(qiáng)烈建議分離。原因很簡單Broker 承載消息流量磁盤 IO 和網(wǎng)絡(luò)帶寬波動(dòng)大Controller 需要穩(wěn)定的低延遲環(huán)境來維持 Raft 共識(shí)?；觳繒?huì)導(dǎo)致 Broker 的 IO 尖峰影響 Controller 的日志復(fù)制進(jìn)而拖慢整個(gè)元數(shù)據(jù)層。分離部署時(shí)Controller 節(jié)點(diǎn)配置可以低一些比如 2 核 4G但磁盤一定要用 SSD網(wǎng)絡(luò)要低延遲。Broker 節(jié)點(diǎn)按消息量配置和傳統(tǒng) Kafka 集群一樣。三節(jié)點(diǎn) Quorum 是最小生產(chǎn)配置五節(jié)點(diǎn)能容忍兩個(gè)故障適合對(duì)可用性要求更高的場(chǎng)景。6.3 升級(jí)和遷移要留退路從 ZooKeeper 模式遷移到 KRaft 不是一鍵操作Kafka 提供了kafka-metadata-quorum.sh和kafka-storage.sh來做遷移但過程比較復(fù)雜需要先做元數(shù)據(jù)快照再逐步切換。我的建議是先在測(cè)試環(huán)境完整走一遍遷移流程記錄每一步的耗時(shí)和可能的問題生產(chǎn)環(huán)境遷移前做好全量備份包括 ZooKeeper 數(shù)據(jù)和 Kafka 日志目錄遷移過程中保持 ZooKeeper 集群可用一旦 KRaft 出問題可以快速回滾。升級(jí) Kafka 版本時(shí)也要注意 KRaft 的兼容性。不同版本之間的 Raft 日志格式可能有變化跨大版本升級(jí)要先看官方升級(jí)指南確認(rèn)是否需要中間版本過渡。我見過一次從 3.3 直接升到 3.7結(jié)果快照格式不兼容節(jié)點(diǎn)起不來最后只能回滾重來。6.4 日志目錄的磁盤規(guī)劃KRaft 的元數(shù)據(jù)日志和快照都存在log.dirs下和消息數(shù)據(jù)共用磁盤。如果消息量很大元數(shù)據(jù)日志可能被擠到磁盤邊緣影響寫入性能。建議給元數(shù)據(jù)單獨(dú)掛一塊小容量 SSD通過log.dirs配置指向不同磁盤。元數(shù)據(jù)日志本身不大幾 GB 足夠但快照可能會(huì)到幾十 GB取決于 Topic 和分區(qū)的數(shù)量。另外log.dirs支持配置多個(gè)目錄Kafka 會(huì)把不同分區(qū)的日志分散到不同目錄。但元數(shù)據(jù)日志只會(huì)寫到一個(gè)目錄所以多目錄對(duì)元數(shù)據(jù)沒有幫助。如果元數(shù)據(jù)磁盤滿了整個(gè) Quorum 會(huì)停止工作所以這個(gè)目錄的磁盤使用率要重點(diǎn)監(jiān)控。6.5 時(shí)鐘同步不能忽視Raft 本身不依賴絕對(duì)時(shí)鐘但選舉超時(shí)和心跳超時(shí)是基于本地時(shí)鐘的。如果節(jié)點(diǎn)之間時(shí)鐘漂移太大比如一臺(tái)機(jī)器慢了幾秒它可能會(huì)誤判 Leader 心跳超時(shí)頻繁發(fā)起選舉導(dǎo)致集群不穩(wěn)定。生產(chǎn)環(huán)境必須配 NTP 或類似的時(shí)鐘同步服務(wù)確保 Quorum 節(jié)點(diǎn)之間的時(shí)鐘偏差在毫秒級(jí)。我遇到過一次時(shí)鐘漂移導(dǎo)致的問題一臺(tái) Controller 的時(shí)鐘比另外兩臺(tái)慢了 5 秒結(jié)果它每隔幾秒就發(fā)起一次選舉雖然選不出來但大量選舉請(qǐng)求占用了網(wǎng)絡(luò)和 CPU導(dǎo)致正常的日志復(fù)制也變慢。后來查了半天才發(fā)現(xiàn)是 NTP 服務(wù)掛了時(shí)鐘慢慢漂移了。所以時(shí)鐘同步不僅要配還要監(jiān)控。6.6 快照和日志的清理策略KRaft 會(huì)自動(dòng)清理快照之前的日志但快照本身不會(huì)自動(dòng)刪除。如果快照生成太頻繁磁盤上會(huì)積累大量快照文件。雖然 Kafka 會(huì)保留最近幾個(gè)快照但舊快照的清理不是實(shí)時(shí)的?？梢允謩?dòng)清理舊快照但一定要保留最新的一個(gè)否則節(jié)點(diǎn)重啟時(shí)無法加載狀態(tài)。日志清理方面controller.quorum.snapshot.interval.ms控制快照頻率間接影響日志保留量。如果元數(shù)據(jù)變更頻繁比如大量 Topic 創(chuàng)建刪除可以適當(dāng)調(diào)小這個(gè)值讓快照更頻繁日志截?cái)喔皶r(shí)。但快照本身也有開銷太頻繁會(huì)影響 Controller 性能。我的經(jīng)驗(yàn)是元數(shù)據(jù)變更不頻繁的集群10 分鐘一次快照足夠變更頻繁的可以調(diào)到 5 分鐘。7. 從原理到實(shí)戰(zhàn)一次 Controller 頻繁切換的排查記錄7.1 問題現(xiàn)象與初步判斷某天下午監(jiān)控告警顯示 Active Controller 在 10 分鐘內(nèi)切換了 7 次。Broker 日志里大量Controller not available和Metadata update failed部分 Topic 的元數(shù)據(jù)操作超時(shí)。但消息讀寫本身沒受太大影響因?yàn)?Broker 緩存了元數(shù)據(jù)短時(shí)間內(nèi)的元數(shù)據(jù)不一致還沒波及到消息層。先看 Quorum 狀態(tài)發(fā)現(xiàn)三個(gè) Controller 節(jié)點(diǎn)都在線但 Leader 頻繁易主。查看選舉日志發(fā)現(xiàn)每次選舉的任期號(hào)都在快速增長說明選舉被反復(fù)觸發(fā)。初步判斷是某個(gè) Follower 頻繁發(fā)起選舉導(dǎo)致 Leader 不斷退位。7.2 深入排查網(wǎng)絡(luò)、磁盤、時(shí)鐘先查網(wǎng)絡(luò)。用ping和traceroute看 Controller 之間的延遲發(fā)現(xiàn)其中兩臺(tái)之間偶爾有 200 毫秒以上的抖動(dòng)。但 Raft 的選舉超時(shí)是 1000 毫秒200 毫秒抖動(dòng)不至于觸發(fā)選舉。繼續(xù)查磁盤三臺(tái)機(jī)器的磁盤 IO 都正常沒有明顯瓶頸。然后查時(shí)鐘。用ntpq -p看 NTP 同步狀態(tài)發(fā)現(xiàn)其中一臺(tái)機(jī)器的偏移量在 300 毫秒左右而且還在緩慢增大。這臺(tái)機(jī)器正是頻繁發(fā)起選舉的那個(gè)。時(shí)鐘漂移導(dǎo)致它的本地時(shí)間比另外兩臺(tái)快它認(rèn)為 Leader 心跳超時(shí)了于是發(fā)起選舉。雖然它選不上但選舉請(qǐng)求會(huì)干擾 Leader導(dǎo)致 Leader 也誤判最終引發(fā)連鎖反應(yīng)。7.3 解決與后續(xù)加固臨時(shí)解決很簡單重啟 NTP 服務(wù)強(qiáng)制同步時(shí)鐘。同步完成后選舉立刻停止Controller 恢復(fù)穩(wěn)定。但根本解決要加監(jiān)控對(duì) NTP 偏移量設(shè)告警超過 100 毫秒就通知對(duì)選舉頻率設(shè)告警5 分鐘內(nèi)超過 3 次就介入。另外把controller.quorum.election.timeout.ms從 1000 毫秒調(diào)到 1500 毫秒給網(wǎng)絡(luò)抖動(dòng)和時(shí)鐘偏差更多容錯(cuò)空間。這個(gè)調(diào)整的代價(jià)是故障發(fā)現(xiàn)變慢但在這個(gè)場(chǎng)景下穩(wěn)定性比快速發(fā)現(xiàn)更重要。調(diào)整后觀察了一周沒有再出現(xiàn)頻繁選舉。7.4 這次排查給我的啟發(fā)Raft 的選舉機(jī)制對(duì)時(shí)鐘和網(wǎng)絡(luò)非常敏感而這兩個(gè)因素在分布式環(huán)境里恰恰是最容易出問題的。很多人排查 Kafka 問題習(xí)慣只看 Broker 層但在 KRaft 模式下Controller 層的穩(wěn)定性才是根基。時(shí)鐘同步、網(wǎng)絡(luò)質(zhì)量、磁盤 IO 這三樣必須納入日常巡檢。還有一點(diǎn)選舉超時(shí)不是越小越好。默認(rèn) 1000 毫秒在大多數(shù)環(huán)境夠用但如果網(wǎng)絡(luò)質(zhì)量一般或者時(shí)鐘同步不夠精確適當(dāng)調(diào)大反而更穩(wěn)。調(diào)參的本質(zhì)是在“快速發(fā)現(xiàn)故障”和“避免誤判”之間找平衡沒有標(biāo)準(zhǔn)答案只能根據(jù)實(shí)際環(huán)境試。8. 關(guān)于 KRaft 后續(xù)演進(jìn)的一些觀察KRaft 目前已經(jīng)能覆蓋絕大多數(shù) ZooKeeper 模式的場(chǎng)景但還有一些邊界情況在完善中。比如超大規(guī)模集群下的 Quorum 性能、跨機(jī)房部署的延遲優(yōu)化、動(dòng)態(tài)成員變更的平滑度這些都在持續(xù)改進(jìn)。從社區(qū)動(dòng)向看KRaft 是 Kafka 元數(shù)據(jù)管理的唯一方向ZooKeeper 模式遲早會(huì)退出歷史舞臺(tái)。對(duì)普通用戶來說現(xiàn)在就可以開始學(xué)習(xí)和測(cè)試 KRaft不用等到必須遷移時(shí)才臨時(shí)抱佛腳。先在測(cè)試環(huán)境搭一套跑一些元數(shù)據(jù)操作密集的場(chǎng)景比如批量創(chuàng)建刪除 Topic、頻繁調(diào)整分區(qū)副本觀察 Quorum 的表現(xiàn)。踩過坑之后生產(chǎn)遷移時(shí)心里就有底了。我個(gè)人在實(shí)際操作中的體會(huì)是KRaft 把 Kafka 的元數(shù)據(jù)層從“黑盒”變成了“白盒”雖然學(xué)習(xí)曲線陡了一些但一旦理解了 Raft 的日志復(fù)制和選舉機(jī)制排查元數(shù)據(jù)問題就不再是靠猜了。這套知識(shí)不僅對(duì) Kafka 有用對(duì)其他基于 Raft 的系統(tǒng)比如 etcd、Consul也有觸類旁通的效果。