作者 |?kimmking

來源 | CSDN博客，責(zé)編 | 夕顏

出品 | CSDN（ID:CSDNnews）

隨著分布式技術(shù)的發(fā)展，MQ技術(shù)產(chǎn)品也出現(xiàn)井噴。目前除了各類常用的MQ，比如Apache的ActiveMQ，Kafka，Pulsar，RocketMQ（既是Apache，也是阿里的，頭條也是基于RocketMQ），以及RabbitMQ（美團(tuán)、汽車之家大量使用）外，各大廠商都自研了自己的產(chǎn)品，騰訊的CMQ和TubeMQ，京東的JMQ，去哪兒的QMQ，滴滴的DDMQ（基于RocketMQ），其中不少都開源了。這里說一下今年開源的TubeMQ。

騰訊開源的TubeMQ

官方介紹如下：

https://github.com/Tencent/TubeMQ/blob/master/docs/tubemq_basic_introduction_cn.md

TubeMQ是騰訊大數(shù)據(jù)在2013年開始研發(fā)的分布式消息中間件系統(tǒng)（MQ），專注服務(wù)大數(shù)據(jù)場景下海量數(shù)據(jù)的高性能存儲和傳輸。經(jīng)過近7年上萬億的海量數(shù)據(jù)沉淀，較之于眾多的開源MQ組件，TubeMQ在海量實踐（穩(wěn)定性+性能）和低成本方面有一定的優(yōu)勢，近期我們在開源TubeMQ的相關(guān)代碼及設(shè)計，更多資料正在陸續(xù)整理。

TubeMQ集群架構(gòu)：

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

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

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

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

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

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

比較常規(guī)的分布式MQ結(jié)構(gòu)，broker功能比較重。

相比Kafka,TubeMQ的系統(tǒng)特點：

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

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

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

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

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

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

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

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

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

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

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

這一塊基本上說清楚了特點，以及與其他MQ的一些特色的地方，其實可以猜到，一直在和kafka做對比，很多地方參與并改進(jìn)了kafka，在管理能力上做了不少思考和新的實現(xiàn)。

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

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

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

• Push客戶端：TubeMQ最初消費端版本只提供Push模式的消費，這種模式能比較快速地消費數(shù)據(jù)，減輕服務(wù)端壓力，但同時也帶來一個問題，業(yè)務(wù)使用的時候因為無法控制拉取頻率，從而容易形成數(shù)據(jù)積壓數(shù)據(jù)處理不過來；

• • 帶消費中止/繼續(xù)的Push客戶端：在收到業(yè)務(wù)反饋能否控制Push拉取動作的需求后，我們增加了resumeConsume()/pauseConsume()函數(shù)對，讓業(yè)務(wù)可以模擬水位線控制機制，狀態(tài)比較繁忙時調(diào)用pauseConsume()函數(shù)來中止Lib后臺的數(shù)據(jù)拉取，在狀態(tài)恢復(fù)后，再調(diào)用resumeConsume()通知Lib后臺繼續(xù)拉取數(shù)據(jù)；

  • Pull客戶端：我們后來版本里增加了Pull客戶端，該客戶端有別于 – Push客戶端，是由業(yè)務(wù)而非Lib主動的拉取消息并對數(shù)據(jù)處理的結(jié)果進(jìn)行成功與否的確認(rèn)，將數(shù)據(jù)處理的主動權(quán)留給業(yè)務(wù)。這樣處理后，雖然服務(wù)端壓力有所提升，但業(yè)務(wù)消費時積壓情況可大大緩解。

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

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

推和拉是消息處理的兩個最基礎(chǔ)模式。推對服務(wù)器處理來說更簡單，推出去就不管了，broker變輕，但是可能單位時間推太多，導(dǎo)致消費端積壓，壓垮了client端系統(tǒng)。拉則意味著，你隨時來拿數(shù)據(jù)，broker都要保持狀態(tài)而且會產(chǎn)生積壓，還需要處理重試策略等。有了offset則意味著可以隨時回溯消息，但是這樣可能會導(dǎo)致重復(fù)，如果沒有內(nèi)置的去重其實不是extractly once，而是atleast once，消息會重復(fù)。

