TubeMQ總體介紹

TubeMQ是騰訊大數(shù)據(jù)在2013年開始研發(fā)的分布式消息中間件系統(tǒng)（MQ），專注服務(wù)大數(shù)據(jù)場(chǎng)景下海量數(shù)據(jù)的高性能存儲(chǔ)和傳輸。經(jīng)過近7年上萬(wàn)億的海量數(shù)據(jù)沉淀，較之于眾多的開源MQ組件，TubeMQ在海量實(shí)踐（穩(wěn)定性+性能）和低成本方面有一定的優(yōu)勢(shì)。一個(gè)禮拜前，TubeMQ開源了，本篇博文轉(zhuǎn)載自官方公布的文檔。博主花了半天搭建開發(fā)環(huán)境到運(yùn)行，到發(fā)送消息接收消息體驗(yàn)下來，發(fā)現(xiàn)不管是騰訊的TubeMQ，還是rocketmq，他們的架構(gòu)都或多或少參考了kafka的設(shè)計(jì)，所以上手會(huì)非?？?。而且，開源版本很可能是內(nèi)部版本的剖離版，剛開源還沒來得及打磨，沒做全面的驗(yàn)證測(cè)試。因?yàn)椴┲髟跍y(cè)試過程中發(fā)現(xiàn)了一個(gè)特別大的bug，consumer接收消息時(shí)導(dǎo)致CPU100%，而且是必現(xiàn)的，有興趣的可以去issue查看，博主提交issue后，官方開發(fā)立馬就跟進(jìn)了，這速度也是沒誰(shuí)了。相信不久后TubeMQ會(huì)是繼kafka和rocketmq后又一個(gè)非常不錯(cuò)的選擇。TubeMQ也有捐贈(zèng)給Apache的想法，Apache中國(guó)內(nèi)的頂級(jí)項(xiàng)目越來越多了，國(guó)內(nèi)的開源大環(huán)境也越來越好了

項(xiàng)目地址：https://github.com/Tencent/TubeMQ

TUBEMQ的性能：

從TubeMQ架構(gòu)圖可以很清晰的看到，作為分布式的消息中間件系統(tǒng)，Broker單節(jié)點(diǎn)的性能情況直接影響到集群總體的性能表現(xiàn)，即相同的節(jié)點(diǎn)數(shù)下Broker節(jié)點(diǎn)性能越高則TubeMQ的總體性能越強(qiáng)。下表是根據(jù)我們多年的線上運(yùn)營(yíng)經(jīng)驗(yàn)總結(jié)的典型場(chǎng)景： 

通過對(duì)TubeMQ與Kafka進(jìn)行對(duì)比測(cè)試分析（詳情見《TubeMQ VS Kafka性能對(duì)比測(cè)試總結(jié)V1.0.md》），在1份寫入2份并行消費(fèi)的場(chǎng)景下，從機(jī)型、關(guān)鍵配置、系統(tǒng)測(cè)試結(jié)果數(shù)據(jù)的對(duì)比中我們可以很清晰的看到TubeMQ的性能情況，用大家熟悉的復(fù)仇者聯(lián)盟角色類比，相當(dāng)于是如下表的情況總結(jié): 

總的來說：Kafka按照順序?qū)?+ 順序塊讀的模式實(shí)現(xiàn)，單實(shí)例下性能數(shù)據(jù)很強(qiáng)，但隨著實(shí)例數(shù)增多，它的性能就呈現(xiàn)不穩(wěn)定下降狀態(tài)；TubeMQ采用順序?qū)?+ 隨機(jī)讀的模式，即使在最大限制下系統(tǒng)仍可以做到長(zhǎng)期穩(wěn)定的1G以上的入流量，同時(shí)，結(jié)合服務(wù)端過濾過濾消費(fèi)非常順暢。

與當(dāng)前MQ橫向?qū)Ρ确治觯?/h2>

