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

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

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

KRaft 全面替代 ZooKeeper

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

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

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

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

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

圖片

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

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

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

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

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

圖片

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

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

圖片

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

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

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

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

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

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

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

性能對(duì)比與實(shí)測(cè)數(shù)據(jù)

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

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

點(diǎn)對(duì)點(diǎn)消息模型與共享組

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

圖片

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

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

圖片

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

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

圖片

主要特點(diǎn)：

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

共享組（Share Group）機(jī)制

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

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

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

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

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

改進(jìn)點(diǎn)：

• 簡化代碼：去除了歷史包袱，簡化了代碼結(jié)構(gòu)，統(tǒng)一KafkaProducer與KafkaConsumer接口，減少冗余配置項(xiàng)，減少了測(cè)試難度。
• 提高性能：去除了對(duì)舊協(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. 動(dòng)態(tài)配置優(yōu)化：

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

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

總結(jié)

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

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

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