其他幾個mq

滴滴的DDMQ：

https://github.com/didi/DDMQ/blob/master/README_CN.md

去哪兒網(wǎng)的QMQ：

https://github.com/qunarcorp/qmq

有意思的幾個點

TubeMQ跟 kafka，rocketmq，pulsar等主流的MQ架構(gòu)上有什么差別？

官方給出的意見是：

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

個人對這個持保留意見，大量創(chuàng)建topic不適合kafka的設(shè)計原則（一般我們建議單集群的topic數(shù)量在100以內(nèi)，過多的小topic造成隨機讀寫，但是可以合并，然后區(qū)分和路由消息即可），同時如果改成SSD盤也可以提升吞吐和延遲，幾千個topic問題不大。而且kafka的延遲也不像上面的文檔里對比說的250ms，我們實際使用大概在10-40ms之間。

TubeMQ看了一下，整體設(shè)計跟pulsar有點像，主要是broker和storage做了分離；消息處理模式上跟ActiveMQ到底有些許接近。

幾個有意思的地方：

1、TubeMQ不支持多副本，這樣的話單機有可能還是在極端情況下丟失數(shù)據(jù)，但多副本是目前的各種分布式消息隊列的標(biāo)配（看了一下騰訊云上的商業(yè)版本CMQ是支持的。）

2、服務(wù)器側(cè)消費負(fù)載均衡，早期版本的kafka是這樣的，問題挺多

3、消息隨機讀，這樣需要加內(nèi)存緩存和依賴SSD，挺詭異，為了并發(fā)又加了鎖，這一塊很復(fù)雜，ActiveMQ就是因為內(nèi)存的處理太復(fù)雜，導(dǎo)致量一大，誰都用不好

4、同時支持推和拉，這一點也挺有意思，跟第一條一條有關(guān)系，要是支持推的話，服務(wù)端肯定需要有狀態(tài)

5、支持服務(wù)器端的消息過濾，現(xiàn)在一般的MQ都是客戶端過濾，也同理。

MQ發(fā)現(xiàn)到現(xiàn)在，一共經(jīng)歷了三代，分別以ActiveMQ，Kafka/RocketMQ，Pulsar為代表，從趨勢上來看，越來越分布式、趨向?qū)υ圃闹С?#xff0c;越來越無狀態(tài)，broker越來越輕薄。

總之這個方案看起來是綜合了傳統(tǒng)和現(xiàn)在的各個MQ的一些特點，但是實現(xiàn)的很重。

還有個tip，TubeMQ里的組件名稱有點亂，叫master的東西，實際上是broker，叫broker的東西，實際上是storage（在pulsar里是bookie）。

原文鏈接：

https://blog.csdn.net/KimmKing/article/details/103133789

同時，歡迎所有開發(fā)者掃描下方二維碼填寫《開發(fā)者與AI大調(diào)研》，只需2分鐘，便可收獲價值299元的「AI開發(fā)者萬人大會」在線直播門票!

推薦閱讀：你知道嗎？其實 Oracle 直方圖自動統(tǒng)計算法存在這些缺陷！（附驗證步驟） 你公司的虛擬機還閑著？基于 Jenkins 和 Kubernetes 的持續(xù)集成測試實踐了解一下！一站式殺手級 AI 開發(fā)平臺來襲！告別切換零散建模工具那些神一樣的程序員 比特幣當(dāng)贖金，WannaRen 勒索病毒二度來襲！通過 Python 代碼實現(xiàn)時間序列數(shù)據(jù)的統(tǒng)計學(xué)預(yù)測模型 真香，朕在看了！

總結(jié)

以上是生活随笔為你收集整理的MQ 技术产品井喷，今天来详聊一下腾讯开源消息中间件 TubeMQ | 原力计划的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。