Apache TubeMQ使用時要注意哪些點

今天就跟大家聊聊有關Apache TubeMQ使用時要注意哪些點，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。

1. 前言

Apache TubeMQ使用時要注意哪些點？為什么要這么設計？我在這里匯總解答下，便于大家了解。

2. 問題

2.1 為什么Broker要先配置再使用？

這個應是Apache TubeMQ在使用體驗上與其他MQ的最大不同，如下圖所示，集群要先部署Master；Master部署好Broker上線前，要先在Master配置好Broker相關配置，并調整其狀態為上線狀態后，Broker才能加入集群對外服務。TubeMQ為什么要這樣設計，為什么不能如其他MQ，比如Kafka，配置好Broker的文件后，直接啟動進程就可以加入集群直接使用呢？

為了集群管控： 大家可以試想下，如果直接加入有什么不足的地方，雖然方便使用，但如果我作為一個仿冒者，是否可以不知不覺加入集群讓系統運行混亂，形成數據泄漏；或者有人會說啟動時候配置文件里加入認證授權哈，但如果這個節點掛了，我從哪里方便的了解線上各個節點的總體情況呢？ TubeMQ采用的是SAAS模式進行集群管理，對應的它需要明確的知道集群的各個Broker節點當前狀態是怎樣，需要有一個地方來集中的管理它們；為了達到這個效果，我們設計了一個狀態機：

Broker的主體狀態為草稿--> 上線 --> 下線，新增加Broker配置均為草稿狀態，只有將Broker狀態設置為上線及之后的狀態后才能正常啟動新版本的Broker進程；在Broker配置變更后，還需要進行Broker加載操作，才能使配置最終生效；在broker下線時，只需要調用Broker下線操作即可。在進行狀態機操作時我們還有需要特別注意的地方：

• 每個狀態的流轉都有狀態機，在操作時，避免同一時刻對集群里所有的Broker節點做操作，只有等到運行子狀態為idle時才能對下一批節點做處理；

• Topic相關的配置變更后，要對被修改的Broker做重載操作，配置才能生效，Topic配置的[分區數，可發布、可訂閱] 變更會觸發流轉狀態機，對這些參數的變更要分批進行。

通過如上的設計，我們實現了整個節點的狀態管理和配置管理。

2.2 為什么Topic不支持自動添加，同時新增時要輸入授權碼？

權限管控： 這塊和Broker管理類似，采用SAAS模式，資源是集中且有限的，需要業務提前切分資源，準備好后再使用；同時頁面上的所有變更操作，以及某些查詢超過要輸入授權碼，是在于從系統的管理角度來看，這些操作本身就是分級的：

我們內部是運維來運營管理系統，授權碼設置比較簡單，放置在master.ini文件的confModAuthToken參數里，誰有權限登錄該主機就有權限操作；這塊大家也可以根據各自的實際情況進行調整，比如對你們的接認證系統。

我們的接口在指定Topic配置的時候是要求指定配置該Topic的BrokerId集合的，其作用在于精確的將Topic分配到指定的Broker，避免負載不一致問題；新增完Topic配置后，我們還需要對新增Topic的Broker集合做Reload操作，我們的做法是將Broker分批進行Reload，前一批Broker Reload完畢后再做下一批Broker的Reload，完成整體的配置變更。

2.3 為什么每次配置變更都要做Reload，并且要持續這么長時間？

這個應該也是Apache TubeMQ和其他MQ在使用體驗上的最大差異之一，TubeMQ做配置變更時是通過Broker的Reload操作進行，一個Broker從調用Reload發起變更到變更最終結束，整個過程會耗費大約1.2分鐘的間隔，為什么TubeMQ變更要這樣做，為什么不像其他MQ一樣，比如Kafka和Pulsar，將配置數據直接寫入zk，這樣配置就可以實時生效了？

上圖是Reload的一個完整狀態遷移圖，Broker的Reload操作實際上包含了如下9個步驟：

1. 執行Reload命令，Master將指定Broker的acceptPublish狀態設置為false，先執行暫停生產操作，并等待1個最大心跳等待周期（25秒）；

