在曾經(jīng)很長一段時間里，ZooKeeper都是 Kafka的標配，現(xiàn)如今，Kafka官方已經(jīng)在慢慢去除ZooKeeper，Kafka 為什么要拋棄 Zookeeper？這篇文章我們來聊聊其中的緣由。

Kafka 和 ZooKeeper 的關系

ZooKeeper 是一個分布式協(xié)調服務，常用于管理配置、命名和同步服務。長期以來，Kafka 使用 ZooKeeper 負責管理集群元數(shù)據(jù)、控制器選舉和消費者組協(xié)調等任務理，包括主題、分區(qū)信息、ACL（訪問控制列表）等。

ZooKeeper 為 Kafka 提供了選主（leader election）、集群成員管理等核心功能，為 Kafka提供了一個可靠的分布式協(xié)調服務，使得 Kafka能夠在多個節(jié)點之間進行有效的通信和管理。然而，隨著 Kafka的發(fā)展，其對 ZooKeeper的依賴逐漸顯露出一些問題，這些問題也是下面 Kafka去除 Zookeeper的原因。

拋棄ZooKeeper的原因

(1) 復雜性增加

ZooKeeper 是獨立于 Kafka 的外部組件，需要單獨部署和維護，因此，使用 ZooKeeper 使得 Kafka的運維復雜度大幅提升。運維團隊必須同時管理兩個分布式系統(tǒng)（Kafka和 ZooKeeper），這不僅增加了管理成本，也要求運維人員具備更高的技術能力。

(2) 性能瓶頸

作為一個協(xié)調服務，ZooKeeper 并非專門為高負載場景設計， 因此，隨著集群規(guī)模擴大，ZooKeeper在處理元數(shù)據(jù)時的性能問題日益突出。例如，當分區(qū)數(shù)量增加時，ZooKeeper需要存儲更多的信息，這導致了監(jiān)聽延遲增加，從而影響Kafka的整體性能34。在高負載情況下，ZooKeeper可能成為系統(tǒng)的瓶頸，限制了Kafka的擴展能力。

(3) 一致性問題

Kafka 內部的分布式一致性模型與 ZooKeeper 的一致性模型有所不同。由于 ZooKeeper和 Kafka控制器之間的數(shù)據(jù)同步機制不夠高效，可能導致狀態(tài)不一致，特別是在處理集群擴展或不可用情景時，這種不一致性會影響消息傳遞的可靠性和系統(tǒng)穩(wěn)定性。

(4) 發(fā)展自己的生態(tài)

Kafka 拋棄 ZooKeeper，我個人覺得最核心的原因是：Kafka生態(tài)強大了，需要自立門戶，這樣就不會被別人卡脖子。縱觀國內外，有很多這樣鮮活的例子，當自己弱小時，會先選擇使用別家的產(chǎn)品，當自己羽翼豐滿時，再選擇自建完善自己的生態(tài)圈。

引入KRaft

為了剝離和去除 ZooKeeper，Kafka 引入了自己的親兒子 KRaft（Kafka Raft Metadata Mode）。KRaft 是一個新的元數(shù)據(jù)管理架構，基于 Raft 一致性算法實現(xiàn)的一種內置元數(shù)據(jù)管理方式，旨在替代 ZooKeeper 的元數(shù)據(jù)管理功能。其優(yōu)勢在于：

• 完全內置，自包含：KRaft 將所有協(xié)調服務嵌入 Kafka 自身，不再依賴外部系統(tǒng)，這樣大大簡化了部署和管理，因為管理員只需關注 Kafka 集群。
• 高效的一致性協(xié)議：Raft 是一種簡潔且易于理解的一致性算法，易于調試和實現(xiàn)。KRaft 利用 Raft 協(xié)議實現(xiàn)了強一致性的元數(shù)據(jù)管理，優(yōu)化了復制機制。
• 提高元數(shù)據(jù)操作的擴展性：新的架構允許更多的并發(fā)操作，并減少了因為擴展性問題導致的瓶頸，特別是在高負載場景中。
• 降低延遲：在消除 ZooKeeper 作為中間層之后，Kafka 的延遲性能有望得到改善，特別是在涉及選主和元數(shù)據(jù)更新的場景中。
• 完全自主：因為是自家產(chǎn)品，所以產(chǎn)品的架構設計，代碼開發(fā)都可以自己說了算，未來架構走向完全控制在自己手上。

KRaft的設計細節(jié)

控制器（Controller）節(jié)點的去中心化：KRaft 模式中，控制器節(jié)點由一組 Kafka 服務進程代替，而不是一個獨立的 ZooKeeper 集群。這些節(jié)點共同負責管理集群的元數(shù)據(jù)，通過 Raft 實現(xiàn)數(shù)據(jù)的一致性。

• 日志復制和恢復機制：利用 Raft 的日志復制和狀態(tài)機應用機制，KRaft 實現(xiàn)了對元數(shù)據(jù)變更的強一致性支持，這意味著所有控制器節(jié)點都能夠就集群狀態(tài)達成共識。
• 動態(tài)集群管理：KRaft 允許動態(tài)地向集群中添加或移除節(jié)點，而無需手動去 ZooKeeper 中更新配置，這使得集群管理更為便捷。

下面給出一張 Zookeeper 和 KRaft的對比圖：

總結

本文，我們分析了為什么 Kafka 要移除 ZooKeeper，主要原因有兩個：ZooKeeper不能滿足 Kafka的發(fā)展以及 Kafka想創(chuàng)建自己的生態(tài)。在面臨越來越復雜的數(shù)據(jù)流處理需求時，KRaft 模式為 Kafka 提供了一種更高效、簡潔的架構方案。不論結局如何，Kafka 和 ZooKeeper曾經(jīng)也度過了一段美好的蜜月期，祝福 Kafka 在 KRaft模式越來越強大，為使用者帶來更好的體驗。