騰訊自研高吞吐消息隊列組件TubeMQ升級爲 TubeHub，挑戰RocketMQ

TubeMQ簡介

TubeMQ 是騰訊在 2013 年自研的分佈式消息中間件系統，專一服務大數據場景下海量數據的高性能存儲和傳輸，較之於衆多明星的開源 MQ組件，TubeMQ 在海量實踐（穩定性+性能）和低成本方面有着比較好的核心優點。

2019 年 9 月 12 日，Apache 軟件基金會成立 20 週年之際，騰訊在 ApacheCon 宣佈 TubeMQ 捐贈給 ASF。TubeMQ 成爲騰訊開源第一個捐贈 Apache 基金會的項目。

變動說明

近日，Apache TubeMQ 項目負責人宣佈該項目將進行全面升級拓展，並改名爲 TubeHub 。

升級後的項目將命名爲 TubeHub，具備全部組件可插拔、可隔離、可伸縮和可監控的雲原生特性，爲開發者提供一站式的流式大數據解決方案，包括自動、安全、高性能、分佈式的數據發佈訂閱能力，便於使用者在業務上構建基於流式的數據應用，例如滾動的日誌、MySQL 的 binlog 等。

在 Apache 基金會一年的項目孵化過程當中，項目團隊新增了 40+ 的 contributores，社區提交了 400+ issuses，合併了 300+ PRs，共發佈了 4 個版本。項目團隊決定對 TubeMQ 進行全面的升級 —— 即在保留本來 mq 的功能特性以外，同時提供一個包含了大數據場景下的數據採集落地的總體集成方案。 

特性

• 純 Java 實現語言

• 引入 Master 協調節點：相比 Kafka 依賴於 Zookeeper 完成元數據的管理和實現 HA 保障不一樣，TubeMQ 系統採用的是自管理的元數據仲裁機制方式進行，Master 節點經過採用內嵌數據庫 BDB 完成集羣內元數據的存儲、更新以及 HA 熱切功能，負責 TubeMQ 集羣的運行管控和配置管理操做，對外提供接口等；經過 Master 節點，TubeMQ 集羣裏的 Broker 配置設置、變動及查詢實現了完整的自動化閉環管理，減輕了系統維護的複雜度

• 服務器側消費負載均衡：TubeMQ 採用的是服務側負載均衡的方案，而不是客戶端側操做，提高系統的管控能力同時簡化客戶端實現，更便於均衡算法升級

• 系統行級鎖操做：對於 Broker 消息讀寫中存在中間狀態的併發操做採用行級鎖，避免重複問題

• Offset 管理調整：Offset 由各個 Broker 獨自管理，ZK 只做數據持久化存儲用（最初考慮徹底去掉ZK依賴，考慮到後續的功能擴展就暫時保留）

• 消息讀取機制的改進：TubeMQ 採用的是消息隨機讀取模式,同時爲了下降消息時延又增長了內存緩存讀寫,對於帶 SSD 設備的機器,增長消息滯後轉 SSD 消費的處理，解決消費嚴重滯後時吞吐量降低以及 SSD 磁盤容量小、刷盤次數有限的問題，使其知足業務快速生產消費的需求

• 消費者行爲管控：支持經過策略實時動態地控制系統接入的消費者行爲，包括系統負載高時對特定業務的限流、暫停消費，動態調整數據拉取的頻率等；

• 服務分級管控：針對系統運維、業務特色、機器負載狀態的不一樣需求，系統支持運維經過策略來動態控制不一樣消費者的消費行爲，好比是否有權限消費、消費時延分級保證、消費限流控制，以及數據拉取頻率控制等

• 系統安全管控：根據業務不一樣的數據服務須要，以及系統運維安全的考慮，TubeMQ 系統增長了 TLS 傳輸層加密管道，生產和消費服務的認證、受權，以及針對分佈式訪問控制的訪問令牌管理，知足業務和系統運維在系統安全方面的需求

• 資源利用率提高改進：相比於 Kafka，TubeMQ 採用鏈接複用模式，減小鏈接資源消耗；經過邏輯分區構造，減小系統對文件句柄數的佔用，經過服務器端過濾模式，減小網絡帶寬資源使用率；經過剝離對 Zookeeper 的使用，減小 Zookeeper 的強依賴及瓶頸限制

• 客戶端改進：基於業務使用上的便利性以，咱們簡化了客戶端邏輯，使其作到最小的功能集合，咱們採用基於響應消息的接收質量統計算法來自動剔出壞的 Broker 節點，基於首次使用時做鏈接嘗試來避免大數據量發送時發送受阻