博文推薦|Apache Pulsar 輕裝上陣:邁向輕 ZooKeeper 時代

ApachePulsar發表於2022-04-06
本文翻譯自《Pulsar Isolation Part III: Separate Pulsar Clusters Sharing a Single BookKeeper Cluster》,原文連結:https://streamnative.io/blog/...。作者 David Kjerrumgaard,Apache Pulsar Committer,StreamNative 佈道師。

譯者簡介

李文奇,就職於微軟 STCA,業餘時間喜歡研究各類中介軟體技術及分散式系統。

首次!無 ZooKeeper 也能執行 Pulsar

Apache Pulsar™ 有時被視為一個較複雜的系統,有一部分原因是因為 Pulsar 使用了 Apache ZooKeeper™ 儲存後設資料。從設計之初,Plusar 就使用 ZooKeeper 儲存分配給 topic 的 broker 資訊、topic 的安全和資料留存策略等關鍵後設資料資訊。ZooKeeper 這個額外元件便加深了大家對於 Pulsar 是一個複雜系統的印象。

為了簡化 Pulsar 的部署,社群發起了一項計劃——Pulsar 改進規劃 PIP-45 來減輕對 ZooKeeper 的依賴,同時用可插拔的框架來替代。這種可插拔的框架支援使用者按照實際的部署環境選擇可替換的後設資料及協調系統,從而減少了 Pulsar 在基礎設施層面的必須依賴。

PIP- 45 的實現與未來計劃

PIP-45 的程式碼已經被提交到了主分支上,並即將於 Pulsar 2.10 版本釋出。Apache Pulsar 使用者首次可以在沒有 ZooKeeper 的情況下執行 Pulsar。

與 Apache Kafka 的 ZooKeeper 替換策略不同,PIP-45 的目的不是內部化 Apache Pulsar 平臺本身的分散式協調功能。相反,它允許使用者根據自身環境選用合適的技術元件來替換 ZooKeeper。

在非生產環境中,現在使用者可以選擇使用輕量級的替代方案,可將後設資料保留在記憶體中或者本地磁碟上。開發人員便可收回之前在其筆記本上執行 Apache ZooKeeper 所需的計算資源。

在生產環境中,Pulsar 的可插拔框架支援使用者利用那些早已在自身軟體技術棧中執行的元件作為 ZooKeeper 的替代方案。

可以想象,如此重大的計劃由多個步驟組成,目前其中一些已經實現。本文將帶您瀏覽迄今為止已實現的步驟(步驟 1-4),並概述仍需要完成的工作(步驟 5-6)。請注意,本文中討論的功能尚處於測試階段,在實際釋出版本中可能會有所變化。

第一步:定義後設資料儲存 API

PIP-45 為後設資料管理和分散式協調提供了一個跨技術元件的介面,從而允許使用非 ZooKeeper 的方式管理後設資料等,增加了系統的靈活性。

ZooKeeper 客戶端 API 歷來貫穿整個 Apache Pulsar 程式碼庫,因此我們首先需要通過單個通用的 MetadataStore 介面來整合所有這些 API 呼叫。該介面的構造是基於 Pulsar 在與後設資料間互動的需求以及一些由現有的後設資料儲存引擎(如 ZooKeeper 及 etcd)提供的場景語義。

 title=
圖 1:支援開發不同的 MetadataStore 介面實現方式,從而用介面來代替對 Apache ZooKeeper 的直接依賴,並提供了使用者根據自身環境選用的靈活性。

這一步不僅將 Pulsar 與 ZooKeeper API 進行了解耦,同時也構建了一種可插拔框架,這樣不同的介面實現便能在開發環境中互相替換。

這些新介面允許 Pulsar 使用者根據 broker 配置檔案中的 metadataURL 屬性值輕鬆地將 Apache ZooKeeper 替換為其他後設資料管理系統或其他協調服務。這套框架會根據 URL 的字首自動產生正確的例項。例如,如果 metadataURL 配置屬性值以 Rocksdb:// 開頭,則將使用 RocksDB 作為介面的實現。

第二步:建立基於 ZooKeeper 的實現

一旦定義了這些介面,會建立一個基於 Apache ZooKeeper 的預設實現,以便為現有的 Pulsar 平穩過渡到新的可插拔框架。

這一階段我們的主要目標是對於那些想保留 Apache ZooKeeper 的使用者,防止因 Pulsar 升級到新版本而產生任何重大的變更。因此,我們需要確保當前儲存在 ZooKeeper 中的現有後設資料在升級後也可以儲存在與以前相同的位置和相同的格式中。

基於 ZooKeeper 的實現允許使用者繼續選擇使用 ZooKeeper 作為後設資料儲存層,並且在 etcd 版本完成以前,這是目前唯一在生產環境中可用的實現方式。

第三步:建立基於 RocksDB 的實現

在解決了這些向後相容問題之後,下一步是提供不基於 ZooKeeper 的實現方式,以展示框架的可插拔性。驗證該框架的最簡單方式是在單機模式(standalone 模式)下基於 RocksDB 實現 MetaDataStore。

