[[423797]]

Pulsar是一款非常優秀的消息流平臺，這篇文章主要講Pulsar中Topic通過Bundle這個負載均衡利器在Broker中的分配。

1 Topic層級概念

首先看一下Pulsar的架構圖，如下圖：

Pulsar的Broker可以管理一個或者多個Topic。Pulsar是一個多租戶平臺，多租戶的特性體現在Topic是一個層級概念，Topic的URL如下圖：

一個Topic可以使用persistent屬性指定是否持久化，而Topic的上層使用租戶來進行權限隔離，使用Namespace來進行策略管理。

Topic的層級概念也可以用下圖來表示：

在一個公司內部的Pulsar集群中，可以根據業務部門建租戶，根據業務部門內部的不同項目組來劃分Namespace，根據每個項目組的不同業務單元來劃分Topic。

2 Namespace Bundles

Pulsar把Namespace拆成了Bundle，Bundle是namespace的子集。如下圖一個Namespace下面有6個Topic：

我們把這個Namespace劃分成四個hash區域，從0x00000000~0xffffffff，之后把6個Topic按照名字(上面URL圖中的最后一部分)做Hash運算，分配到這四個區域內，如下圖：

上圖中，Topic0做Hash運算后值落在了0xc0000000~0xffffffff這個區域，其他幾個Topic也分別落到了自己的Hash區域。

為什么要為Namespace劃分Bundle子集呢?因為Pulsar有自動負載均衡機制，會把繁忙的Broker里面的一些Topic遷移到比較空閑的Broker中，實現Broker直接的流量均衡。這個搬移如果直接搬移Namespace，會太重，比如上面的圖需要一下子搬移6個Topic。如果以Topic為單位，每次搬移數據就會太小，而且搬移過程中需要保存大量Topic和Broker之間的元數據。有了Bundle后，以Bundle為單位進行遷移，遷移Topic會容易很多，比如上圖中，一次遷移一個Bundle，有的包含一個Topic，有的包含兩個Topic。

3 Broker分配Bundle

Broker集群啟動過程中會在Zookeeper競爭創建臨時節點，創建成功的成為Leader節點，叫Load Manager，這個節點會定期搜集其他Broker的服務狀態，比如CPU、內存、網卡帶寬利用率，這些指標都是臨時數據，所以Leader節點并不會保存太多數據。

Leader節點會根據搜集到的負載情況為其他Broker節點分配Bundle。如下圖：

上圖中Broker1競爭成為Leader，它負責為其他幾個Broker分配Bundle。初始化時，每個Broker都沒有Boundle，Leader把topic0分配給了Broker3，這就代表topic0所在的Bundle分配給了Broker3，之后Hash值跟topic0相同的都會落到這個Bundle。然后把topic1分配給了Broker2，這就代表topic1所在的Bundle分配給了Broker2。類似把其他2個Bundle分別分配給了Broker0和Broker1。

4 高可用

還是以上面的圖為例，如果Broker0宕機了，Load Manager和ZK都能檢測到broker0宕機，這時Load Manager會重新把Bundle(0x00000000~0x400000000)分配給其他三個broker，最后選擇哪個broker取決于Load Manager收集到的每個broker的負載情況，會找一個負載最小的broker分配。如下圖：

如果Broker1宕機了，也就是Leader節點宕機了，那Broker0、Broker1和Broker2三個節點會去Zookeeper搶占注冊零時節點，注冊成功的成為新的Leader，新的Leader節點會把Broker1的Bundle分配給剩下的3個Broker。

5 客戶端

Topic通過Bundle綁定了Broker之后，客戶端就可以跟自己要訪問的Broker建立長鏈接，如下圖：

這里需要注意：圖中的第1、2兩步既可以用HTTP的方式，也可以用TCP的方式，但是第3步也就是Broker跟client建立連接只能用TCP。

Pulsar為客戶端提供了代理，客戶端可以直接跟代理通信，如下圖：

6 總結

使用了Bundle，Pulsar可以方便地通過Load Manager節點做負載均衡，不用考慮一次搬移的Topic太多，也不用擔心一次搬移一個Topic而需要保存太多元數據。