騰訊“瘋狂”開源！

作者 | 馬超

責編 | 胡巍巍

出品 | CSDN（ID：CSDNnews）

近日，騰訊自研的萬億級分散式訊息中介軟體TubeMQ正式開源，並捐贈給Apache基金會，成為基金會官方認可的Incubator專案。

我們知道與TubeMQ功能類似的kafka是領英公司在早在10年前捐贈給Apache基金會的金牌專案，而那時的騰訊還在忙於3Q大戰，公司文化也相對封閉，甚至連目前社交領域的絕對領跑者-微信都是騰訊內部競爭，獲得勝出的產品，所以誰也沒想到騰訊竟然有今天的轉變，成為了一家全面擁抱開源的科技公司。

 

走向開源的騰訊

 

在近日舉辦的騰訊Techo開發者大會上，騰訊正式對外表示將改變過去“自下而上”的開源模式，向“自下而上”與“自上而下”相結合的協同式開發演進。

其開源將在內部協同共建的基礎上，推動更底層、更重磅的技術對外開放，緊密參與開源社群建設，不斷完善開源治理，打造開發者共建的生態。

並建立對外開源管理辦公室，對開源專案進行指導和幫助，為開發者提供社群合作交流機會，建設以開源為核心的技術生態圈。

而且騰訊還真的不是隻做所謂PPT開源，筆者剛剛在Github上做了一下統計，目前騰訊在Github上釋出的總專案數達到90個，Star數破26萬；

而且其開源專案很多都堪稱重磅，如在18年騰訊將其高效能RPC開發框架TARS及其輕量化名字服務方案TSeer捐贈給Linux基金會，當時就獲得了業內的廣泛好評，今年以來騰訊開源勢頭更盛，先是開源了物聯網作業系統Tencent OS Tiny，而近期開源的TubeMQ算得上是社交巨頭騰訊的最核心技術了。

 

騰訊為何擁抱開源

 

筆者曾經分析過開源對於與IT技術發展的關係，此番再度思考之後筆者認為開源對於巨頭們來說有如下三個戰略意義：下：

開源之爭就是標準之爭：目前的開源之爭就是20年前的標準與智慧財產權之爭。比如谷歌的深度學習框架Tensorflow成為人工智慧方面的行業標準，靠的就是開源使用者的口口相傳，可以說誰掌握了最流行的開源專案，誰就掌握了話語權，從而主導行業的發展方向。

開源之爭就是入口之爭：目前各大IT廠商之所以紛紛推出自己的loT作業系統、深度學習框架等開源專案，其實本質的商業邏輯還是爭奪使用者的入口流量，掌握入口就能在未來競爭中掌握主動。

開源之爭就是全棧之爭：為了保證自己的基業長青，各巨頭基本要採用全技術棧不留死角的競爭策略，才能讓自己保持基業長青，目前類似於騰訊這樣的企業將自身從前端到後端的所有技術全部開源，供行業其它參考者模仿，就是要鞏固自身在行業內部的領先優勢，為自身的品牌價值及技術能力宣傳造勢。

所以開源實際是最高形式的競爭，整個技術社群的認可才能保證自己永不落後。

 

萬億交易量成就的TubeMQ

 

TubeMQ的誕生

