Apache Pulsar的系統架構及設計理念是什么

今天就跟大家聊聊有關Apache Pulsar的系統架構及設計理念是什么，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。

我們將介紹Apache Pulsar背后的一些系統架構和設計理念，并最后與Apache Kafka的架構進行一些比較。

Pulsar的分層架構

Apache Pulsar和其他消息系統最根本的不同是采用分層架構。 Apache Pulsar集群由兩層組成：無狀態服務層，由一組接收和傳遞消息的Broker組成；以及一個有狀態持久層，由一組名為bookies的Apache BookKeeper存儲節點組成，可持久化地存儲消息。 下圖顯示了Apache Pulsar的典型部署。

在Pulsar客戶端中提供生產者和消費者（Producer & Consumer）接口，應用程序使用Pulsar客戶端連接到Broker來發布和消費消息。
Pulsar客戶端不直接與存儲層Apache BookKeeper交互。 客戶端也沒有直接的Zookeeper訪問權限。這種隔離，為Pulsar實現安全的多租戶統一身份驗證模型提供了基礎。
Apache Pulsar為客戶端提供多種語言的支持，包括Java，C ++，Python，Go和Websockets。
Apache Pulsar還提供了一組兼容Kafka的API，用戶可以通過簡單地更新依賴關系并將客戶端指向Pulsar集群來遷移現有的Kafka應用程序，這樣現有的Kafka應用程序可以立即與Apache Pulsar一起使用，無需更改任何代碼。

Broker層--無狀態服務層

Broker集群在Apache Pulsar中形成無狀態服務層。服務層是“無狀態的”，因為Broker實際上并不在本地存儲任何消息數據。有關Pulsar主題的消息，都被存儲在分布式日志存儲系統（Apache BookKeeper）中。我們將在下一節中更多地討論BookKeeper。
每個主題分區（Topic Partition）由Pulsar分配給某個Broker，該Broker稱為該主題分區的所有者。 Pulsar生產者和消費者連接到主題分區的所有者Broker，以向所有者代理發送消息并消費消息。

如果一個Broker失敗，Pulsar會自動將其擁有的主題分區移動到群集中剩余的某一個可用Broker中。這里要說的一件事是：由于Broker是無狀態的，當發生Topic的遷移時，Pulsar只是將所有權從一個Broker轉移到另一個Broker，在這個過程中，不會有任何數據復制發生。

下圖顯示了一個擁有4個Broker的Pulsar集群，其中4個主題分區分布在4個Broker中。每個Broker擁有并為一個主題分區提供消息服務。

BookKeeper層--持久化存儲層

Apache BookKeeper是Apache Pulsar的持久化存儲層。 Apache Pulsar中的每個主題分區本質上都是存儲在Apache BookKeeper中的分布式日志。

每個分布式日志又被分為Segment分段。 每個Segment分段作為Apache BookKeeper中的一個Ledger，均勻分布并存儲在BookKeeper群集中的多個Bookie（Apache BookKeeper的存儲節點）中。
Segment的創建時機包括以下幾種：基于配置的Segment大小；基于配置的滾動時間；或者當Segment的所有者被切換。

通過Segment分段的方式，主題分區中的消息可以均勻和平衡地分布在群集中的所有Bookie中。 這意味著主題分區的大小不僅受一個節點容量的限制； 相反，它可以擴展到整個BookKeeper集群的總容量。

下面的圖說明了一個分為x個Segment段的主題分區。 每個Segment段存儲3個副本。 所有Segment都分布并存儲在4個Bookie中。

Segment為中心的存儲

存儲服務的分層的架構 和 以Segment為中心的存儲 是Apache Pulsar（使用Apache BookKeeper）的兩個關鍵設計理念。 這兩個基礎為Pulsar提供了許多重要的好處：

• 無限制的主題分區存儲

• 即時擴展，無需數據遷移

• 無縫Broker故障恢復

• 無縫集群擴展

• 無縫的存儲（Bookie）故障恢復

• 獨立的可擴展性

  
  

下面我們分別展開來看著幾個好處。

無限制的主題分區存儲

由于主題分區被分割成Segment并在Apache BookKeeper中以分布式方式存儲，因此主題分區的容量不受任何單一節點容量的限制。 相反，主題分區可以擴展到整個BookKeeper集群的總容量，只需添加Bookie節點即可擴展集群容量。 這是Apache Pulsar支持存儲無限大小的流數據，并能夠以高效，分布式方式處理數據的關鍵。 使用Apache BookKeeper的分布式日志存儲，對于統一消息服務和存儲至關重要。

即時擴展，無需數據遷移

由于消息服務和消息存儲分為兩層，因此將主題分區從一個Broker移動到另一個Broker幾乎可以瞬時內完成，而無需任何數據重新平衡（將數據從一個節點重新復制到另一個節點）。 這一特性對于高可用的許多方面至關重要，例如集群擴展；對Broker和Bookie失敗的快速應對。 我將使用例子在下文更詳細地進行解釋。

• 無縫Broker故障恢復

