2025 年 3 月，Apache Kafka 迎來了具有劃時代意義的 4.0 版本。這一版本不僅是技術(shù)架構(gòu)的全面革新，更是功能場景的深度拓展。

碼哥第一時間對 4.0 版本分析，為大家深度解讀 Kafka 4.0 的核心特性，以下是碼哥認(rèn)為比較重要的特性：

1. KRaft 全面替代 ZooKeeper
2. 新一代消費者重平衡協(xié)議
3. 點對點消息模型與共享組
4. 移除舊協(xié)議 API 版本，提升系統(tǒng)性能

KRaft 全面替代 ZooKeeper

Apache Kafka 4.0 是一個重要的里程碑，標(biāo)志著第一個完全無需 Apache ZooKeeper? 運行的主要版本。

通過默認(rèn)運行在 KRaft 模式下，Kafka 簡化了部署和管理，消除了維護(hù)單獨 ZooKeeper 集群的復(fù)雜性。

這一變化顯著降低了運營開銷，增強了可擴展性，并簡化了管理任務(wù)。

舊架構(gòu)痛點回顧

在 Kafka 3.x 及更早版本中，ZooKeeper（ZK）是元數(shù)據(jù)管理的核心組件，負(fù)責(zé) Broker 注冊、Topic 分區(qū)分配、控制器選舉等關(guān)鍵任務(wù)，如圖所示。

圖片

然而，這種設(shè)計存在顯著問題：

• 運維復(fù)雜度高：需獨立維護(hù) ZK 集群，占用額外資源且增加故障點。
• 性能瓶頸明顯：元數(shù)據(jù)操作依賴 ZK 的原子廣播協(xié)議（ZAB），大規(guī)模集群（如萬級分區(qū)）下元數(shù)據(jù)同步延遲可達(dá)秒級。
• 擴展性受限：ZK 的寫性能隨節(jié)點數(shù)增加而下降，限制 Kafka 集群規(guī)模。

KRaft 模式的技術(shù)實現(xiàn)

Apache Kafka Raft（KRaft）是在 KIP-500 中引入的共識協(xié)議，用于移除 Apache Kafka 對 ZooKeeper 進(jìn)行元數(shù)據(jù)管理的依賴。這通過將元數(shù)據(jù)管理的責(zé)任集中在 Kafka 本身，而不是在兩個不同的系統(tǒng)（ZooKeeper 和 Kafka）之間分割，從而大大簡化了 Kafka 的架構(gòu)。

KRaft 模式利用 Kafka 中的新法定多數(shù)控制器服務(wù)，取代了之前的控制器，并使用基于事件的 Raft 共識協(xié)議的變體。

圖片

Kafka 4.0 默認(rèn)啟用KRaft 模式（Kafka Raft），完全摒棄 ZK 依賴。其核心原理如下：

1. 元數(shù)據(jù)自管理：基于 Raft 共識算法，將元數(shù)據(jù)存儲于內(nèi)置的__cluster_metadata主題中，由 Controller 節(jié)點（通過選舉產(chǎn)生）統(tǒng)一管理。
2. 日志復(fù)制機制：所有 Broker 作為 Raft 協(xié)議的 Follower，實時復(fù)制 Controller 的元數(shù)據(jù)日志，確保強一致性。
3. 快照與恢復(fù)：定期生成元數(shù)據(jù)快照，避免日志無限增長，故障恢復(fù)時間從 ZK 時代的分鐘級優(yōu)化至秒級。

圖片

我們可以看出 KRaft 替換 ZK，并不是元數(shù)據(jù)存儲重新造輪子，而核心是集群協(xié)調(diào)機制的演進(jìn)。

整個通信協(xié)調(diào)機制本質(zhì)上是事件驅(qū)動模型，也就是 Metadata as an Event Log，Leader 通過 KRaft 生產(chǎn)權(quán)威的事件，F(xiàn)ollower 和 Broker 通過監(jiān)聽 KRaft 來獲得這些事件，并且順序處理事件，達(dá)到集群狀態(tài)和期望的最終一致。

新一代消費者重平衡協(xié)議

傳統(tǒng)消費者組采用Eager Rebalance 協(xié)議，存在兩大瓶頸：

1. 全局同步屏障（Stop-the-World）：任何成員變更（如擴容、故障）都會觸發(fā)全組暫停，導(dǎo)致分鐘級延遲。
2. 擴展性差：消費者數(shù)量受限于分區(qū)數(shù)，萬級消費者組重平衡耗時高達(dá)數(shù)分鐘。

