事件溯源概念深入人心：Kafka將拋棄ZooKeeper，替換為自我管理的後設資料仲裁

banq發表於2019-08-05
事件Kafka

這是Kafka的KIP-500提案，目前，Kafka使用ZooKeeper儲存有關分割槽和代理的後設資料，並選擇其作為Kafka控制器的代理。我們想要刪除對ZooKeeper的這種依賴。這將使我們能夠以更具可擴充套件性和可靠性的方式管理後設資料，從而支援更多分割槽。它還將簡化Kafka的部署和配置。
將狀態作為一系列事件進行管理由很多好處。在Kafka中，偏移量指標指示資料流中的位置。多個消費者只需重播比當前偏移量更新的所有事件即可，這樣可以獲得最新狀態。日誌已經在事件之間建立明確的順序，並確保消費者始終沿著單個時間線移動。
然而，儘管我們的使用者享受這些好處，但卡夫卡本身也被排除在外。我們將後設資料的更改視為孤立的更改，彼此之間沒有任何關係。當控制器將狀態更改通知（例如LeaderAndIsrRequest）推送到叢集中的其他節點時，節點可能會獲得一些更改，但不是全部。雖然控制器重試幾次，但它最終會放棄。這可能使叢集中各個節點處於不同的狀態。
更糟糕的是，儘管ZooKeeper是記錄儲存，但ZooKeeper中的狀態通常與控制器記憶體中儲存的狀態不匹配。例如，當分割槽負責人在ZK中更改其ISR時，控制器通常在好幾秒內還不瞭解這些更改。控制器沒有通用的方法來遵循ZooKeeper事件日誌。
後設資料應該儲存在Kafka本身，而不是儲存在單獨的系統中。這將避免與控制器狀態和Zookeeper狀態之間的差異相關的所有問題。節點之間應該只從事件日誌中消費後設資料事件，而不是向其他節點推送通知。這可確保後設資料更改始終以相同的順序到達。節點將能夠在檔案中本地儲存後設資料。當他們啟動時，他們只需要讀取控制器發生的變化，而不是完整狀態。這將讓我們以更少的CPU消耗支援更多分割槽。

評論：Zebee已經根據EventSourcing實現了全新的訊息代理：如何使用Zebee構建高度可擴充套件的分散式工作流中介軟體？
 

相關文章