Apache InLong分布式消息中間件系統(tǒng)

Apache InLong（原 Apache TubeMQ 項目更名）是騰訊在 2013 年自研的分布式消息中間件系統(tǒng)，專注服務(wù)大數(shù)據(jù)場景下海量數(shù)據(jù)的高性能存儲和傳輸，較之于眾多明星的開源 MQ組件，TubeMQ 在海量實踐（穩(wěn)定性+性能）和低成本方面有著比較好的核心優(yōu)勢。

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

特性：

• 純 Java 實現(xiàn)語言
• 引入 Master 協(xié)調(diào)節(jié)點：相比 Kafka 依賴于 Zookeeper 完成元數(shù)據(jù)的管理和實現(xiàn) HA 保障不同，TubeMQ 系統(tǒng)采用的是自管理的元數(shù)據(jù)仲裁機(jī)制方式進(jìn)行，Master 節(jié)點通過采用內(nèi)嵌數(shù)據(jù)庫 BDB 完成集群內(nèi)元數(shù)據(jù)的存儲、更新以及 HA 熱切功能，負(fù)責(zé) TubeMQ 集群的運(yùn)行管控和配置管理操作，對外提供接口等；通過 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ī)制的改進(jìn)：TubeMQ 采用的是消息隨機(jī)讀取模式,同時為了降低消息時延又增加了內(nèi)存緩存讀寫,對于帶 SSD 設(shè)備的機(jī)器,增加消息滯后轉(zhuǎn) SSD 消費的處理，解決消費嚴(yán)重滯后時吞吐量下降以及 SSD 磁盤容量小、刷盤次數(shù)有限的問題，使其滿足業(yè)務(wù)快速生產(chǎn)消費的需求
• 消費者行為管控：支持通過策略實時動態(tài)地控制系統(tǒng)接入的消費者行為，包括系統(tǒng)負(fù)載高時對特定業(yè)務(wù)的限流、暫停消費，動態(tài)調(diào)整數(shù)據(jù)拉取的頻率等；
• 服務(wù)分級管控：針對系統(tǒng)運(yùn)維、業(yè)務(wù)特點、機(jī)器負(fù)載狀態(tài)的不同需求，系統(tǒng)支持運(yùn)維通過策略來動態(tài)控制不同消費者的消費行為，比如是否有權(quán)限消費、消費時延分級保證、消費限流控制，以及數(shù)據(jù)拉取頻率控制等
• 系統(tǒng)安全管控：根據(jù)業(yè)務(wù)不同的數(shù)據(jù)服務(wù)需要，以及系統(tǒng)運(yùn)維安全的考慮，TubeMQ 系統(tǒng)增加了 TLS 傳輸層加密管道，生產(chǎn)和消費服務(wù)的認(rèn)證、授權(quán)，以及針對分布式訪問控制的訪問令牌管理，滿足業(yè)務(wù)和系統(tǒng)運(yùn)維在系統(tǒng)安全方面的需求
• 資源利用率提升改進(jìn)：相比于 Kafka，TubeMQ 采用連接復(fù)用模式，減少連接資源消耗；通過邏輯分區(qū)構(gòu)造，減少系統(tǒng)對文件句柄數(shù)的占用，通過服務(wù)器端過濾模式，減少網(wǎng)絡(luò)帶寬資源使用率；通過剝離對 Zookeeper 的使用，減少 Zookeeper 的強(qiáng)依賴及瓶頸限制
• 客戶端改進(jìn)：基于業(yè)務(wù)使用上的便利性以，我們簡化了客戶端邏輯，使其做到最小的功能集合，我們采用基于響應(yīng)消息的接收質(zhì)量統(tǒng)計算法來自動剔出壞的 Broker 節(jié)點，基于首次使用時作連接嘗試來避免大數(shù)據(jù)量發(fā)送時發(fā)送受阻