Apache Pulsar學習筆記04: Pulsar的租戶、名稱空間和Topic

上一節在docker容器執行並體驗了單機模式的Pulsar，使用命令列管理工具

pulsar-admin

建立了租戶、名稱空間和Topic，瞭解了Pulsar Admin REST API。 本節將對pulsar的租戶、名稱空間、Topic相關的內容做一下整理。

Pulsar被設計為一個多租戶系統，租戶可以跨叢集分佈，每個租戶都可以有單獨的認證和授權機制，可以針對租戶設定儲存配額、訊息生存時間TTL和隔離策略。 Pulsar的多租戶功能使其可以為組織中的不同部門、不同團隊提供安全且獨佔的訊息服務，允許不同部門、不同團隊之間共享。這樣一個Pulsar例項下邊多個Pulsar叢集可以成為整個組織的訊息平臺服務。 Pulsar使用租戶、名稱空間、主題的層次結構支援多租戶，這就是Pulsar的邏輯架構，描述了在Pulsar中如何儲存資料的邏輯結構。

在上圖中將租戶劃給了組織的不同的部門或團隊，實際上租戶代表了組織中特定的業務單元，產品線、核心功能，這些由不同的部門或團隊負責。

租戶（Tenant）

租戶可以跨叢集分佈，表了組織中特定的業務單元，產品線、核心功能，這些由組織不同的部門或團隊負責。每個租戶都可以有單獨的認證和授權機制，可以針對租戶設定儲存配額、訊息生存時間TTL和隔離策略。

名稱空間（Namespace）

名稱空間是租戶的管理單元，每個租戶下可以建立多個名稱空間。可以透過在名稱空間上設定的配置策略來管理該名稱空間下的Topic，這樣就可以在名稱空間的級別上為該名稱空間的所有Topic設定訪問許可權、調整複製設定、管理跨叢集跨地域的訊息複製，控制訊息過期時間。

主題（Topic）和分割槽主題（Partitioned Topic）

在Pulsar中所有訊息的讀取和寫入都是和Topic進行，Pulsar的Topic本身並不區分

釋出訂閱模式

或者

生產消費模式（獨佔， 一個訊息只能被一個消費者消費）

，Pulsar是依賴於各種

訂閱型別

來控制訊息的使用模式。

在RabbitMQ中有Exchange的概念，而Exchange的型別分為dircet， topic， fanout， header四種類型，可以透過組合Producer，Exchange， Queue， Consumer來實現這兩種模式。

在Kafka中有Topic、Topic分割槽、消費者組的概念，Consumer被分組，Topic的每個分割槽只能被一個消費者組中的一個消費者消費。例如，一個Topic有4個分割槽，消費者組1中有4個消費者，消費者組2中有2個消費者，這兩個消費者組都訂閱了這個Topic，則組1中每個消費者分配到1個分割槽，組2中每個消費者分配到2個分割槽。Kafka很好的實現了釋出訂閱模式，多個消費者組可以消費同一個訊息。如果只把Kafka中的一個Topic和只有一個消費者的消費者組進行關聯，就模擬除了生產消費獨佔模式，但這也存在其缺點。

預設情況下一個Topic中的訊息只能由Pulsar服務層中的一個Broker提供服務，因此單個Topic的吞吐量受限於為其提供服務的Broker的計算能力。 好在Pulsar還支援分割槽主題（partitioned topic），這允許多個Broker提供服務，就可以將負載分佈到多臺機器上。在Pulsar內部，分割槽主題被實現為N個內部Topic，N是分割槽數量，分割槽跨Broker的分佈由Pulsar自動管理，這對使用者來說是完全透明的。 Pulsar將分割槽主題實現為多個內部主題，這樣就可以在需要增加分割槽數量的時候不必重新平衡整個主題，Pulsar只需在其內部建立新的分割槽（內部主題）就能夠立即接收新的訊息，使客戶端能在不中斷的情況下對現有分割槽進行訊息讀寫。

當生產者釋出訊息到分割槽主題時，不需要特意指定路由模式，預設使用

RoundRobinPartition

路由模式，將以輪循的方式將訊息均勻分佈到各個分割槽。目前支援以下3種路由模式：

SinglePartition： 如果沒有訊息key提供，將會隨機選擇一個單獨的分割槽來發布訊息，可用於將來自特定生產者的訊息分組在一起，以在沒有鍵值（key）時維護訊息順序。

RoundRobinPartition： 如果沒有訊息key提供，將以輪循的方式將訊息均勻分佈到各個分割槽

CustomPartition： 定製實現路由模式，控制訊息分發到Topic的分割槽中

如果提供了訊息key，會以key做hash，然後分配訊息到指定分割槽。因此分割槽中訊息的順序與路由模式和訊息的key有關：

按key分割槽，即所有擁有相同的key的訊息有序，將會被髮送到相同的分割槽

按producer，當路由模式為SinglePartition，且訊息沒有提供key時，來自於相同的Producer的訊息有序

Topic的URL，持久化Topic和非持久化Topic

Pulsar Topic預設是持久化的，即會儲存還沒確認的訊息到BookKeeper叢集的bookies節點中。持久化Topic的訊息資料可以在broker重啟或者訂閱者出問題的，故障轉移之後繼續存在。 Pulsar還支援非永續性topic，這些topic的訊息從不持久化儲存到磁碟，只存在於記憶體中，當使用非持久topic分發時，關閉Broker或者關閉訂閱者，非持久化Topic上所有的瞬時訊息都會丟失，客戶端可能會出現丟失訊息的情況。 非持久topic中，broker會立即釋出訊息給所有連線的訂閱者，而不會在BookKeeper中儲存。 如果有一個訂閱者斷開連線，broker將無法重發這些瞬時訊息，訂閱者將永遠無法收到這些訊息了。

雖然非持久訊息傳遞通常比持久訊息傳遞快，因為它避免了將資料持久化到磁碟相關的延遲，但只有在您確定具體的業務場景能夠容忍訊息丟失時，才建議使用它。

持久化Topic URL的格式為：

persistent：//tenant/namespace/topic-name

非持久化Topic URL的格式為：

non-persistent：//tenant/namespace/topic-name

參考

https：//pulsar。apache。org/docs/zh-CN/concepts-multi-tenancy/

https：//pulsar。apache。org/docs/en/2。5。1/cookbooks-partitioned/