Kafka 為什麼要拋棄Zookeeper？
在曾經很長一段時間裡，ZooKeeper都是Kafka的標配，現如今，Kafka官方已經在慢慢去除ZooKeeper，Kafka 為什麼要拋棄Zookeeper？這篇文章我們來聊聊其中的緣由。
Kafka 和ZooKeeper 的關係
ZooKeeper 是一個分散式協調服務，常用於管理設定、命名和同步服務。長期以來，Kafka 使用ZooKeeper 負責管理叢集元資料、控制器選舉和消費者群組協調等任務理，包括主題、分區資訊、ACL（存取控制清單）等。
ZooKeeper 為Kafka 提供了選主（leader election）、叢集成員管理等核心功能，為Kafka提供了一個可靠的分散式協調服務，使得Kafka能夠在多個節點之間進行有效的通訊和管理。然而，隨著Kafka的發展，其對ZooKeeper的依賴逐漸顯露出一些問題，這些問題也是以下Kafka去除Zookeeper的原因。
拋棄ZooKeeper的原因
(1) 複雜度增加
ZooKeeper 是獨立於Kafka 的外部元件，需要單獨部署和維護，因此，使用ZooKeeper 使得Kafka的維運複雜度大幅提升。維運團隊必須同時管理兩個分散式系統（Kafka和ZooKeeper），這不僅增加了管理成本，也要求維運人員具備更高的技術能力。
(2) 效能瓶頸
作為一個協調服務，ZooKeeper 並非專門為高負載場景設計， 因此，隨著叢集規模擴大，ZooKeeper在處理元資料時的效能問題日益突出。例如，當分區數量增加時，ZooKeeper需要儲存更多的信息，這導致了監聽延遲增加，從而影響Kafka的整體效能34。在高負載情況下，ZooKeeper可能成為系統的瓶頸，限制了Kafka的擴展能力。
(3) 一致性問題
Kafka 內部的分散式一致性模型與ZooKeeper 的一致性模型有所不同。由於ZooKeeper和Kafka控制器之間的資料同步機制不夠高效，可能導致狀態不一致，特別是在處理叢集擴展或不可用情境時，這種不一致性會影響訊息傳遞的可靠性和系統穩定性。
(4) 發展自己的生態
Kafka 拋棄ZooKeeper，我個人覺得最核心的原因是：Kafka生態強大了，需要自立門戶，這樣就不會被別人卡脖子。縱觀國內外，有很多這樣鮮活的例子，當自己弱小時，會先選擇使用別家的產品，當自己羽翼豐滿時，再選擇自建完善自己的生態圈。
引入KRaft
為了剝離和去除ZooKeeper，Kafka 引入了自己的親兒子KRaft（Kafka Raft Metadata Mode）。 KRaft 是一個新的元資料管理架構，基於Raft 一致性演算法實現的內建元資料管理方式，旨在取代ZooKeeper 的元資料管理功能。其優勢在於：
- 完全內置，自包含：KRaft 將所有協調服務嵌入Kafka 自身，不再依賴外部系統，這大大簡化了部署和管理，因為管理員只需關注Kafka 叢集。
- 高效的一致性協定：Raft 是一種簡潔且易於理解的一致性演算法，易於調試和實作。 KRaft 利用Raft 協定實現了強一致性的元資料管理，優化了複製機制。
- 提高元資料操作的擴展性：新的架構允許更多的並發操作，並減少了因為擴展性問題導致的瓶頸，特別是在高負載場景中。
- 降低延遲：在消除ZooKeeper 作為中間層之後，Kafka 的延遲效能有望得到改善，特別是在涉及選主和元資料更新的場景中。
- 完全自主：因為是自家產品，所以產品的架構設計，程式碼開發都可以自己說了算，未來架構走向完全控制在自己手上。
KRaft的設計細節
控制器（Controller）節點的去中心化：KRaft 模式中，控制器節點由一組Kafka 服務流程取代，而不是一個獨立的ZooKeeper 叢集。這些節點共同負責管理叢集的元數據，透過Raft 實現資料的一致性。
- 日誌複製和復原機制：利用Raft 的日誌複製和狀態機應用機制，KRaft 實現了對元資料變更的強一致性支持，這意味著所有控制器節點都能夠就叢集狀態達成共識。
- 動態叢集管理：KRaft 允許動態地向叢集中新增或移除節點，而無需手動前往ZooKeeper 中更新配置，這使得叢集管理更為便利。
下面給出一張Zookeeper 和KRaft的比較圖：
總結
本文，我們分析了為什麼Kafka 要移除ZooKeeper，主要原因有兩個：ZooKeeper無法滿足Kafka的發展以及Kafka想創造自己的生態。在面臨越來越複雜的資料流處理需求時，KRaft 模式為Kafka 提供了更有效率、簡潔的架構方案。不論結局如何，Kafka 和ZooKeeper曾經也度過了一段美好的蜜月期，祝福Kafka 在KRaft模式越來越強大，為使用者帶來更好的體驗。