騰訊“瘋狂”開源

騰訊“瘋狂”開源

作者 | 馬超

出品 | 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則放棄了數據同步的策略,以儘可能的提升效率,並且加入了消息的服務端過濾功能。

<table><tbody>

比較項

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

高,有很多配套插件使用

高,有很多配套插件使用

/<tbody>/<table>

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】

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

腾讯“疯狂”开源


分享到:


相關文章: