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

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

1. 前言

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

2. 問(wèn)題

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6. Master指定Broker的acceptSubscribe為true，開(kāi)啟該Broker的消費(fèi)，并等待1個(gè)最大心跳周期；

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

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

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

為什么要這么做呢？這樣操作下來(lái)時(shí)間很長(zhǎng)且繁雜。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

廣告

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