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

網(wǎng)站建設(shè)哪家好，找創(chuàng)新互聯(lián)！專注于網(wǎng)頁設(shè)計、網(wǎng)站建設(shè)、微信開發(fā)、重慶小程序開發(fā)、集團(tuán)企業(yè)網(wǎng)站建設(shè)等服務(wù)項目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了龍海免費建站歡迎大家使用！

1. 前言

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

2. 問題

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

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

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

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

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

• Topic相關(guān)的配置變更后，要對被修改的Broker做重載操作，配置才能生效，Topic配置的[分區(qū)數(shù)，可發(fā)布、可訂閱] 變更會觸發(fā)流轉(zhuǎn)狀態(tài)機，對這些參數(shù)的變更要分批進(jìn)行。

通過如上的設(shè)計，我們實現(xiàn)了整個節(jié)點的狀態(tài)管理和配置管理。

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

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

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

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

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

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

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

1. 執(zhí)行Reload命令，Master將指定Broker的acceptPublish狀態(tài)設(shè)置為false，先執(zhí)行暫停生產(chǎn)操作，并等待1個最大心跳等待周期（25秒）；

2. 向該Broker生產(chǎn)數(shù)據(jù)的Producer收到變更通知，暫停向該Broker發(fā)送數(shù)據(jù)，等待配置完成；

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

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

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

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

7. Consumer發(fā)起到該Broker的訂閱操作；

8. Master指定Broker的acceptPublish狀態(tài)設(shè)置為true,開啟該Broker的生產(chǎn)，并等待1個心跳周期；

9. Master設(shè)置管理狀態(tài)為空閑態(tài)。

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

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

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

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

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

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

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

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

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

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

2.6 哪里查指標(biāo)數(shù)據(jù)，比如每個分區(qū)的生產(chǎn)消費情況？

在Log日志目錄下，生產(chǎn)指標(biāo)存儲于get_transfer.log，消費指標(biāo)存儲于put_transfer.log，細(xì)化到每個partition粒度。由于我們系統(tǒng)負(fù)載實在是很高，采用的方案都是吐指標(biāo)，依靠第三方組件完成對應(yīng)數(shù)據(jù)深加工。

2.7 后續(xù)TubeMQ的功能有什么方向？

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

看完上述內(nèi)容，你們對Apache TubeMQ使用時要注意哪些點有進(jìn)一步的了解嗎？如果還想了解更多知識或者相關(guān)內(nèi)容，請關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝大家的支持。

文章標(biāo)題：ApacheTubeMQ使用時要注意哪些點
瀏覽地址：http://chinadenli.net/article2/gpdeic.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供域名注冊、網(wǎng)站營銷、微信公眾號、、網(wǎng)站維護(hù)、云服務(wù)器

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)