下表是TubeMQ與主流MQ做的一個(gè)整體情況對(duì)比，便于大家快速粗略的了解TubeMQ與其他的MQ之間的差異。需要注意的是，相比其他MQ，基于成本和異步復(fù)制仍有丟數(shù)據(jù)的考慮，TubeMQ沒有納入多副本實(shí)現(xiàn)，相關(guān)高可靠的業(yè)務(wù)應(yīng)用通過另一套實(shí)時(shí)多副本MQ Hippo來提供相應(yīng)服務(wù)；TubeMQ在接下來版本中有計(jì)劃進(jìn)行多副本的實(shí)現(xiàn)處理。如下是相關(guān)特性比較： 

TUBEMQ集群架構(gòu)：

經(jīng)過多年演變，TubeMQ集群分為如下5個(gè)部分： 

Portal： 負(fù)責(zé)對(duì)外交互和運(yùn)維操作的Portal部分，包括API和Web兩塊，API對(duì)接集群之外的管理系統(tǒng)，Web是在API基礎(chǔ)上對(duì)日常運(yùn)維功能做的頁(yè)面封裝；

Master： 負(fù)責(zé)集群控制的Control部分，該部分由1個(gè)或多個(gè)Master節(jié)點(diǎn)組成，Master HA通過Master節(jié)點(diǎn)間心跳?；睢?shí)時(shí)熱備切換完成（這是大家使用TubeMQ的Lib時(shí)需要填寫對(duì)應(yīng)集群所有Master節(jié)點(diǎn)地址的原因），主Master負(fù)責(zé)管理整個(gè)集群的狀態(tài)、資源調(diào)度、權(quán)限檢查、元數(shù)據(jù)查詢等；

Broker： 負(fù)責(zé)實(shí)際數(shù)據(jù)存儲(chǔ)的Store部分，該部分由相互之間獨(dú)立的Broker節(jié)點(diǎn)組成，每個(gè)Broker節(jié)點(diǎn)對(duì)本節(jié)點(diǎn)內(nèi)的Topic集合進(jìn)行管理，包括Topic的增、刪、改、查，Topic內(nèi)的消息存儲(chǔ)、消費(fèi)、老化、分區(qū)擴(kuò)容、數(shù)據(jù)消費(fèi)的offset記錄等，集群對(duì)外能力，包括Topic數(shù)目、吞吐量、容量等，通過水平擴(kuò)展Broker節(jié)點(diǎn)來完成；

Client： 負(fù)責(zé)數(shù)據(jù)生產(chǎn)和消費(fèi)的Client部分，該部分我們以Lib形式對(duì)外提供，大家用得最多的是消費(fèi)端，相比之前，消費(fèi)端現(xiàn)支持Push、Pull兩種數(shù)據(jù)拉取模式，數(shù)據(jù)消費(fèi)行為支持順序和過濾消費(fèi)兩種。對(duì)于Pull消費(fèi)模式，支持業(yè)務(wù)通過客戶端重置精確offset以支持業(yè)務(wù)extractly-once消費(fèi)，同時(shí)，消費(fèi)端新推出跨集群切換免重啟的BidConsumer客戶端；

Zookeeper： 負(fù)責(zé)offset存儲(chǔ)的zk部分，該部分功能已弱化到僅做offset的持久化存儲(chǔ)，考慮到接下來的多節(jié)點(diǎn)副本功能該模塊暫時(shí)保留。

相比KAFKA,TUBEMQ的系統(tǒng)特點(diǎn)：

純Java實(shí)現(xiàn)語(yǔ)言： 

TubeMQ采用純Java語(yǔ)言開發(fā)，便于開發(fā)人員快速熟悉項(xiàng)目及問題處理；

引入Master協(xié)調(diào)節(jié)點(diǎn)： 