Kafka 4.0 引入增量式重平衡協(xié)議（KIP-848），核心改進(jìn)包括：

1. 協(xié)調(diào)邏輯轉(zhuǎn)移：由 Broker 端的GroupCoordinator統(tǒng)一調(diào)度，消費者僅需上報狀態(tài)，無需全局同步。
2. 增量分配：僅調(diào)整受影響的分區(qū)，未變更的分區(qū)可繼續(xù)消費。
3. 容錯優(yōu)化：局部故障僅觸發(fā)局部重平衡，避免全組停機。

性能對比與實測數(shù)據(jù)

Kafka 4.0 引入了一種強大的新消費者組協(xié)議，旨在顯著提高重新平衡性能。

這種優(yōu)化顯著減少了停機時間和延遲，增強了消費者組的可靠性和響應(yīng)性，尤其是在大規(guī)模部署中。

點對點消息模型與共享組

傳統(tǒng)上，Kafka 主要采用發(fā)布-訂閱模式，消費者組模式下，分區(qū)需與消費者一一綁定，如下圖所示。

圖片

無法實現(xiàn)多消費者協(xié)同處理同一分區(qū)消息，消費者數(shù)量不能超過分區(qū)數(shù)量——最多為一對一。

如下圖所示，Consumer 5 無法處理 Topic 消息。

圖片

而在某些特定場景下，如點對點的消息傳遞、任務(wù)分配等，傳統(tǒng)的隊列語義更具優(yōu)勢。

Kafka 4.0 通過引入“隊列”功能，共享組（Share Group），允許多消費者同時處理同一分區(qū)消息，實現(xiàn)點對點消費模式。

圖片

主要特點：

• 支持傳統(tǒng)隊列場景：適用于需要保證消息嚴(yán)格順序且僅由一個消費者處理的場景。
• 提升資源利用率：共享組機制使得多個消費者能夠動態(tài)地共享分區(qū)資源，提高了系統(tǒng)資源的利用率和整體吞吐量。
• 簡化架構(gòu)設(shè)計：開發(fā)者無需在 Kafka 與其他專門的隊列系統(tǒng)之間進(jìn)行復(fù)雜的集成和數(shù)據(jù)遷移。

共享組（Share Group）機制

Kafka 4.0 通過共享組實現(xiàn)隊列語義，關(guān)鍵技術(shù)包括：

1. 多消費者協(xié)同消費：同一分區(qū)的消息可由多個消費者并行處理，突破分區(qū)數(shù)限制。
2. 記錄級鎖機制：每條消息被消費時加鎖（TTL 控制），防止重復(fù)處理。
3. ACK/NACK 語義：支持逐條確認(rèn)（Exactly-Once）或重試（At-Least-Once）。

移除舊協(xié)議 API 版本，提升系統(tǒng)性能

Kafka 一直以來都致力于兼容各個版本的協(xié)議 API，但隨著時間的推移，維護(hù)大量舊版本的協(xié)議 API 帶來了許多不必要的復(fù)雜性和成本。

在 Kafka 4.0 中，舊版本的協(xié)議 API 被徹底移除，系統(tǒng)基準(zhǔn)協(xié)議直接提升至 Kafka 2.1 版本。

改進(jìn)點：

• 簡化代碼：去除了歷史包袱，簡化了代碼結(jié)構(gòu)，統(tǒng)一KafkaProducer與KafkaConsumer接口，減少冗余配置項，減少了測試難度。
• 提高性能：去除了對舊協(xié)議 API 的支持，使得系統(tǒng)性能得到了顯著提升。廢棄 Kafka 2.1 之前的所有 API（如MessageFormatter v0）

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

其他改進(jìn)

Kafka 4.0 的其他新變化：

1. 動態(tài)配置優(yōu)化：

1. 自動線程調(diào)整：num.io.threads根據(jù) CPU 核數(shù)動態(tài)分配，提升資源利用率。
2. 時間窗口偏移量：支持從特定時間點（如 24 小時前）開始消費，替代固定偏移量。

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

總結(jié)

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

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

這些架構(gòu)革新使得 Kafka 4.0 成為了一個更加獨立、高效和易用的分布式消息系統(tǒng)，為未來的發(fā)展奠定了堅實的基礎(chǔ)。