騰訊開源訊息中介軟體TubeMQ總體介紹分析

TubeMQ總體介紹

TubeMQ是騰訊巨量資料在2013年開始研發的分散式訊息中介軟體系統（MQ），專注服務巨量資料場景下海量資料的高效能儲存和傳輸。經過近7年上萬億的海量資料沉澱，較之於眾多的開源MQ元件，TubeMQ在海量實踐（穩定性+效能）和低成本方面有一定的優勢。一個禮拜前，TubeMQ開源了，本篇博文轉載自官方公佈的檔案。博主花了半天搭建開發環境到執行，到傳送訊息接收訊息體驗下來，發現不管是騰訊的TubeMQ，還是rocketmq，他們的架構都或多或少參考了kafka的設計，所以上手會非常快。而且，開源版本很可能是內部版本的剖離版，剛開源還沒來得及打磨，沒做全面的驗證測試。因為博主在測試過程中發現了一個特別大的bug，consumer接收訊息時導致CPU100%，而且是必現的，有興趣的可以去issue檢視，博主提交issue後，官方開發立馬就跟進了，這速度也是沒誰了。相信不久後TubeMQ會是繼kafka和rocketmq後又一個非常不錯的選擇。TubeMQ也有捐贈給Apache的想法，Apache中國內的頂級專案越來越多了，國內的開源大環境也越來越好了

專案地址：https://github.com/Tencent/TubeMQ

TUBEMQ的效能：

從TubeMQ架構圖可以很清晰的看到，作為分散式的訊息中介軟體系統，Broker單節點的效能情況直接影響到叢集總體的效能表現，即相同的節點數下Broker節點效能越高則TubeMQ的總體效能越強。下表是根據我們多年的線上運營經驗總結的典型場景： 

通過對TubeMQ與Kafka進行對比測試分析（詳情見《TubeMQ VS Kafka效能對比測試總結V1.0.md》），在1份寫入2份並行消費的場景下，從機型、關鍵設定、系統測試結果資料的對比中我們可以很清晰的看到TubeMQ的效能情況，用大家熟悉的復仇者聯盟角色類比，相當於是如下表的情況總結: 

總的來說：Kafka按照順序寫 + 順序塊讀的模式實現，單範例下效能資料很強，但隨著範例數增多，它的效能就呈現不穩定下降狀態；TubeMQ採用順序寫 + 隨機讀的模式，即使在最大限制下系統仍可以做到長期穩定的1G以上的入流量，同時，結合伺服器端過濾過濾消費非常順暢。

與當前MQ橫向對比分析：

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

TUBEMQ叢集架構：

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

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

Master： 負責叢集控制的Control部分，該部分由1個或多個Master節點組成，Master HA通過Master節點間心跳保活、實時熱備切換完成（這是大家使用TubeMQ的Lib時需要填寫對應叢集所有Master節點地址的原因），主Master負責管理整個叢集的狀態、資源排程、許可權檢查、後設資料查詢等；

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

Client： 負責資料生產和消費的Client部分，該部分我們以Lib形式對外提供，大家用得最多的是消費端，相比之前，消費端現支援Push、Pull兩種資料拉取模式，資料消費行為支援順序和過濾消費兩種。對於Pull消費模式，支援業務通過使用者端重置精確offset以支援業務extractly-once消費，同時，消費端新推出跨叢集切換免重啟的BidConsumer使用者端；

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

相比KAFKA,TUBEMQ的系統特點：

純Java實現語言： 

TubeMQ採用純Java語言開發，便於開發人員快速熟悉專案及問題處理；

引入Master協調節點： 

相比Kafka依賴於Zookeeper完成後設資料的管理和實現HA保障不同，TubeMQ系統採用的是自管理的後設資料仲裁機制方式進行，Master節點通過採用內嵌資料庫BDB完成叢集內後設資料的儲存、更新以及HA熱切功能，負責TubeMQ叢集的執行管控和設定管理操作，對外提供介面等；通過Master節點，TubeMQ叢集裡的Broker設定設定、變更及查詢實現了完整的自動化閉環管理，減輕了系統維護的複雜度；

伺服器側消費負載均衡： 

TubeMQ採用的是服務側負載均衡的方案，而不是使用者端側操作，提升系統的管控能力同時簡化使用者端實現，更便於均衡演演算法升級；

系統行級鎖操作： 

對於Broker訊息讀寫中存在中間狀態的並行操作採用行級鎖，避免重複問題；

Offset管理調整：

 Offset由各個Broker獨自管理，ZK只作資料持久化儲存用（最初考慮完全去掉ZK依賴，考慮到後續的功能擴充套件就暫時保留）；