相比Kafka依賴于Zookeeper完成元數(shù)據(jù)的管理和實(shí)現(xiàn)HA保障不同，TubeMQ系統(tǒng)采用的是自管理的元數(shù)據(jù)仲裁機(jī)制方式進(jìn)行，Master節(jié)點(diǎn)通過采用內(nèi)嵌數(shù)據(jù)庫(kù)BDB完成集群內(nèi)元數(shù)據(jù)的存儲(chǔ)、更新以及HA熱切功能，負(fù)責(zé)TubeMQ集群的運(yùn)行管控和配置管理操作，對(duì)外提供接口等；通過Master節(jié)點(diǎn)，TubeMQ集群里的Broker配置設(shè)置、變更及查詢實(shí)現(xiàn)了完整的自動(dòng)化閉環(huán)管理，減輕了系統(tǒng)維護(hù)的復(fù)雜度；

服務(wù)器側(cè)消費(fèi)負(fù)載均衡： 

TubeMQ采用的是服務(wù)側(cè)負(fù)載均衡的方案，而不是客戶端側(cè)操作，提升系統(tǒng)的管控能力同時(shí)簡(jiǎn)化客戶端實(shí)現(xiàn)，更便于均衡算法升級(jí)；

系統(tǒng)行級(jí)鎖操作： 

對(duì)于Broker消息讀寫中存在中間狀態(tài)的并發(fā)操作采用行級(jí)鎖，避免重復(fù)問題；

Offset管理調(diào)整：

 Offset由各個(gè)Broker獨(dú)自管理，ZK只作數(shù)據(jù)持久化存儲(chǔ)用（最初考慮完全去掉ZK依賴，考慮到后續(xù)的功能擴(kuò)展就暫時(shí)保留）；

消息讀取機(jī)制的改進(jìn)：

 相比于Kafka的順序塊讀,TubeMQ采用的是消息隨機(jī)讀取模式,同時(shí)為了降低消息時(shí)延又增加了內(nèi)存緩存讀寫,對(duì)于帶SSD設(shè)備的機(jī)器,增加消息滯后轉(zhuǎn)SSD消費(fèi)的處理，解決消費(fèi)嚴(yán)重滯后時(shí)吞吐量下降以及SSD磁盤容量小、刷盤次數(shù)有限的問題，使其滿足業(yè)務(wù)快速生產(chǎn)消費(fèi)的需求（后面章節(jié)詳細(xì)介紹）；

消費(fèi)者行為管控： 

支持通過策略實(shí)時(shí)動(dòng)態(tài)地控制系統(tǒng)接入的消費(fèi)者行為，包括系統(tǒng)負(fù)載高時(shí)對(duì)特定業(yè)務(wù)的限流、暫停消費(fèi)，動(dòng)態(tài)調(diào)整數(shù)據(jù)拉取的頻率等；

服務(wù)分級(jí)管控：

 針對(duì)系統(tǒng)運(yùn)維、業(yè)務(wù)特點(diǎn)、機(jī)器負(fù)載狀態(tài)的不同需求，系統(tǒng)支持運(yùn)維通過策略來動(dòng)態(tài)控制不同消費(fèi)者的消費(fèi)行為，比如是否有權(quán)限消費(fèi)、消費(fèi)時(shí)延分級(jí)保證、消費(fèi)限流控制，以及數(shù)據(jù)拉取頻率控制等；

系統(tǒng)安全管控：

 根據(jù)業(yè)務(wù)不同的數(shù)據(jù)服務(wù)需要，以及系統(tǒng)運(yùn)維安全的考慮，TubeMQ系統(tǒng)增加了TLS傳輸層加密管道，生產(chǎn)和消費(fèi)服務(wù)的認(rèn)證、授權(quán)，以及針對(duì)分布式訪問控制的訪問令牌管理，滿足業(yè)務(wù)和系統(tǒng)運(yùn)維在系統(tǒng)安全方面的需求；

資源利用率提升改進(jìn)：

 相比于Kafka，TubeMQ采用連接復(fù)用模式，減少連接資源消耗；通過邏輯分區(qū)構(gòu)造，減少系統(tǒng)對(duì)文件句柄數(shù)的占用，通過服務(wù)器端過濾模式，減少網(wǎng)絡(luò)帶寬資源使用率；通過剝離對(duì)Zookeeper的使用，減少Zookeeper的強(qiáng)依賴及瓶頸限制；

