TubeMQ總體介紹

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

項目地址：https://github.com/Tencent/TubeMQ

TUBEMQ的性能：

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

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

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

與當前MQ橫向對比分析：

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

TUBEMQ集群架構：

經過多年演變，TubeMQ集群分為如下5個部分： 

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

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

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

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

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

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

純Java實現(xiàn)語言： 

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

引入Master協(xié)調節(jié)點： 

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

服務器側消費負載均衡： 

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

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

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

Offset管理調整：

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

消息讀取機制的改進：

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

消費者行為管控： 

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

服務分級管控：

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

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

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

資源利用率提升改進：

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

客戶端改進：

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

BROKER文件存儲方案改進：

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

1.文件結構組織形式調整： 

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

2.內存塊緩存：

在文件存儲基礎上，我們針對每個存儲實例又額外增加了一個單獨的內存緩存塊，即在原有寫磁盤基礎上增加一塊內存，隔離硬盤的慢速影響，數據先刷到內存，然后由內存控制塊批量地將數據刷到磁盤文件：

3.SSD輔助存儲： 

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

目前我們仍在探索新的存儲方案，后續(xù)版本中我們會將實踐后的內容分享到大家。

TUBEMQ客戶端的演進：

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

1.數據拉取模式支持Push、Pull：

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

2.數據消費行為支持順序和過濾消費：

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

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

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

以上就是騰訊開源消息中間件TubeMQ總體介紹分析的詳細內容，更多關于騰訊開源消息中間件TubeMQ的資料請關注腳本之家其它相關文章！

最新評論