TubeMQ(Github地址：https://github.com/Tencent/TubeMQ)是2013年騰訊開始自研的分散式訊息中介軟體系統，專注服務大資料場景下海量資料的高效能儲存和傳輸。經過近7年日均25萬億的天量資料的打磨，較之於其它競品TubeMQ絕對堪稱是千錘百煉，在海量實踐應用場景下絕對無人能出其右。 

TubeMQ的適用場景

與一般的MQ類似，TubeMQ也比較適合及流式資料的處理場景，如使用者的使用日誌，實時廣告的推薦等場景。 

TubeMQ與其它MQ的比較：可以說TubeMQ最核心的優勢就是歷經考驗了，我們可以看到其它的TubeMQ的競品，幾乎都有不同策略的資料副本同步機制，而只要存在這種策略，並一定要有一致性的保證機制，從而造成一定的效能消耗，TubeMQ則放棄了資料同步的策略，以儘可能的提升效率，並且加入了訊息的服務端過濾功能。

比較項	TubeMQ	Hippo	Kafka	Pulsar
資料時延	10毫秒	20毫秒級	250毫秒	10毫秒
請求TPS	單機14W+/s	不適用	單機10W+/s	10W+/s (大壓力下不穩定)
過濾消費	支援服務端過濾	客戶端過濾，不支援服務端過濾	客戶端過濾，不支援服務端過濾	客戶端過濾，不支援服務端過濾
資料副本同步策略	無，通過RAID10磁碟備份+低時延消費解決	類Paxos演算法保障	多機非同步備份	多機非同步備份
資料可靠性	無資料同步策略，故單機故障未消費的資料存在丟失風險	高	一般，master未同步的資料存在丟失風險	一般，master未同步的資料存在丟失風險
系統穩定性	高，日均25萬億交易量， 穩定執行5年	無TubeMQ類似的運營場景	無TubeMQ類似的運營場景	無TubeMQ類似的運營場景
易用性	一般，只提供Java和C++的Lib	一般，只提供Java和C++的Lib	高，有很多配套外掛使用	高，有很多配套外掛使用

TubeMQ的技術架構

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

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

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

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

Zookeerper：僅做offset的持久化儲存，考慮到接下來的多節點副本功能該模組暫時保留。

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

與kafka的技術方案相比 

在TubeMQ的最大不同在於以下幾個方面

1、TubeMQ使用Java語言開發,kafka則使用相對小眾的scala語言，再二次開發的難度TubeMQ佔據優勢

2、 使用內嵌資料庫儲存後設資料：與Kafka的Zookeeper模組管理後設資料的策略不同，TubeMQ系統的主節點通過採用內嵌資料庫BDB完成叢集內後設資料的儲存、更新以及HA熱切功能，負責TubeMQ叢集的執行管控和配置管理操作，對外提供介面，從而減輕維護複雜度

3、 服務端的訊息過濾：TubeMQ支援服務端的訊息過濾及負載均衡的方案，更便於均衡演算法升級；

4、 引入行級鎖防重複：TubeMQ的Broker在中間狀態的併發操作採用行級鎖的策略，避免重複問題。

 

後記

 

IT業與傳統行業最大的不同，就是其背後還隱藏著俠義與江湖的影子，技術社群就是江湖上的武林大會，而開源則是武林高手下場比武，而在這種不斷交流切磋的過程中，必將提高各門派的武功水準。

所以在此筆者也由衷希望騰訊今後能夠開源更多更優質的專案以饗整個國內IT業，推動行業良性發展。

【End】

熱門:Python 學習 100 天

https://edu.csdn.net/topic/python115?utm_source=csdn_bw

艾瑞巴蒂，上雲了嗎！過程順利嗎！需要奔走相告嗎！CSDN雲端計算現強勢開啟“雲+X”案例徵集活動，從先進性、擴充性、效益性等三個基本方向出發，深入展現雲技術作用行業的突出優勢。挖掘優秀案例、啟迪各行各業，推動整個“雲+行業”的健康發展～權益震撼，活動免費，快掃描⬇二維碼報名吧～

熱 文 推 薦 

☞微信成最頻繁網路詐騙犯罪工具；庫克再談賈伯斯；PyCharm 2019.2.5 釋出| 極客頭條

☞不為人知的 35 個 More Effective C++ 改善程式設計與設計的最佳方法 | 原力計劃

☞程式設計師的修神之路是？

☞金山辦公上市，雷軍心願了卻！

☞“12306”的架構到底有多6？

☞如何向純潔的女朋友解釋併發與並行的區別？

☞全面分析阿里資料中臺，小白也能看懂 | CSDN原力計劃

☞百度工程師詳解合約閘道器，如何用Quorum中間層快速開發投票智慧合約？

點選閱讀原文，立即報名參會！

你點的每個“在看”，我都認真當成了喜歡