日均350000億接入量，騰訊TubeMQ效能超過Kafka

AI科技大本營發表於2020-01-16
MQKafka
640?wx_fmt=png

整理 | 夕顏
出品 | AI科技大本營（ID:rgznai100）
 
【導讀】近日，騰訊開源動作不斷，相繼開源了分散式訊息中介軟體TubeMQ，基於最主流的 OpenJDK8開發的Tencent Kona JDK，分散式HTAP資料庫 TBase，企業級容器平臺TKEStack，以及高效能圖計算框架Plato。短短一週之內，騰訊開源了五大重點專案。其中，TubeMQ是騰訊大資料平臺部門應用的核心元件，據悉，在目前日均接入35萬億條資料背景下，部門每年都會針對它制定KPI指標，來保證系統能穩定執行，並且持續改進以提高效能，降低成本。
 
TubeMQ究竟有什麼不一般的地方，今天我們就來詳細瞭解一下。


TubeMQ是什麼？

TubeMQ技術部落格已經對TubeMQ進行了詳細的技術解讀，這裡我們再來回顧一下。
 
TubeMQ是騰訊大資料在2013年開始研發的分散式訊息中介軟體系統（MQ），專注服務大資料場景下海量資料的高效能儲存和傳輸。經過近7年上萬億的海量資料沉澱，較之於眾多的開源MQ元件，TubeMQ在海量實踐（穩定性+效能）和低成本方面有一定的優勢。
 
目前，TubeMQ已經在騰訊內部多個重要業務部門成功落地，如微信支付、社交廣告、騰訊遊戲、騰訊視訊、微視等。
 
640?wx_fmt=png
 
注：近期，騰訊開源了TubeMQ的相關程式碼及設計。專案推出後得到了廣泛關注和對比討論，在GitHub上已經獲得了1.5k個Star。
 GitHub：
https://github.com/Tencent/TubeMQ
 

TubeMQ VS Kafka效能對比測試總結

作為一款國產框架，自然而然會有人與 Kafka 做比較。在GitHub上，騰訊也相應對兩者進行了效能對比。
 
GitHub地址：
https://github.com/Tencent/TubeMQ/blob/master/docs/tubemq_perf_test_vs_Kafka_cn.md#top
 
介紹中提到，TubeMQ系統架構的思想就是源於Apache Kafka，而在實現上，則完全採取自適應的方式，結合實戰做了很多優化及研發工作，如分割槽管理、分配機制和全新節點通訊流程，自主開發高效能的底層RPC通訊模組等。這些實現使得TubeMQ在保證實時性和一致性的前提下，具有很好的健壯性及更高的吞吐能力。結合目前主流訊息中介軟體使用情況，以Kafka為參照做效能對比測試，對比常規應用場景下兩套系統效能。
 
從TubeMQ架構圖可以很清晰的看到，作為分散式的訊息中介軟體系統，Broker單節點的效能情況直接影響到叢集總體的效能表現，即相同的節點數下Broker節點效能越高則TubeMQ的總體效能越強。
 
下表是TubeMQ與Kafka效能資料對比方案，在資料1份寫入2份並行消費的場景下，從機型、關鍵配置、系統資料的對比中可以很清晰地看到TubeMQ的效能情況：
 
640?wx_fmt=png 
總的來說：Kafka按照順序寫順序塊讀的模式實現，單例項下效能資料很強，但隨著例項數增多，它的效能就呈現不穩定下降狀態；TubeMQ採用順序寫 + 隨機讀的模式，即使在最大限制下系統仍可以做到長期穩定的1G以上的入流量，同時，結合服務端過濾，過濾消費非常順暢。
 
具體的資料分析來看：

1、單Topic單例項配置下，TubeMQ吞吐量要遠低於Kafka；單Topic多例項配置下，TubeMQ在4個例項時吞吐量追上Kafka對應5個分割槽配置，同時TubeMQ的吞吐量隨例項數增加而增加，Kafka出現不升反降的情況；TubeMQ可以在系統執行中通過調整各項引數來動態的控制吞吐量的提升；

2、多Topic多例項配置下，TubeMQ吞吐量維持在一個非常穩定的範圍，且資源消耗，包括檔案控制程式碼、網路連線控制程式碼數等非常的低；Kafka吞吐量隨Topic數增多呈現明顯的下降趨勢，且資源消耗急劇增大；在SATA盤儲存條件下，隨著機型的配置提升，TubeMQ吞吐量可以直接壓到磁碟瓶頸，而Kafka呈現不穩定狀態；在CG1機型SSD盤情況下，Kafka的吞吐量要好於TubeMQ；

3、在過濾消費時，TubeMQ可以極大地降低服務端的網路出流量，同時還會因過濾消費消耗的資源少於全量消費，反過來促進TubeMQ吞吐量提升；kafka無服務端過濾，出流量與全量消費一致，流量無明顯的節約；

4、資源消耗方面各有差異：TubeMQ由於採用順序寫隨機讀，CPU消耗很大，Kafka採用順序寫塊讀，CPU消耗很小，但其他資源，如檔案控制程式碼、網路連線等消耗非常的大。在實際的SAAS模式下的運營環境裡，Kafka會因為zookeeper依賴出現系統瓶頸，會因生產、消費、Broker眾多，受限制的地方會更多，比如檔案控制程式碼、網路連線數等，資源消耗會更大。

具體的場景測試及結論可參考GitHub：
https://github.com/Tencent/TubeMQ/blob/master/docs/tubemq_perf_test_vs_Kafka_cn.md#top 

TubeMQ相比Kafka的系統特點:

1、純Java實現語言：
TubeMQ採用純Java語言開發，便於開發人員快速熟悉專案及問題處理。

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

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

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

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

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

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

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

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

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

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

與當前主流MQ橫向對比分析

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

比較項
TubeMQ
Kafka
Pulsar
資料時延
非常低，10毫秒級
比較低，250毫秒級
非常低，10毫秒級
請求TPS
高，單機14W+/s
一般，單機10W+/s
一般，單機10W+/s (大壓力下不穩定)
過濾消費
支援服務端過濾
客戶端過濾，不支援服務端過濾
客戶端過濾，不支援服務端過濾
資料副本同步策略
無，通過RAID10磁碟備份+低時延消費解決
多機非同步備份
多機非同步備份(高效能場景)
資料可靠性
一般，單機故障未消費的資料存在丟失風險
一般，主機故障未同步的資料存在丟失風險
一般，主機故障未同步的資料存在丟失風險
單機磁碟IO 100%時對外服務能力
高，特定機型下可以通過SSD轉儲存消費功能,維持約700M寫入及超過1G的消費流量
低，滯後會讀寫受阻，甚至會停寫
低，滯後會讀寫受阻，甚至會停寫
系統穩定性
高，已線上運營7年，每天25萬億的資料量，已做到單叢集400臺Broker的線上運營規模
一般，效能隨Topic數增多出現不穩定情況，沒有超大資料運營規模場景
一般，高壓下存在效能下降、服務受阻等情況
跨叢集管控能力
有，實施中
無
無
配置可管理性
高，熱備儲存，中心化管理，API或頁面操作
一般，基於zk配置管理，API或頁面操作
一般，基於zk配置管理，API或頁面操作
易用性
一般，只提供Java和C++的Lib，資料上報支援tcp、udp、http
高，有很多配套外掛使用
高，有很多配套外掛使用


TubeMQ叢集架構

經過多年演變，TubeMQ叢集分為如下5個部分：
 
      640?wx_fmt=png

  • 負責對外互動和運維操作的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客戶端；
  • 負責offset儲存的zk部分，該部分功能已弱化到僅做offset的持久化儲存，考慮到接下來的多節點副本功能該模組暫時保留。


Broker檔案儲存方案

以磁碟為資料持久化媒介的系統都面臨各種因磁碟問題導致的系統效能問題，TubeMQ系統也不例外，效能提升很大程度上是在解決訊息資料如何讀寫及儲存的問題，在這個方面TubeMQ進行了比較多的改進：
 
TubeMQ的磁碟儲存方案類似Kafka，但又不盡相同，如下圖示，儲存例項由一個索引檔案和一個資料檔案組成，每個Topic可以分配1個或者多個儲存例項，每個Topic單獨維護管理儲存例項的相關機制，包括老化週期，partition個數，是否可讀可寫等：
 
640?wx_fmt=png
 
在檔案儲存基礎上，我們針對每個儲存例項又額外增加了一個單獨的記憶體快取塊，即在原有寫磁碟基礎上增加一塊記憶體，隔離硬碟的慢速影響，資料先刷到記憶體，然後由記憶體控制塊批量地將資料刷到磁碟檔案：
 
640?wx_fmt=png
 
針對除了由磁碟儲存外還帶SSD硬體的伺服器，我們又做了一層SSD儲存，在磁碟IO飆升時候將滯後消費讀進行轉移，避免讀寫集中在SATA盤上，不過該方案有別於外界系統先將資料存SSD，然後再將資料由SSD轉到磁碟的通常做法：
 
按照我們的分析，正常情況下磁碟的順序讀寫效能已足夠滿足資料持久化的需求，磁碟IO到100%時的效能下降主要是由於滯後消費引起，滯後的比例越大影響越大；SSD相比磁碟，雖然讀寫速度近似記憶體但寫入次數有限，像MQ這種每天大量寫的系統很有可能因為SSD突然變得不可寫帶來系統風險。
 
基於這些考慮，我們採用了動態的SSD轉儲存消費方案：正常情況下資料走磁碟讀寫消費；資料擠壓情況出現，並且持續的狀態觸發運維設定的閥值時，滯後的資料消費將被轉移到SSD上進行；資料擠壓情況解除後，SSD停用資料繼續走磁碟進行讀寫：
 
640?wx_fmt=png
 
目前我們仍在探索新的儲存方案，後續版本中我們會將實踐後的內容分享到大家。 

TubeMQ客戶端的演進

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

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

  • 資料消費行為支援順序和過濾消費:


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

  • 支援業務extractly-once消費：

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

TubeMQ捐贈Apache軟體基金會

值得注意的是，騰訊已將TubeMQ捐獻給全球最大的開源基金會Apache軟體基金會，走上了社群開放治理之路。
 
640?wx_fmt=png
（騰訊開源路線圖）

近年來，騰訊在開源上的步伐不斷加快。截至11月，騰訊自主開源專案已達89個，Star數超過26萬，重點關注領域包括 IaaS、容器與雲原生、資料庫、大資料與 AI、中介軟體、IoT/邊緣計算、小程式生態等。在不斷貢獻優質專案之餘，騰訊也積極貢獻開源社群，除了加入Apache基金會、Linux基金會、LFAI 基金會、OpenStack基金會、MariaDB基金會多個頂尖開源基金會的白金會員外，騰訊眾多業務團隊和技術人員也積極參與到開源貢獻中，已廣泛參與數十個社群和專案的建設。

（*本文為AI科技大本營整理文章，轉載請微信聯絡1092722531）


◆

精彩推薦

◆



開幕倒數計時16天｜2019 中國大資料技術大會（BDTC）即將震撼來襲！豪華主席陣容及百位技術專家齊聚，15 場精選專題技術和行業論壇，超強幹貨+技術剖析+行業實踐立體解讀。6.6 折票限時特惠（立減1400元），學生票僅 599 元！

640?wx_fmt=jpeg

推薦閱讀

相關文章