您好,登錄后才能下訂單哦!
本篇文章給大家分享的是有關哪些場景下適合用Apache TubeMQ,小編覺得挺實用的,因此分享給大家學習,希望大家閱讀完這篇文章后可以有所收獲,話不多說,跟著小編一起來看看吧。
Apache TubeMQ是騰訊于2019年對外開源后捐獻給Apache的新一代MQ,其源于騰訊公司的實際生產環境,專注服務海量數據的高性能存儲和傳輸,在MQ已是紅海的今天(僅Apache就已經有5個MQ),較之于眾多的開源MQ組件,Apache TubeMQ到底有些什么特點,我們在什么場景下適用,應用這個產品能給我們帶來什么好處?下面想從這點進行介紹。
總結起來,主要是如下場景:
數據上報量太大,普通MQ支撐不住;
普通MQ能抗住,但消耗的機器資源太多,或者系統不穩定難維護
技術棧純JAVA,便于自行改造及版本維護,即使版本有問題也可以快速協調資源立即止損;
功能上只要生產消費,不需要事務消息、Exactly Once等高級功能;
系統自動化程度高,容忍極端情況下少量數據丟失。
個人覺得主要有3點:
線上8年過40萬億的數據量級服務沉淀,Apache TubeMQ源于騰訊公司的實際生產環境,最初我們也如大多數業務樣采用Apache Kafka進行數據服務,但由于Kafka服務端采用Scala實現,閱讀、維護較為困難,出問題沒辦法立即解決,同時Kafka設計存在一些不太合理的地方,使用起來比較的復雜;在現網壓力下,我們基于Kafka的思想以及實際需要,萌發了做一款基于服務端管控的以SAAS模式對外服務的高可靠、高性能、低延遲、低成本的分布式消息中間件思路,并圍繞這個項目定位進行了產品構建及持續改進。
到目前為止,Apache TubeMQ專注服務大數據場景已近8年的時間,目前已達到了日均40萬億+的吞吐量級,形成了較穩定、易于維護的久經考驗產品,服務的業務包括了廣點通、PCG、微信等,我們最大的集群規模超過300臺Broker,每個Broker配置的topic達到800個,消費組有近3K的規模。
基于騰訊內部各種業務的需求打磨出來的這款MQ,我們很確定一定也適合大家在類似業務場景上的使用。
單機10W以上的TPS,10ms以下的端到端時延,這是一份Apache TubeMQ在開源初期做的一份性能壓測對比總結報告tubemq_perf_test_vs_Kafka,總的來說,在TS60機型(萬兆網卡,64G內存,24核CPU,12TSATA硬盤)下,配置1000個topic,每個topic配置10個分區,每條消息1K大小,在一份生產二份消費的前提下,單機Broker可以做到10W以上的TPS(TransactionsPerSecond的縮寫,每秒成功的請求響應數),端到端時延10ms以下。這僅是我們給出的保守指標,我建議大家自己在相同場景下對比測試,大家可以拿任意外部MQ進行對比測試,會有不一樣的發現。
很多MQ都有稱系統能達到上千萬的TPS,甚至1ms的端到端時延,我們給出的這個指標大家是否覺得太低了?我想表達的是,指標的提供是要有配套的測試前提的,在給出的明確系統配置、生產消費負載下,如果要達到千萬級別的TPS,單機10W以上TPS的前提下,集群只需要不到100臺的Broker橫向擴展即可達到;如果沒有如上系統配置、生產消費負載,達到千萬級別的TPS,機器量級會更低。
Apache TubeMQ能夠達到我們所述的特點,主要源于其根據業務場景構建的TubeMQ 架構,我們內部不僅自己用這套系統支撐服務,同時我們還將其開源出來,按照Apache規則進行項目孵化,讓更多的外部公司的業務來使用它,通過它來降成本,提升系統性能和穩定性。系統足夠的穩定,有過MQ經驗的同學按照官網上的指引進行搭建即可運行起來;系統完全開源且采用純JAVA構建,即使原創團隊不再維護,市場上也有足夠的技術人才支撐其改進;按照Apache社區規范來運作社區,只要你有任何的改進建議,驗證有效都能合入系統,且原創團隊都是國內人員,交流溝通更方便。
一站式的流數據服務平臺,我們想將整個的數據上報平臺在這個項目里開源出來,將數據上報涉及的采集,匯聚,存儲,轉發等模塊以插件化的形式有機的整合起來(即使是TubeMQ,也可以在這個平臺里進行更替),基于此系統,業務只需要進行數據的發布和訂閱,即可輕松構建基于流數據的分析和應用。 我們正在構建各個部分的模塊,歡迎大家一起來共建。
以上就是哪些場景下適合用Apache TubeMQ,小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注億速云行業資訊頻道。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。