Apache Kafka 4.0 的釋出是一個重要的里程碑，本次大版本更新引入了大量的新功能和改進，其中最引人注目的是 KRaft 模式下的預設操作，根據 Confluent 的文件，它消除了對 Apache ZooKeeper 的依賴。
十多年來，ZooKeeper 一直是 Kafka 的支柱，社群感謝了它的貢獻。然而，Kafka 4.0 預設採用 KRaft，無需再單獨維護 ZooKeeper 元件，簡化了部署和管理。
圖片來源：Confluent 文件）
AWS 社群建設者 Lalit Moharana 在 LinkedIn 上發帖：
隨著 Apache Kafka 在即將釋出的 Kafka 4.0 中採用 KRaft，ZooKeeper 將退居二線，這標誌著這段長達 14 年的合作關係即將結束。這一轉變簡化了 Kafka 的架構，拋棄了獨立的 ZooKeeper 系統，提高了可擴充套件性，併為自給自足的未來鋪平了道路 —— 這一切都要歸功於 KRaft 的 Raft 協議。
此外：
為什麼要改變？ZooKeeper 的開銷和限制（10 萬多個分割槽）跟不上 Kafka 的增長。還有：KRaft 的優勢：一個系統，數以百萬計的分割槽，更快的恢復 —— Kafka 已經準備好翱翔藍天！
除了架構上的轉變，Kafka 4.0 還正式引入了下一代消費者組協議 KIP-848 。這一新協議旨在大幅提高再平衡效能，減少消費者組的停機時間和延遲，尤其是在大規模環境中。透過最大限度地減少“停止世界（stop-the-world）”的再平衡，Kafka 旨在提供更穩定、響應更快的資料流體驗。在伺服器端，新協議預設啟用，消費者端則需要透過設定 group.protocol=consumer 進行選用。
在 Hacker News 上的一個討論 中，一位回覆者評論道：
從 SNS/SQS 切換到 Kafka 後，我立即注意到了一件事，那就是它的速度。訊息幾乎可以立即傳送 / 接收。
此外，Kafka 4.0 還提供了 Queues for Kafka（KIP-932）的早期試用。該功能引入了“共享組（share group）”的概念，可以使用常規的 Kafka 主題實現協同消費，從而讓 Kafka 可以有效地支援傳統的佇列語義。雖然不是直接新增“佇列”資料結構，但這一增強功能提高了 Kafka 的多功能性，使其適用於更廣泛的訊息傳遞用例，特別是那些需要類似於持久共享訂閱的點對點訊息傳遞模式的。
在 LinkedIn 上的一篇文章中，IBM 人工智慧與資料工程負責人 Govindan Gopalan 總結道：
早期佇列支援（KIP-932）引入了點對點訊息傳遞，將 Kafka 的用例擴充套件到了傳統的釋出 – 訂閱工作流之外。
這一大版本標誌著 Kafka 向平臺現代化邁出了重要的一步。作為演進的一部分，Kafka 4.0 刪除了已廢棄 12 個月以上的 API。此外，它還更新了最低 Java 要求，Kafka Clients 和 Kafka Streams 現在需要 Java 11，而 Kafka Brokers、Connect 和 Tools 則需要 Java 17。這一舉措旨在鼓勵採用較新的 Java 特性，並使 Kafka 與當前其他的技術棧保持一致。該版本還更新了支援的最低客戶端和代理版本（KIP-896），併為支援的升級路徑定義了新的基線要求，詳見 KIP-1124。
原文連結：
https://www.infoq.com/news/2025/04/kafka-4-kraft-architecture/
宣告：本文為 InfoQ 翻譯，未經許可禁止轉載。