下圖說明了Pulsar如何處理Broker失敗的示例。 在例子中Broker 2因某種原因（例如停電）而斷開。 Pulsar檢測到Broker 2已關閉，并立即將Topic1-Part2的所有權從Broker 2轉移到Broker 3。在Pulsar中數據存儲和數據服務分離，所以當代理3接管Topic1-Part2的所有權時，它不需要復制Partiton的數據。 如果有新數據到來，它立即附加并存儲為Topic1-Part2中的Segment x + 1。 Segment x + 1被分發并存儲在Bookie1, 2和4上。因為它不需要重新復制數據，所以所有權轉移立即發生而不會犧牲主題分區的可用性。

• 無縫集群容量擴展

下圖說明了Pulsar如何處理集群的容量擴展。 當Broker 2將消息寫入Topic1-Part2的Segment X時，將Bookie X和Bookie Y添加到集群中。 Broker 2立即發現新加入的Bookies X和Y。然后Broker將嘗試將Segment X + 1和X + 2的消息存儲到新添加的Bookie中。 新增加的Bookie立刻被使用起來，流量立即增加，而不會重新復制任何數據。 除了機架感知和區域感知策略之外，Apache BookKeeper還提供資源感知的放置策略，以確保流量在群集中的所有存儲節點之間保持平衡。

• 無縫的存儲（Bookie）故障恢復

下圖說明了Pulsar（通過Apache BookKeeper）如何處理bookie的磁盤故障。 這里有一個磁盤故障導致存儲在bookie 2上的Segment 4被破壞。Apache BookKeeper后臺會檢測到這個錯誤并進行復制修復。

Apache BookKeeper中的副本修復是Segment（甚至是Entry）級別的多對多快速修復，這比重新復制整個主題分區要精細，只會復制必須的數據。 這意味著Apache BookKeeper可以從bookie 3和bookie 4讀取Segment 4中的消息，并在bookie 1處修復Segment 4。所有的副本修復都在后臺進行，對Broker和應用透明。
即使有Bookie節點出錯的情況發生時，通過添加新的可用的Bookie來替換失敗的Bookie，所有Broker都可以繼續接受寫入，而不會犧牲主題分區的可用性。

獨立的可擴展性

由于消息服務層和持久存儲層是分開的，因此Apache Pulsar可以獨立地擴展存儲層和服務層。這種獨立的擴展，更具成本效益：

當您需要支持更多的消費者或生產者時，您可以簡單地添加更多的Broker。主題分區將立即在Brokers中做平衡遷移，一些主題分區的所有權立即轉移到新的Broker。

當您需要更多存儲空間來將消息保存更長時間時，您只需添加更多Bookie。通過智能資源感知和數據放置，流量將自動切換到新的Bookie中。 Apache Pulsar中不會涉及到不必要的數據搬遷，不會將舊數據從現有存儲節點重新復制到新存儲節點。

和Kafka的對比

Apache Kafka和Apache Pulsar都有類似的消息概念。 客戶端通過主題與消息系統進行交互。 每個主題都可以分為多個分區。 然而，Apache Pulsar和Apache Kafka之間的根本區別在于Apache Kafka是以分區為存儲中心，而Apache Pulsar是以Segment為存儲中心。

上圖顯示了以分區為中心和以Segment為中心的系統之間的差異。
在Apache Kafka中，分區只能存儲在單個節點上并復制到其他節點，其容量受最小節點容量的限制。這意味著容量擴展需要對分區重新平衡，這反過來又需要重新復制整個分區，以平衡新添加的代理的數據和流量。
重新傳輸數據非常昂貴且容易出錯，并且會消耗網絡帶寬和I/O。維護人員在執行此操作時必須非常小心，以避免破壞生產系統。

Kafka中分區數據的重新拷貝不僅發生在以分區為中心的系統中的群集擴展上。許多其他事情也會觸發數據重新拷貝，例如副本故障，磁盤故障或計算機的故障。在數據重新復制期間，分區通常不可用，直到數據重新復制完成。例如，如果您將分區配置為存儲為3個副本，這時，如果丟失了一個副本，則必須重新復制完整個分區后，分區才可以再次可用。

在用戶遇到故障之前，通常會忽略這種缺陷，因為許多情況下，在短時間內僅是對內存中緩存數據的讀取。當數據被保存到磁盤后，用戶將越來越多地不可避免地遇到數據丟失，故障恢復的問題，特別是在需要將數據長時間保存的場合。

相反，在Apache Pulsar中，同樣是以分區為邏輯單元，但是以Segment為物理存儲單元。分區隨著時間的推移會進行分段，并在整個集群中均衡分布，旨在有效地迅速地擴展。
Pulsar是以Segment為中心的，因此在擴展容量時不需要數據重新平衡和拷貝，舊數據不會被重新復制，這要歸功于在Apache BookKeeper中使用可擴展的以Segment為中心的分布式日志存儲系統。

通過利用分布式日志存儲，Pulsar可以最大化Segment放置選項，實現高寫入和高讀取可用性。 例如，使用BookKeeper，副本設置等于2，只要任何2個Bookie啟動，就可以對主題分區進行寫入。 對于讀取可用性，只要主題分區的副本集中有1個處于活動狀態，用戶就可以讀取它，而不會出現任何不一致。

看完上述內容，你們對Apache Pulsar的系統架構及設計理念是什么有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。