Kafka 4.0 發布：KRaft 替代 Zookeeper、新一代重平衡協議、點對點消息模型、移除舊協議 API
2025 年 3 月，Apache Kafka 迎來了具有劃時代意義的 4.0 版本。這一版本不僅是技術架構的全面革新，更是功能場景的深度拓展。
碼哥第一時間對 4.0 版本分析，為大家深度解讀 Kafka 4.0 的核心特性，以下是碼哥認為比較重要的特性：
- KRaft 全面替代 ZooKeeper
- 新一代消費者重平衡協議
- 點對點消息模型與共享組
- 移除舊協議 API 版本，提升系統性能
KRaft 全面替代 ZooKeeper
Apache Kafka 4.0 是一個重要的里程碑，標志著第一個完全無需 Apache ZooKeeper? 運行的主要版本。
通過默認運行在 KRaft 模式下，Kafka 簡化了部署和管理，消除了維護單獨 ZooKeeper 集群的復雜性。
這一變化顯著降低了運營開銷，增強了可擴展性，并簡化了管理任務。
舊架構痛點回顧
在 Kafka 3.x 及更早版本中，ZooKeeper（ZK）是元數據管理的核心組件，負責 Broker 注冊、Topic 分區分配、控制器選舉等關鍵任務，如圖所示。
圖片
然而，這種設計存在顯著問題：
- 運維復雜度高：需獨立維護 ZK 集群，占用額外資源且增加故障點。
- 性能瓶頸明顯：元數據操作依賴 ZK 的原子廣播協議（ZAB），大規模集群（如萬級分區）下元數據同步延遲可達秒級。
- 擴展性受限：ZK 的寫性能隨節點數增加而下降，限制 Kafka 集群規模。
KRaft 模式的技術實現
Apache Kafka Raft（KRaft）是在 KIP-500 中引入的共識協議，用于移除 Apache Kafka 對 ZooKeeper 進行元數據管理的依賴。這通過將元數據管理的責任集中在 Kafka 本身，而不是在兩個不同的系統（ZooKeeper 和 Kafka）之間分割，從而大大簡化了 Kafka 的架構。
KRaft 模式利用 Kafka 中的新法定多數控制器服務，取代了之前的控制器，并使用基于事件的 Raft 共識協議的變體。
圖片
Kafka 4.0 默認啟用KRaft 模式（Kafka Raft），完全摒棄 ZK 依賴。其核心原理如下：
- 元數據自管理：基于 Raft 共識算法，將元數據存儲于內置的
__cluster_metadata主題中，由 Controller 節點（通過選舉產生）統一管理。 - 日志復制機制：所有 Broker 作為 Raft 協議的 Follower，實時復制 Controller 的元數據日志，確保強一致性。
- 快照與恢復：定期生成元數據快照，避免日志無限增長，故障恢復時間從 ZK 時代的分鐘級優化至秒級。
圖片
我們可以看出 KRaft 替換 ZK，并不是元數據存儲重新造輪子，而核心是集群協調機制的演進。
整個通信協調機制本質上是事件驅動模型，也就是 Metadata as an Event Log，Leader 通過 KRaft 生產權威的事件，Follower 和 Broker 通過監聽 KRaft 來獲得這些事件，并且順序處理事件，達到集群狀態和期望的最終一致。
新一代消費者重平衡協議
傳統消費者組采用Eager Rebalance 協議，存在兩大瓶頸：
- 全局同步屏障（Stop-the-World）：任何成員變更（如擴容、故障）都會觸發全組暫停，導致分鐘級延遲。
- 擴展性差：消費者數量受限于分區數，萬級消費者組重平衡耗時高達數分鐘。
Kafka 4.0 引入增量式重平衡協議（KIP-848），核心改進包括：
- 協調邏輯轉移：由 Broker 端的
GroupCoordinator統一調度，消費者僅需上報狀態，無需全局同步。 - 增量分配：僅調整受影響的分區，未變更的分區可繼續消費。
- 容錯優化：局部故障僅觸發局部重平衡，避免全組停機。
性能對比與實測數據
指標 | 舊協議（Eager） | 新協議（Incremental） |
重平衡延遲（萬級組） | 60 秒 | <1 秒 |
資源消耗（CPU） | 高 | 降低 70% |
擴展上限 | 千級消費者 | 十萬級消費者 |
Kafka 4.0 引入了一種強大的新消費者組協議，旨在顯著提高重新平衡性能。
這種優化顯著減少了停機時間和延遲，增強了消費者組的可靠性和響應性，尤其是在大規模部署中。
點對點消息模型與共享組
傳統上，Kafka 主要采用發布-訂閱模式，消費者組模式下，分區需與消費者一一綁定，如下圖所示。
圖片
無法實現多消費者協同處理同一分區消息，消費者數量不能超過分區數量——最多為一對一。
如下圖所示，Consumer 5 無法處理 Topic 消息。
圖片
而在某些特定場景下，如點對點的消息傳遞、任務分配等，傳統的隊列語義更具優勢。
Kafka 4.0 通過引入“隊列”功能，共享組（Share Group），允許多消費者同時處理同一分區消息，實現點對點消費模式。
圖片
特性 | 傳統消費者組 | 共享組 |
并行消費 | 分區數=消費者數 | 消費者數>分區數 |
消息確認 | 偏移量提交 | 逐條 ACK/NACK |
投遞語義 | At-Least-Once | Exactly-Once（可選） |
主要特點：
- 支持傳統隊列場景：適用于需要保證消息嚴格順序且僅由一個消費者處理的場景。
- 提升資源利用率：共享組機制使得多個消費者能夠動態地共享分區資源，提高了系統資源的利用率和整體吞吐量。
- 簡化架構設計：開發者無需在 Kafka 與其他專門的隊列系統之間進行復雜的集成和數據遷移。
共享組（Share Group）機制
Kafka 4.0 通過共享組實現隊列語義，關鍵技術包括：
- 多消費者協同消費：同一分區的消息可由多個消費者并行處理，突破分區數限制。
- 記錄級鎖機制：每條消息被消費時加鎖（TTL 控制），防止重復處理。
- ACK/NACK 語義：支持逐條確認（Exactly-Once）或重試（At-Least-Once）。
移除舊協議 API 版本，提升系統性能
Kafka 一直以來都致力于兼容各個版本的協議 API，但隨著時間的推移，維護大量舊版本的協議 API 帶來了許多不必要的復雜性和成本。
在 Kafka 4.0 中，舊版本的協議 API 被徹底移除，系統基準協議直接提升至 Kafka 2.1 版本。
改進點：
- 簡化代碼：去除了歷史包袱，簡化了代碼結構，統一
KafkaProducer與KafkaConsumer接口，減少冗余配置項，減少了測試難度。 - 提高性能：去除了對舊協議 API 的支持，使得系統性能得到了顯著提升。廢棄 Kafka 2.1 之前的所有 API（如
MessageFormatterv0）
值得注意的是，在 Kafka 4.0 中，Kafka 客戶端和 Kafka Streams 需要 Java 11，而 Kafka Brokers,Connect 和工具現在需要 Java 17。
其他改進
Kafka 4.0 的其他新變化：
- 動態配置優化：
- 自動線程調整：
num.io.threads根據 CPU 核數動態分配，提升資源利用率。 - 時間窗口偏移量：支持從特定時間點（如 24 小時前）開始消費，替代固定偏移量。
- 安全性增強：OAuth 2.0 集成，支持基于 Token 的鑒權，替代 SASL/PLAIN；審計日志：記錄所有元數據操作，滿足金融級合規要求。
總結
Kafka 4.0 通過徹底擺脫 ZooKeeper，全面采用 KRaft 模式，不僅簡化了部署和維護工作，還顯著提升了系統的性能和穩定性。
同時，新一代消費者重平衡協議和隊列功能的引入，為開發者提供了更為靈活和高效的消息處理模式。
這些架構革新使得 Kafka 4.0 成為了一個更加獨立、高效和易用的分布式消息系統，為未來的發展奠定了堅實的基礎。