客戶端改進(jìn)：

 基于業(yè)務(wù)使用上的便利性以，我們簡(jiǎn)化了客戶端邏輯，使其做到最小的功能集合，我們采用基于響應(yīng)消息的接收質(zhì)量統(tǒng)計(jì)算法來自動(dòng)剔出壞的Broker節(jié)點(diǎn)，基于首次使用時(shí)作連接嘗試來避免大數(shù)據(jù)量發(fā)送時(shí)發(fā)送受阻（具體內(nèi)容見后面章節(jié)介紹）。

BROKER文件存儲(chǔ)方案改進(jìn)：

以磁盤為數(shù)據(jù)持久化媒介的系統(tǒng)都面臨各種因磁盤問題導(dǎo)致的系統(tǒng)性能問題，TubeMQ系統(tǒng)也不例外，性能提升很大程度上是在解決消息數(shù)據(jù)如何讀寫及存儲(chǔ)的問題，在這個(gè)方面TubeMQ進(jìn)行了比較多的改進(jìn)：

1.文件結(jié)構(gòu)組織形式調(diào)整： 

TubeMQ的磁盤存儲(chǔ)方案類似Kafka，但又不盡相同，如下圖示，存儲(chǔ)實(shí)例由一個(gè)索引文件和一個(gè)數(shù)據(jù)文件組成，每個(gè)Topic可以分配1個(gè)或者多個(gè)存儲(chǔ)實(shí)例，每個(gè)Topic單獨(dú)維護(hù)管理存儲(chǔ)實(shí)例的相關(guān)機(jī)制，包括老化周期，partition個(gè)數(shù)，是否可讀可寫等：

2.內(nèi)存塊緩存：

在文件存儲(chǔ)基礎(chǔ)上，我們針對(duì)每個(gè)存儲(chǔ)實(shí)例又額外增加了一個(gè)單獨(dú)的內(nèi)存緩存塊，即在原有寫磁盤基礎(chǔ)上增加一塊內(nèi)存，隔離硬盤的慢速影響，數(shù)據(jù)先刷到內(nèi)存，然后由內(nèi)存控制塊批量地將數(shù)據(jù)刷到磁盤文件：

3.SSD輔助存儲(chǔ)： 

針對(duì)除了由磁盤存儲(chǔ)外還帶SSD硬件的服務(wù)器，我們又做了一層SSD輔助存儲(chǔ)，該方案有別于外界系統(tǒng)先將數(shù)據(jù)存SSD，然后再將數(shù)據(jù)由SSD轉(zhuǎn)到磁盤的通常做法：按照我們的分析，正常情況下磁盤的順序讀寫性能已足夠滿足數(shù)據(jù)持久化的需求，磁盤IO到100%時(shí)的性能下降主要是由于滯后消費(fèi)引起，滯后的比例越大影響越大；SSD相比磁盤，雖然讀寫速度近似內(nèi)存但寫入次數(shù)有限，像MQ這種每天大量寫的系統(tǒng)很有可能因?yàn)镾SD突然變得不可寫帶來系統(tǒng)風(fēng)險(xiǎn)?；谶@些考慮，我們采用了動(dòng)態(tài)的SSD轉(zhuǎn)存儲(chǔ)消費(fèi)方案：正常情況下數(shù)據(jù)走磁盤讀寫消費(fèi)；數(shù)據(jù)擠壓情況出現(xiàn)，并且持續(xù)的狀態(tài)觸發(fā)運(yùn)維設(shè)置的閥值時(shí)，滯后的數(shù)據(jù)消費(fèi)將被轉(zhuǎn)移到SSD上進(jìn)行；數(shù)據(jù)擠壓情況解除后，SSD停用數(shù)據(jù)繼續(xù)走磁盤進(jìn)行讀寫，這樣在磁盤IO飆升時(shí)候?qū)笙M(fèi)讀進(jìn)行轉(zhuǎn)移，避免讀寫集中在SATA盤上：