2. 向該Broker生產數據的Producer收到變更通知，暫停向該Broker發送數據，等待配置完成；

3. Master繼續指定Broker的acceptSubscribe為false，執行暫停消費，并等待1個最大心跳等待周期；

4. 訂閱該Broker數據的Consumer感知Broker的配置將發生變更，暫停消費，等待配置完成；

5. Broker在如上過程完成（8秒內）配置變更；

6. Master指定Broker的acceptSubscribe為true，開啟該Broker的消費，并等待1個最大心跳周期；

7. Consumer發起到該Broker的訂閱操作；

8. Master指定Broker的acceptPublish狀態設置為true,開啟該Broker的生產，并等待1個心跳周期；

9. Master設置管理狀態為空閑態。

為什么要這么做呢？這樣操作下來時間很長且繁雜。

為了避免數據丟失： 從流程大家可以看到，TubeMQ的Reload采用這種近似系統重啟的流程是為了盡可能的讓消費先于生產加入集群，應對的就是系統擴容時，Consumer 以【缺省首次從最大位置開始消費，后續接續消費】設置時，遇到分區信息被Producer先于Consumer獲取并生產數據時的數據丟失情況。

有同學可能會說，為什么不像Pulsar樣，擴容時先將元數據寫入ZooKeeper設置初始的offset位置來解決該問題呢？

與ZooKeeper解耦： 從系統實現大家也可以看到，ZooKeeper在TubeMQ里支持做offset的持久化用，系統實際運行起來后是可以脫離ZooKeeper而存在的，如果我們擴容時先將元數據寫入ZooKeeper設置初始的offset位置，就會形成系統對ZooKeeper的依賴，比如Master連不上ZooKeeper時就會出現數據仍有丟的情況，同時，這樣設計會加重配置變更的處理邏輯，以及延長了擴容的時間，甚至有可能因為ZooKeeper異常導致擴容操作失敗。

考慮到線上的Topic操作其實是不需要即時產生，同時隨著系統發展，后續不同類型的配置有可能又需要做狀態機管理且多個變更合在一起操作時，仍有需要多個心跳周期同步后才能更新完的情況；所以，目前我們采用了如上異步模式進行。

注意： 從上面的描述我們可以看到，Broker進行Reload時，會有短暫的停讀停寫操作，因此，線上使用，我們都是對需要更新配置的Broker分批操作，逐批的Broker更新來完成Topic的配置更新。

2.4 為什么0.8.0版本的客戶端連不上0.3.0的服務端？

SAAS管控： Apache TubeMQ采用的是強管控服務器模式，線上我們運用模式一定是服務端高版本客戶端允許低版本形式存在；也即服務端兼容低版本客戶端，但高版本的客戶端不兼容低版本服務端，解決客戶端復雜化的問題。

2.5 為什么WEB的API操作和Restful像，又不太像？為什么要手工拼接WEB API的查詢返回？

方便使用及性能考慮： 反Restful模式主要是考慮新增修改操作可以直接在瀏覽器里輸入url即可完成查詢或者修改操作，缺點就是修改操作的量一次可能只能到幾百的記錄條數（最大URL長限制）；手工拼接json的返回結果，主要是性能考慮，從我們測試來看，手工操作可以達到毫秒級時耗，采用組件有可能是秒級，帶來的問題就是編碼上需要特別注意。

2.6 哪里查指標數據，比如每個分區的生產消費情況？

在Log日志目錄下，生產指標存儲于get_transfer.log，消費指標存儲于put_transfer.log，細化到每個partition粒度。由于我們系統負載實在是很高，采用的方案都是吐指標，依靠第三方組件完成對應數據深加工。

2.7 后續TubeMQ的功能有什么方向？

個人覺得這個看開源社區的走向：Apache TubeMQ現在已經捐獻給了Apache，雖然我們是項目的原創團隊，但我們現在也只是參與社區。從我們的角度來說，我們會滿足我們內部的業務需求，并將我們的特性貢獻給社區；所以歡迎大家一起來共建共同促進社區的繁榮。

看完上述內容，你們對Apache TubeMQ使用時要注意哪些點有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。