分散式訊息流平臺:不要只想著Kafka,還有Pulsar

語言: CN / TW / HK
摘要:Pulsar作為一個雲原生的分散式訊息流平臺,越來越頻繁地出現在人們的視野中,大有替代Kafka江湖地位的趨勢。

本文分享自華為雲社群《MRS Pulsar:下一代分散式訊息流平臺全新發布!》,作者: Lothar。

Pulsar的前世今生

Apache Pulsar是一個釋出-訂閱訊息系統,使用計算與儲存分離的雲原生架構。Pulsar 2018年9月成為ASF頂級專案,近兩年,隨著社群不斷髮展和諸多企業的應用和貢獻,Pulsar作為一個雲原生的分散式訊息流平臺,越來越頻繁地出現在人們的視野中,大有替代Kafka江湖地位的趨勢。

Pulsar和Kafka的對比

Pulsar和Kafka架構上最大的不同是,Kafka由Broker進行訊息的收發和持久化,資料儲存在本地檔案系統,由Broker統一管理。這也意味著資料和訊息處理是耦合的。

Kafka官網描述道:Kafka重度依賴檔案系統,用於儲存或快取訊息。當Broker接收到訊息時,會將訊息追加寫到本地磁碟上。這一架構決定了Partition和Broker的對應關係是相對固定的,只有在partition reassign時才會發生資料遷移。Partition的Leader在資料副本分佈節點上產生,用於處理生產消費請求。

而Pulsar採用了計算儲存分離架構,這也是Pulsar被稱作雲原生平臺的主要原因。Pulsar依賴Apache BookKeeper管理持久化資料,Apache BookKeeper是可擴充套件、可容錯、低延遲的日誌儲存服務,能夠保證在強永續性下的低延遲讀寫。

*引自Pulsar官網介紹:https://pulsar.apache.org/docs/en/concepts-architecture-overview/

Broker接收請求後,資料實際分散式儲存在BookKeeper服務中。在資料的物理儲存模型中某個Topic或Partition的資料並不固定儲存在某個Bookie例項上。

Pulsar將分散式日誌劃分為多個Segment,每個Segment對應BookKeeper中的一個Ledger。與Kafka將某一Partition的資料日誌儲存在某一固定目錄下不同,Pulsar通過劃分Segment的方式,可以將同一topic或partition分佈到不同的Bookie上。

Pulsar的優勢特性

靈活擴充套件

相信很多使用Kafka的客戶都有類似的經歷:

  • 磁碟空間不足,只能調整資料TTL,或擴容機器後向新的Broker中遷移Partition
  • Topic或Partition間資料分配不均勻,節點之間或磁碟之間使用不均衡,有的磁碟已經滿了,而有的磁碟還有很多空間
  • Broker機器故障,需要將資料遷移到其他節點後下電維修

Pulsar的存算分離架構天然地避免了這些問題。Pulsar Broker本身是無狀態的,當某個Broker故障時,另一個Broker可以立即接管對應的Topic而不需要遷移資料。BookKeeper分散式日誌保證了儲存節點間的資料均衡,不會因某一個Partitoin或Topic資料過多而導致IO集中在某一節點上。

當叢集需要擴容時,Broker可以立即感知到新加入叢集的Bookie,並將新寫入的資料儲存到新新增的Bookie中。

多租戶

Kafka社群在KIP-37正在討論加入NameSpace以實現多租戶特性,而Pulsar已實現這一功能。在企業中,訊息佇列服務通常會被多個團隊使用,在使用Kafka時,有時需要為每個團隊維護一個Kafka叢集。Pulsar可以配置多個租戶,每個租戶可以有多個NameSpace,管理員可以對NameSpace進行訪問控制、配額管理。

更靈活的訂閱模式

Kafka對訊息的劃分分為兩層:對於屬於同一個Group的KafkaConsumer,其獲取到的訊息是互斥的,即某一條訊息只能被Group中的一個Consumer處理;對於不同的Group,某一條訊息將同時被兩個Group處理,訊息是共享的。

而Pulsar提供了更靈活的訂閱模式:

  • 獨佔式:

在任意時間,Topic中的資料只能被Group中的一個Consumer消費,不允許其他Consumer獲取訊息

  • 主備式:

多個Consumer同時消費同一個Topic時,只有一個Consumer被選為主Consumer,其他Consumer則成為備Consumer。當主Consumer故障時,發生主備倒換,備Consumer中的一個將升主,並繼續訊息的消費。

  • 共享式:

與Kafka類似,使用共享模式,訊息將迴圈分發給不同的Consumer,當某個Consumer故障時,訊息將被重新分配給其他Consumer。

分層儲存

Pulsar另一個很有吸引裡的特性是,流式資料可以轉冷並存儲在更廉價的儲存介質上。通常為了保證效能,流式處理系統配備高效能的SSD。對於Kafka來說,所有需要保留的訊息都必須駐留在昂貴的SSD上。有些時候,資料寫入一段時間後已不在會被使用,但仍需保留一段時間存檔。Pulsar支援將這種冷資料轉儲到離線儲存系統中,BookKeeper只需要保留一部分熱資料,可以節省很多儲存成本。該特性無疑是很有價值的,Kafka社群同樣在進行設計(KIP-405),但目前還沒有實現。

Pulsar的效能指標

Kafka和Pulsar社群都針對性能進行了對比測試。綜合來看,由於Pulsar資料落盤時,會進行同步fsync,永續性要比Kafka更高,Pulsar社群對此作出修改後進行對比測試,部分測試結果如下:

*引自Pulsar社群效能測試報告

在100 Partition時,預設配置下pulsar的吞吐量距離Kafka差距明顯,但當本地持久化等級設定為與Kafka相同時,吞吐量與Kafka基本持平。

*引自Pulsar社群效能測試報告

當Partition數增加到2000個時,Pulsar預設本地持久度的吞吐量基本與Kafka持平。

更多細節請移步SreamNative的benckmarking測試報告:benchmarking pulsar kafka a more accurate perspective on pulsar performance.pdf

MRS上的Pulsar

MRS已釋出Pulsar的POC版本,客戶可以一鍵式部署Pulsar服務,包括Broker和Bookie角色。支援在Web UI上修改Pulsar配置、啟停、監控。

此外MRS還預設集成了KoP。KoP是Pulsar社群開源的一個外掛,執行在Pulsar上,用以相容Kafka協議。使用時,Kafka客戶端可以修改連線地址後直接切換到Pulsar叢集上,而不需要修改業務對Kafka客戶端的依賴。

在MRS Pulsar的商用版本正在規劃中,我們將探索Pulsar在雲上使用的更多可能,進一步發揮Pulsar存算分離的優勢,降低成本,提升資源利用率,為客戶創造更多價值,敬請期待。

 

點選關注,第一時間瞭解華為雲新鮮技術~