訊息讀取機制的改進：

 相比於Kafka的順序塊讀,TubeMQ採用的是訊息隨機讀取模式,同時為了降低訊息時延又增加了記憶體快取讀寫,對於帶SSD裝置的機器,增加訊息滯後轉SSD消費的處理，解決消費嚴重滯後時吞吐量下降以及SSD磁碟容量小、刷盤次數有限的問題，使其滿足業務快速生產消費的需求（後面章節詳細介紹）；

消費者行為管控： 

支援通過策略實時動態地控制系統接入的消費者行為，包括系統負載高時對特定業務的限流、暫停消費，動態調整資料拉取的頻率等；

服務分級管控：

 針對系統運維、業務特點、機器負載狀態的不同需求，系統支援運維通過策略來動態控制不同消費者的消費行為，比如是否有許可權消費、消費時延分級保證、消費限流控制，以及資料拉取頻率控制等；

系統安全管控：

 根據業務不同的資料服務需要，以及系統運維安全的考慮，TubeMQ系統增加了TLS傳輸層加密管道，生產和消費服務的認證、授權，以及針對分散式存取控制的存取令牌管理，滿足業務和系統運維在系統安全方面的需求；

資源利用率提升改進：

 相比於Kafka，TubeMQ採用連線複用模式，減少連線資源消耗；通過邏輯分割區構造，減少系統對檔案控制程式碼數的佔用，通過伺服器端過濾模式，減少網路頻寬資源使用率；通過剝離對Zookeeper的使用，減少Zookeeper的強依賴及瓶頸限制；

使用者端改進：

 基於業務使用上的便利性以，我們簡化了使用者端邏輯，使其做到最小的功能集合，我們採用基於響應訊息的接收質量統計演演算法來自動剔出壞的Broker節點，基於首次使用時作連線嘗試來避免巨量資料量傳送時傳送受阻（具體內容見後面章節介紹）。

BROKER檔案儲存方案改進：

以磁碟為資料持久化媒介的系統都面臨各種因磁碟問題導致的系統效能問題，TubeMQ系統也不例外，效能提升很大程度上是在解決訊息資料如何讀寫及儲存的問題，在這個方面TubeMQ進行了比較多的改進：

1.檔案結構組織形式調整： 

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

2.記憶體塊快取：

在檔案儲存基礎上，我們針對每個儲存範例又額外增加了一個單獨的記憶體快取塊，即在原有寫磁碟基礎上增加一塊記憶體，隔離硬碟的慢速影響，資料先刷到記憶體，然後由記憶體控制塊批次地將資料刷到磁碟檔案：

3.SSD輔助儲存： 

針對除了由磁碟儲存外還帶SSD硬體的伺服器，我們又做了一層SSD輔助儲存，該方案有別於外界系統先將資料存SSD，然後再將資料由SSD轉到磁碟的通常做法：按照我們的分析，正常情況下磁碟的順序讀寫效能已足夠滿足資料持久化的需求，磁碟IO到100%時的效能下降主要是由於滯後消費引起，滯後的比例越大影響越大；SSD相比磁碟，雖然讀寫速度近似記憶體但寫入次數有限，像MQ這種每天大量寫的系統很有可能因為SSD突然變得不可寫帶來系統風險。基於這些考慮，我們採用了動態的SSD轉儲存消費方案：正常情況下資料走磁碟讀寫消費；資料擠壓情況出現，並且持續的狀態觸發運維設定的閥值時，滯後的資料消費將被轉移到SSD上進行；資料擠壓情況解除後，SSD停用資料繼續走磁碟進行讀寫，這樣在磁碟IO飆升時候將滯後消費讀進行轉移，避免讀寫集中在SATA盤上：

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

TUBEMQ使用者端的演進：

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

1.資料拉取模式支援Push、Pull：

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

2.資料消費行為支援順序和過濾消費：

 在TubeMQ設計初我們考慮是不同業務使用不同的Topic，實際運營中我們發現不少業務實際上是通過代理模式上報的資料，資料通過Topic下的檔案ID或者表ID屬性來區分，業務為了消費自己的一份資料是需要全量消費該Topic下的所有資料。我們通過tid欄位支援指定屬性的過濾消費模式，將資料過濾放到伺服器端來做，減少出流量以及使用者端的資料處理壓力。

3.支援業務extractly-once消費：

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

以上就是騰訊開源訊息中介軟體TubeMQ總體介紹分析的詳細內容，更多關於騰訊開源訊息中介軟體TubeMQ的資料請關注it145.com其它相關文章！