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 依賴。其核心原理如下：

1. 元數據自管理：基于 Raft 共識算法，將元數據存儲于內置的__cluster_metadata主題中，由 Controller 節點（通過選舉產生）統一管理。

2. 日志復制機制：所有 Broker 作為 Raft 協議的 Follower，實時復制 Controller 的元數據日志，確保強一致性。

3. 快照與恢復：定期生成元數據快照，避免日志無限增長，故障恢復時間從 ZK 時代的分鐘級優化至秒級。

我們可以看出 KRaft 替換 ZK，并不是元數據存儲重新造輪子，而核心是集群協調機制的演進。

整個通信協調機制本質上是事件驅動模型，也就是 Metadata as an Event Log，Leader 通過 KRaft 生產權威的事件，Follower 和 Broker 通過監聽 KRaft 來獲得這些事件，并且順序處理事件，達到集群狀態和期望的最終一致。

新一代消費者重平衡協議

傳統消費者組采用Eager Rebalance 協議，存在兩大瓶頸：

1. 全局同步屏障（Stop-the-World）：任何成員變更（如擴容、故障）都會觸發全組暫停，導致分鐘級延遲。

2. 擴展性差：消費者數量受限于分區數，萬級消費者組重平衡耗時高達數分鐘。

Kafka 4.0 引入增量式重平衡協議（KIP-848），核心改進包括：

1. 協調邏輯轉移：由 Broker 端的GroupCoordinator統一調度，消費者僅需上報狀態，無需全局同步。

2. 增量分配：僅調整受影響的分區，未變更的分區可繼續消費。

3. 容錯優化：局部故障僅觸發局部重平衡，避免全組停機。

性能對比與實測數據

指標	舊協議（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 通過共享組實現隊列語義，關鍵技術包括：

1. 多消費者協同消費：同一分區的消息可由多個消費者并行處理，突破分區數限制。

2. 記錄級鎖機制：每條消息被消費時加鎖（TTL 控制），防止重復處理。

3. 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（如MessageFormatter v0）

值得注意的是，在 Kafka 4.0 中，Kafka 客戶端和 Kafka Streams 需要 Java 11，而 Kafka Brokers,Connect 和工具現在需要 Java 17。

其他改進

Kafka 4.0 的其他新變化：

1. 動態配置優化：

   1. 自動線程調整：num.io.threads根據 CPU 核數動態分配，提升資源利用率。

   2. 時間窗口偏移量：支持從特定時間點（如 24 小時前）開始消費，替代固定偏移量。

2. 安全性增強：OAuth 2.0 集成，支持基于 Token 的鑒權，替代 SASL/PLAIN；審計日志：記錄所有元數據操作，滿足金融級合規要求。

總結

Kafka 4.0 通過徹底擺脫 ZooKeeper，全面采用 KRaft 模式，不僅簡化了部署和維護工作，還顯著提升了系統的性能和穩定性。

同時，新一代消費者重平衡協議和隊列功能的引入，為開發者提供了更為靈活和高效的消息處理模式。

這些架構革新使得 Kafka 4.0 成為了一個更加獨立、高效和易用的分布式消息系統，為未來的發展奠定了堅實的基礎。