導語 | 近日，雲+社群技術沙龍“騰訊開源技術”圓滿落幕。本次沙龍邀請了多位騰訊技術專家圍繞騰訊開源與各位開發者進行探讨，深度揭秘了騰訊開源項目TencentOS tiny、TubeMQ、Kona JDK、TARS以及MedicalNet。本文是對張國成老師演講的整理。

本文要點：

一、Message Queue 簡介

對于Message Queue(以下簡稱MQ)，Wiki百科上的定義指：不同程序之間或者相同程序不同線程之間的一種通訊方式，它是一種通訊方式。

那我們為什麼要采用MQ呢？這是由MQ的特點來決定的。第一是因為它可以整合多個不同系統共同協作；第二是它可以解耦，進行資料傳遞和處理；第三是它可以做峰值的緩沖處理，我們平常接觸到的像Kafka、RocketMQ、Pulsar等基本上也都有這樣的特點。

那作為大資料場景下的MQ又有什麼特點呢？從我個人的了解來說，就是高吞吐低延時，系統盡可能地穩定，成本盡可能地低，協定也不需要特别地複雜，特别是水準擴充能力要盡可能的高。

因為像海量資料基本上都是到百億、千億、萬億，比方說我們自己的生産環境可能一個月、一年的時間就會翻一番，如果沒有橫向的擴充能力，系統就很容易出現各種問題。

二、TubeMQ實作原理及使用介紹

那麼，騰訊自研的TubeMQ又有什麼樣的特點呢？TubeMQ屬于萬億級分布式消息中間件，專注于海量資料下的資料傳輸和存儲，在性能、可靠性，和成本方面具有獨特的優勢。

針對大資料場景的應用，我們給出了一個測試方案（詳細方案在騰訊TubeMQ開源docs目錄裡可以查詢得到）。首先我們要做一個實際應用場景定義，在這個定義之下，再進行系統資料的收集整理。結果是：我們的吞吐量達到了14萬的TPS，消息時延可以做到5ms以内。

可能有些人會感到好奇，因為有很多研究報告都分析過，同樣的分布式釋出訂閱消息系統，例如Kafka這種，都能達到上百萬的TPS。相比來說，我們的資料會不會顯得太差？

其實這裡是有一個前提的，那就是：我們是在1000個Topic中，并為每個Topic配置10個Partition的場景下達到的性能名額。對于Kafka，它或許可以達到百萬級的TPS，或許時延可以降到很低，但在我們的大資料的場景下，就遠遠到不了這個量級。

我們的系統線上上已經穩定運作了7年的時間，系統的架構采用的是瘦用戶端、偏伺服器管控模型。這樣的技術特點就決定了它相應的應用場景。比如實時的廣告推薦、海量的資料上報、名額&監控、流處理、以及IOT場景下的資料上報等。

部分資料有損是可以允許的，因為大不了重複再報一下也可以解決，但是考慮到資料的量級實在太大，是以隻能犧牲部分的可靠性來換取高性能的資料接入。

TubeMQ系統架構是怎樣的？如下圖所示，它通過一個SDK與外部互動，當然直接通過我們定義的TCP協定實作對接也是可以的。

值得注意的是：TubeMQ是純Java編寫的，它擁有Master HA的協調節點，采用弱zk來管理Offset。在消息存儲模式上也同樣進行了改進，調整了資料可靠性的方案，采用的是磁盤RAID10多副本+快速消費，而非多Broker節點多副本的方案，而且啟用了中繼資料自管理模式等。

如下圖所示，自有資料記錄以來，我們一共經曆了四個階段，從引入到改進再到開始自研，再到現在的自我創新。從2013年6月最開始的200億，到2019年11月的35萬億，預計2020年能達到40萬億。

總的來說，這也是我們當初要選擇自研的重要的原因。因為當資料量還不大的時候，比如在10億或者是10億量級以下，用什麼樣MQ其實都是可以的。但是一旦達到百億、百億到千億、千億到萬億甚至是萬億以上資料量的時候，越來越多的制約因素就會相繼出現，包括系統的穩定性、性能以及機器成本和運維成本等問題。

我們現網TubeMQ擁有1500台的機器，而1500台機器就隻需要用到一個左右的人力來運維就可以了（非全職的兩個人）。對于我們的Broker存儲伺服器，能夠做到上線持續運作4個月不重新開機，這些都是我們在原基礎之上所做的改進和創新帶來的。

下圖的這個表格是TubeMQ與其他MQ橫向比較的資料情況，我們項目是開源的，大家如果感興趣的話可以直接去驗證一下。總的來說，TubeMQ比較适合需要高性能、低成本又容許極端情況下有資料損失的場景，是經得起實踐考驗的。