目前我們?nèi)栽谔剿餍碌拇鎯?chǔ)方案，后續(xù)版本中我們會(huì)將實(shí)踐后的內(nèi)容分享到大家。

TUBEMQ客戶端的演進(jìn)：

業(yè)務(wù)與TubeMQ接觸得最多的是消費(fèi)側(cè)，怎樣更適應(yīng)業(yè)務(wù)特點(diǎn)、更方便業(yè)務(wù)使用我們?cè)谶@塊做了比較多的改進(jìn)：

1.數(shù)據(jù)拉取模式支持Push、Pull：

• Push客戶端： TubeMQ最初消費(fèi)端版本只提供Push模式的消費(fèi)，這種模式能比較快速地消費(fèi)數(shù)據(jù)，減輕服務(wù)端壓力，但同時(shí)也帶來一個(gè)問題，業(yè)務(wù)使用的時(shí)候因?yàn)闊o(wú)法控制拉取頻率，從而容易形成數(shù)據(jù)積壓數(shù)據(jù)處理不過來；
• 帶消費(fèi)中止/繼續(xù)的Push客戶端： 在收到業(yè)務(wù)反饋能否控制Push拉取動(dòng)作的需求后，我們?cè)黾恿藃esumeConsume()/pauseConsume()函數(shù)對(duì)，讓業(yè)務(wù)可以模擬水位線控制機(jī)制，狀態(tài)比較繁忙時(shí)調(diào)用pauseConsume()函數(shù)來中止Lib后臺(tái)的數(shù)據(jù)拉取，在狀態(tài)恢復(fù)后，再調(diào)用resumeConsume()通知Lib后臺(tái)繼續(xù)拉取數(shù)據(jù)；
• Pull客戶端： 我們后來版本里增加了Pull客戶端，該客戶端有別于Push客戶端，是由業(yè)務(wù)而非Lib主動(dòng)的拉取消息并對(duì)數(shù)據(jù)處理的結(jié)果進(jìn)行成功與否的確認(rèn)，將數(shù)據(jù)處理的主動(dòng)權(quán)留給業(yè)務(wù)。這樣處理后，雖然服務(wù)端壓力有所提升，但業(yè)務(wù)消費(fèi)時(shí)積壓情況可大大緩解。

2.數(shù)據(jù)消費(fèi)行為支持順序和過濾消費(fèi)：

 在TubeMQ設(shè)計(jì)初我們考慮是不同業(yè)務(wù)使用不同的Topic，實(shí)際運(yùn)營(yíng)中我們發(fā)現(xiàn)不少業(yè)務(wù)實(shí)際上是通過代理模式上報(bào)的數(shù)據(jù)，數(shù)據(jù)通過Topic下的文件ID或者表ID屬性來區(qū)分，業(yè)務(wù)為了消費(fèi)自己的一份數(shù)據(jù)是需要全量消費(fèi)該Topic下的所有數(shù)據(jù)。我們通過tid字段支持指定屬性的過濾消費(fèi)模式，將數(shù)據(jù)過濾放到服務(wù)端來做，減少出流量以及客戶端的數(shù)據(jù)處理壓力。

3.支持業(yè)務(wù)extractly-once消費(fèi)：

 為了解決業(yè)務(wù)處理數(shù)據(jù)時(shí)需要精確回檔的需求，在客戶端版本里提供了通過客戶端重置精確offset功能，業(yè)務(wù)重啟系統(tǒng)時(shí)，只需通過客戶端提供待回?fù)軙r(shí)間點(diǎn)的消費(fèi)上下文，TubeMQ即可按照指定的精確位置接續(xù)消費(fèi)。該特性目前已在Flink這類實(shí)時(shí)計(jì)算框架使用，依托Flink基于checkpoint機(jī)制進(jìn)行extractly-once數(shù)據(jù)處理。

以上就是騰訊開源消息中間件TubeMQ總體介紹分析的詳細(xì)內(nèi)容，更多關(guān)于騰訊開源消息中間件TubeMQ的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論