Apache Kafka內部刪除了對ZooKeeper的依賴

banq發表於2020-05-17
ApacheKafka

Apache Kafka使用Apache ZooKeeper儲存其後設資料，ZooKeeper有什麼問題呢？實際上，問題不在於ZooKeeper本身，而在於外部後設資料管理的概念。

有兩個系統會導致很多重複。畢竟，Kafka是複製的分散式日誌，其頂部是pub / sub API。ZooKeeper是一個複製的分散式日誌，頂部是檔案系統API。每個都有其自己的網路通訊，安全性，監視和配置方式。使用兩個系統會使維護人員的結果總複雜度大約翻倍。這導致不必要的陡峭學習曲線，並增加了某些配置錯誤導致安全漏洞的風險。

在外部儲存後設資料不是很有效。我們至少執行三個附加的Java程式，有時還要執行更多。實際上，我們經常看到Kafka叢集的ZooKeeper節點與Kafka節點一樣多！此外，ZooKeeper中的資料也需要反映在Kafka控制器上，這會導致雙重快取。

更糟糕的是，在外部儲存後設資料限制了Kafka的可伸縮性。當Kafka叢集啟動或選擇新的控制器時，控制器必須從ZooKeeper載入叢集的完整狀態。隨著後設資料量的增加，此載入過程的時間也隨之增加。這限制了Kafka可以儲存的分割槽數量。

最後，將後設資料儲存在外部會增加控制器的記憶體狀態與外部狀態不同步的可能性。控制器的活動檢視（位於群集中）也可以與ZooKeeper的檢視不同。

KIP-500
KIP-500概述了在Kafka中處理後設資料的更好方法。您可以將其稱為“ Kafka on Kafka”，因為它涉及將Kafka的後設資料儲存在Kafka本身中，而不是儲存在諸如ZooKeeper之類的外部系統中。
在後KIP-500時代，後設資料將儲存在Kafka內的分割槽中，而不是儲存在ZooKeeper中。控制器將成為該分割槽的負責人。僅Kafka本身就不會配置和管理外部後設資料系統。
我們將後設資料視為日誌。需要最新更新的代理只能讀取日誌的末尾。這類似於需要最新日誌條目的使用者僅需要讀取日誌的最後而不是整個日誌的方式。經紀人還將能夠在整個流程重啟期間保留其後設資料快取。

 

相關文章