點擊上方“朱小廝的博客”，選擇“設爲星標”
後臺回覆"加羣"，加入新技術
目前，Apache Kafka 使用 Apache ZooKeeper 來存儲它的元數據，比如分區的位置和主題的配置等數據就是存儲在 ZooKeeper 集羣中。在 2019 年社區提出了一個計劃[1]，以打破這種依賴關係，並將元數據管理引入 Kafka 本身。
所以 Apache Kafka 爲什麼要移除 Zookeeper 的依賴？Zookeeper 有什麼問題？實際上，問題不在於 ZooKeeper 本身，而在於外部元數據管理的概念。
擁有兩個系統會導致大量的重複。畢竟，Kafka 是一個分佈式的發佈-訂閱消息系統，而 ZooKeeper 其實也是一個分佈式日誌系統，其上有一個文件系統 API。每種方法都有自己的網絡通信、安全、監視和配置方法。如果同時使用這兩個系統，則系統的總體複雜性大約會增加一倍，這導致了不必要的學習曲線，並增加了錯誤配置導致安全漏洞的風險。
同時，在外部存儲元數據並不是很好的。我們至少需要運行三個額外的 Java 進程，有時甚至更多。事實上，我們經常看到具有與 Kafka 節點一樣多的 ZooKeeper 節點的 Kafka 集羣！此外，ZooKeeper 中的數據還需要緩存在 Kafka 控制器上，這導致了雙重緩存。
更糟糕的是，在外部存儲元數據限制了 Kafka 的可伸縮性。當 Kafka 集羣啓動時，或者一個新的控制器被選中時，控制器必須從 ZooKeeper 加載集羣的完整狀態。隨着元數據數量的增加，加載過程需要的時間也會增加，這限制了 Kafka 可以存儲的分區數量。
最後，將元數據存儲在外部會增加控制器的內存狀態與外部狀態不同步的可能性。控制器的活動視圖（位於羣集中）也可以從 ZooKeeper 的視圖中分離出來。
KIP-500
處理元數據（Handling metadata）
KIP-500 概述了在 Kafka 中處理元數據的更好方法。我們可以將其稱爲“ Kafka on Kafka”，因爲它涉及將 Kafka 的元數據存儲在 Kafka 本身中，而不是存儲在 ZooKeeper 之類的外部系統中。
在實現了 KIP-500 的系統，元數據將存儲在 Kafka 內的分區中，而不是存儲在 ZooKeeper。控制器將成爲該分區的 leader；除了 Kafka 本身，不需要配置和管理外部元數據系統。
我們將元數據視爲日誌。Brokers 如果需要最新的數據只能讀取日誌的末尾。這類似於需要最新日誌條目的使用者僅需要讀取日誌的最後而不是整個日誌的方式。Brokers 還可以在進程重新啓動時持久化它們的元數據緩存。
控制器體系結構
Kafka 集羣選擇一個控制器節點來管理分區 leaders 和集羣的元數據。我們擁有的分區和元數據越多，控制器的可伸縮性就越重要。我們希望最小化與主題或分區數量成線性比例的時間的操作數量。
其中一個操作是控制器故障轉移。當前，當 Kafka 選擇新控制器時，它需要在繼續之前加載整個集羣的狀態。隨着集羣元數據數量的增長，這個過程會花費越來越長的時間。
相比之下，在實現了 KIP-500 的系統，將會有幾個備用控制器，隨時準備在活動控制器掛掉時接管。這些備用控制器只是元數據分區的 Raft quorum 中的其他節點。這種設計確保了當選擇一個新的控制器時，我們永遠不需要經過漫長的加載過程。
KIP-500 將加快主題的創建和刪除。當前，創建或刪除主題時，控制器必須從 ZooKeeper 重新加載集羣中所有主題名稱的完整列表。這是必要的，因爲當 ZooKeeper 通知我們集羣中的主題集發生更改時，它不會確切地告訴我們添加或刪除了哪些主題。相反，在完全實現了 KIP-500 之後，創建或刪除主題只需要在元數據分區中創建一個新條目，這是 O(1）操作。
元數據可伸縮性是將來擴展 Kafka 的關鍵部分。我們期望單個 Kafka 集羣最終將能夠支持一百萬個分區或更多。
Roadmap
從 Kafka 的管理工具中刪除 ZooKeeper
Kafka 發行版中附帶的一些管理工具仍然允許與 ZooKeeper 直接通信。更糟糕的是，仍然有一兩個操作必須經過 ZooKeeper 的這種直接通信才能完成。
我們一直在努力縮小這些差距。不久之後，對於以前需要直接 ZooKeeper 訪問的每個操作，將都有一個公共的 Kafka API。我們還將在 Kafka 的下一個主要版本中禁用或刪除不必要的 ——zookeeper 標誌。
自我管理的元數據仲裁
在實現 KIP-500 之後，Kafka 控制器會將其元數據存儲在 Kafka 分區中，而不是存儲在 ZooKeeper 中。但是，由於控制器依賴於該分區，因此分區本身不能依賴控制器來進行領導者選舉之類的事情。所以管理此分區的節點必須實現自我管理的 Raft 仲裁。
KIP-595: A Raft Protocol for the Metadata Quorum[2] 概述了社區如何將 Raft 協議引入到 Kafka 中，以使能夠在 Kafka 中更好的工作。這將涉及將 Raft 論文[3] 中描述的基於推的模型更改爲基於拉的模型，這與傳統的 Kafka 複製是一致的。其他節點將連接到這些節點，而不是將數據推送到其他節點。同樣，我們將使用與 Kafka 一致的術語，使用 epochs 而不是原始 Raft 論文中的 terms 等等。
最初的實現將集中在支持元數據分區上。它不支持將常規分區轉換爲 Raft 所需的全部操作。但是，這是我們將來可能會談到的話題。
KIP-500 mode
當然，該項目最令人興奮的部分是在 “ KIP-500模式” 下無需 ZooKeeper 即可運行的能力。當 Kafka 在此模式下運行時，我們將使用 Raft 仲裁存儲元數據，而不是ZooKeeper。
最初，KIP-500 模式將是實驗性的。大多數用戶將繼續使用“傳統模式”，即仍然使用 ZooKeeper。部分原因是因爲 KIP-500 模式最初並不支持所有可能的功能。另一個原因是因爲我們希望在將其設置爲默認值之前，KIP-500 模式必須解決之前所有問題。最後，我們需要時間完善從傳統模式到 KIP-500 模式的升級過程。
啓用 KIP-500 模式的大部分工作將在控制器中進行。我們必須將控制器中與 ZooKeeper 交互的部分與實現更多通用邏輯(如複製集管理)的部分分離開來。
我們需要定義和實現更多的控制器API，以替換當前涉及 ZooKeeper 的通信機制。新的 AlterIsr API 就是一個例子。該 API 允許副本在不使用 ZooKeeper 的情況下將同步副本集中的更改通知控制器。
更新
KIP-500 引入了橋接發行版（bridge release）的概念，使用了這個功能使得 KIP-500 過渡期變得更好。Bridge 發行版非常重要，因爲它們可以讓用戶升級時零停機。使用 Kafka 老版本的用戶只需升級到 bridge 發行版即可。然後，再可以執行第二次升級到完全實現 KIP-500 的版本。正如它的名字所暗示的，橋接發行充當了通往新世界的橋樑。
總結
Kafka 是最活躍的 Apache 項目之一。在過去的幾年裏，它的架構發生了驚人的變化。正如 KIP-500 這樣的 ISSUE 所顯示的那樣，這種進化還沒有完成。我最喜歡KIP-500的地方在於，它簡化了整個體系結構，無論對於管理員還是開發人員而言。它將允許我們使用事件日誌的強大抽象來處理元數據，它最終會證明：Kafka 不需要管理員！
本文翻譯自：Apache Kafka Needs No Keeper: Removing the Apache ZooKeeper Dependency[4]
引用鏈接
[1] 計劃: https://cwiki.apache.org/confluence/display/KAFKA/KIP-500%3A+Replace+ZooKeeper+with+a+Self-Managed+Metadata+Quorum[2] KIP-595: A Raft Protocol for the Metadata Quorum: https://cwiki.apache.org/confluence/display/KAFKA/KIP-595%3A+A+Raft+Protocol+for+the+Metadata+Quorum[3] Raft 論文: https://raft.github.io/raft.pdf[4] Apache Kafka Needs No Keeper: Removing the Apache ZooKeeper Dependency: https://www.confluent.io/blog/removing-zookeeper-dependency-in-kafka/
想知道更多？掃描下面的二維碼關注我
後臺回覆”加羣“獲取公衆號專屬羣聊入口
噹噹618圖書優惠活動，每滿100-50，我這裏還有一批“實付滿200再減30”的優惠碼TEGNC6 ，囤書薅羊毛再走一波~~（使用時間：5月18~6月1日，使用渠道：噹噹小程序或噹噹APP）
朕已閱