這不僅證明該框架具有在不同 MetaDataStore 實現方式切換的能力,同時也能大大減少完整執行完全獨立的 Pulsar 叢集所需的資源總量。該步驟的實現對選擇在本地(通常是 Docker 容器)進行開發和測試的開發者們有直接的影響。

第四步:建立基於記憶體的實現

縮減後設資料儲存也對單元與整合測試大有裨益。我們發現,MetaDataStore 的記憶體實現更加適合測試場景,這就減少了反覆啟動 ZooKeeper 叢集以執行一套測試然後將其關閉的成本。

同時,不僅能夠減少執行 Pulsar 全套整合測試所需的資源量,而且還能夠減少測試的時間。

通過利用 MetaDataStore 的記憶體實現,Pulsar 專案的構建和釋出週期將會大大縮減,構建、測試和釋出也能夠更快地變更到社群。

第五步:建立基於 Etcd 的實現

鑑於 Pulsar 雲原生的設計架構,ZooKeeper 最明顯的替代者便是 etcd。etcd 是一致性、高可用的鍵值儲存系統,用作 Kubernetes 的所有叢集後設資料的儲存。

除了其社群不斷擴大且活躍,專案的廣泛使用,以及效能和可擴充套件性的改進之外,作為控制面的一部分,etcd 早已在 Kubernetes 中可用。由於 Pulsar 天然支援在 Kubernetes 內執行,在大多數生產環境中都可以直接訪問到執行的 etcd 例項,因此使用者可以直接使用已有的 etcd,而不會額外增加 ZooKeeper 帶來更多運營成本。

 title=
圖 2: 當在 Kubernetes 中執行 Pulsar 時,使用者可以使用已有的 etcd 例項來簡化部署

利用在 Kubernetes 叢集內執行的現有 etcd 服務來作為後設資料儲存,使用者可以完全不需要執行 ZooKeeper。這不僅減少了 Pulsar 叢集的基礎設施佔用的資源,還減輕了執行和操作複雜的分散式系統所需的運營負擔。

etcd 的所帶來的效能提升是一項令人特別興奮的技術進展——etcd 旨在解決與 ZooKeeper 相關的一些問題。對於初學者來說,etcd 完全是用 Go 編寫的,ZooKeeper 主要是用 Java 編寫的,而 Go 通常被認為是比 Java 效能更高的程式語言。

此外,etcd 使用較新的 Raft 共識演算法,該演算法在容錯和效能方面與 ZooKeeper 使用的 Paxos 演算法差別不大。但是,它比 ZooKeeper 使用的 ZaB 協議更容易理解和實現。

etcd 的 Raft 實現與 Kafka(KRaft)實現的最大區別在於後者使用基於拉的模型進行同步更新,在延遲上略有劣勢。Raft 演算法的 Kafka 版本也是用 Java 實現的,它在垃圾回收期間可能會出現長時間的停頓。而在基於 Go 語言的 Raft 演算法的 etcd 版本中則沒有這個問題。

第六步:縮放後設資料層

如今,Pulsar 叢集擴充套件的最大障礙是後設資料層的儲存容量。使用 ZooKeeper 儲存此後設資料時,必須將資料保留在記憶體中,以提供較好的延遲效能。用一句話概括便是"磁碟就是 ZooKeeper 的死穴"

然而,etcd 中的資料儲存方式是 B 樹資料結構,而不是 ZooKeeper 使用的分層樹結構,etcd 所用的資料儲存結構儲存在磁碟上並對映到記憶體中以提供低延遲的訪問。

這樣做的意義在於,它有效地將後設資料層的儲存容量從記憶體規模增加到磁碟規模,使我們能夠儲存大量的後設資料。對比 ZooKeeper 與 etcd ,儲存容量從 ZooKeeper 的幾 G 記憶體擴充套件到了超過 100G 的 etcd 磁碟

安裝與更多細節

在過去幾年中,Pulsar 成為了最活躍的 Apache 專案之一,正如 PIP-45 專案所展示的那樣,一個充滿活力的社群將繼續推動專案的創新和改進。

迫不及待想要嘗試去 ZooKeeper 的 Pulsar 嗎?下載最新版本的 Pulsar,並在獨立模式下執行,或者參考文件

除了去除對 ZooKeeper 的強依賴,Apache Pulsar 2.10.0 版本包含來自於 99 位貢獻者的 1000 個 commit,引入了多達 300 項重要的更新。即將釋出的新版本中還有諸多令人興奮的技術進展:

  • 引入 TableView 降低使用者構建鍵值對檢視的成本;
  • 在客戶端新增多叢集自動故障轉移策略;
  • 增加訊息重試指數退避延遲策略;
  • ……

在上週日的 TGIP-CN 037 直播中,Apache Pulsar PMC 成員,StreamNative 首席架構師李鵬輝為大家介紹了即將釋出的 Apache Pulsar 2.10 版本特性,敬請關注本週 Apache Pulsar 公眾號推送~

不過可以掃碼提前瀏覽回顧視訊喲:

參考文獻

關注公眾號「ApachePulsar」,獲取更多技術乾貨

加入 Apache Pulsar 中文交流群??

相關文章