RocketMQ聯合創始人：選擇MQ時，要注意的有哪些？

接收程序員的技術早餐

作者｜馮嘉

編輯｜郭蕾

RocketMQ 是一個來自阿里巴巴的分散式消息中間件，於 2012 年開源，並在 2017 年正式成為 Apache 頂級項目。據了解，包括阿里雲上的消息產品以及收購的子公司在內，阿里集團的消息產品全線都運行在 RocketMQ 之上，並且最近幾年的雙十一大促中，RocketMQ 都有搶眼表現。

談起消息系統中間件，就開源項目而言，用戶的選擇其實很多，包括 ActiveMQ、ZeroMQ、Kafka 等。那到底 RocketMQ 又有什麼優勢？未來它的演進方向會是怎麼樣？去年由 RocketMQ 牽頭推出的全球消息領域標準 OpenMessaging 進展又如何？帶著這些問題，InfoQ 記著採訪了 RocketMQ 聯合創始人馮嘉。

InfoQ：之前 InfoQ 記者其實也有採訪過 RocketMQ 好幾次 [0]，我們也有聊到阿里巴巴消息系統的演進歷史。不過我覺得之前那篇沒有講得特別清楚，不知道還可不可以再談談你們消息系統的演進情況？

馮嘉：在阿里巴巴技術發展初期，伴隨著淘寶業務的快速發展，網站流量呈現幾何級增長。單體巨無霸式的應用無法跟上快速迭代的研發要求，上百工程師每天對著同一套系統，代碼不斷的遷入遷出，發布、交付成本也非常之高。

這個時候，公司內部從業務、組織層面進行了一次大的水平與垂直切分，拆分出用戶中心，商品中心，交易中心，評價中心等平台型應用，分散式電商系統的雛形由此誕生。

阿里第一代消息引擎 Notify 就是在這樣的背景下設計出來的，主要解決的核心問題是交易下單鏈路的非同步解耦。當然，這背後，需要我們嚴肅考慮分散式系統的可擴展性，比方說它的服務發現節點，存儲節點，Broker 節點都是支持水平擴展，面對淘寶高峰流量，比較好地起到了削峰填谷的作用。

放眼全球，當時業界的消息引擎，如 Apache ActiveMQ 以及其它 AMQP 實現，在後端有超大規模消費者，尤其是各消費能力不均衡的前提下，經常會出現堆積，這種影響被傳遞到上游生產者，進而影響交易核心業務，系統卡頓，宕機現象不在少數。如何能夠更好的削峰填谷，這也是 Notify 最早面臨的難題之一。

再後來，隨著 2011 年 Kafka 從 Apache 頂級項目畢業，其自研存儲引擎帶來的海量消息堆積，高效的持久化特性走入我們的視野。但它特殊的日誌通道定位，是不能完全滿足阿里巴巴高頻的在線交易場景，為此團隊設計並研發了新一代消息引擎 RocketMQ（內部叫 MetaQ），從最初的日誌傳輸領域到後來阿里集團全維度在線業務的支撐，RocketMQ 被廣泛用在交易，數據同步，緩存同步，IM 通訊，流計算，IoT 等場景。

關於這些 Use Case，我們在 OpenMessaging 項目里有個簡單總結，大家可以參考這裡 [1]。

InfoQ：談談 2017 年雙十一中，RocketMQ 的一些數據情況？現在阿里就只有用 RocketMQ 嗎？目前開源出去了，內部和外部的版本是一一對應的嗎？未來怎麼打算呢？

馮嘉：目前，包括阿里雲上的消息產品以及收購的子公司在內，阿里集團的消息產品全線跑在 RocketMQ 4 的內核上面。今年會全面擁抱 OpenMessaging 的第一個標準實現 RocketMQ 5.0，這其中也包括我們為千萬中小企業定製的商業化版本的 RocketMQ - Aliware MQ（ONS）。所有消息產品都圍繞著 RocketMQ 唯一內核打造，一個版本，豐富的可插撥組件，這個思路是團隊一直堅持的，而且會持續走下去。

說起數據表現，RocketMQ 在 2017 年雙十一當天的萬億級數據洪峰下，做到了 99.996% 的毫秒級響應，每秒支撐千萬級消息發布，每條消息發布平均響應時間不超過 3 毫秒，最大不超過 20 毫秒，而核心交易鏈路平均 Response Time 僅 3ms，在全球 Messaging 領域做到了領先水平。

隨著我們在 OpenMessaging 標準里的 benchmark[2] 項目陸續發布，開源消息領域的主流產品都會被拿來評測，我們希望它能成為這個領域的基準平台，既有對 OpenMessaging Features 支持程度的評價，又有在不同 Workload 下的性能評估，還能像據庫領域的 DB-Engines 一樣，對全球消息產品有個 Ranking。

InfoQ：從你的經驗，來談談在消息中間件選型時，大家應該注意些什麼？需要從哪幾個維度考慮？

馮嘉：全球主流的開源分散式消息引擎，除了 RabbitMQ，基本上都在 Apache 上了。Apache ActiveMQ 以及旗下的各個子項目，主要面向企業級市場，吞吐不是其強項，主要和企業已有基礎設施集成起來比較方便，如 EAI，ESB 這種早期企業基礎架構。

Apache Kafka 為日誌處理而生，目前從社區來看，發力重點在流計算，IoT 等領域，和 Apache Spark Streaming，Apache Flink，Apache Storm 等一站式流計算平台不同，它從 Apache Samza 這種輕量級方案汲取了養分，提供給用戶的是一個非同步編程框架，用戶基於類庫編程，不需要考慮分發，部署，調度等一系列傳統流計算框架帶來的繁瑣工作。這種輕量級的解決方案在一些日誌處理，ETL 等場景更受大家歡迎。

如果是應對一些高並發，高可靠以及高可用比較苛刻的場景，Apache RocketMQ 是一個不錯的選擇。最近留意到一個有趣的現象，國內一些中大型規模的公司普遍部署了兩套消息引擎，一套選擇 Apache RocketMQ 用在交易，數據分發等核心鏈路上，一套選擇 Apache Kafka 用在大數據等在線、離線分析鏈路上。毫無疑問，Kafka 目前在大數據生態建設這塊，確實具備一定的先發優勢。

RocketMQ 作為承載了阿里巴巴雙十一萬億級數據體量的消息引擎，在電商，金融領域的優勢也是比較明顯的。目前，國內很多金融領域的領軍企業在構建自己的分散式金融體系時，也都不約而同地選擇了 RocketMQ。

另外，自從 RocketMQ 進入 Apache 基金會後，團隊大力發展社區生態，包括和 Apache Spark，Apache Flink，Apache Storm，Apache Ignite 等頂級開源產品有了更多的生態連接與整合能力。未來一兩年，我們也希望 RocketMQ 能在大數據，流計算領域取得更多的創新突破。

InfoQ：我看到社區里做的幾個性能對比，發現其實 RocketMQ 都不是性能最高的，那你認為和其他幾個選項對比（Kafka、RabbitMQ、ZeroMQ），RocketMQ 最大的優點是什麼？

馮嘉：哈哈，大家看到的數據可能比較老了。開個玩笑，其實不光在阿里，在 Google 一樣，軟體產品都以滿足核心場景為最高優先順序。就像這裡提到的，社區里對比各種消息引擎，我大致看下來，大家主要關心的還是吞吐（延遲這個指標，大家關心的較少，對於在線業務，Latency 影響還是蠻大的）這個指標。

ZeroMQ 不是一個 MQ，所以這裡不提了。Kafka 為大數據吞吐為王的日誌處理而生，早先在 Batch 模式下，具有碾壓其它同類產品的品質。這兩年，在滿足了阿里集團核心消息訴求後，我們先後兩次對 RocketMQ 進行了革命式優化，前年主要做了雙十一交易鏈路的長尾慢請求優化，在延遲方面已經超越 Kafka。具體的數據可以參考這篇文章 [3]。

吞吐方面，在小包非批量以及大量分區的場景下（現實應用更廣泛的場景），RocketMQ 更能充分利用磁碟的 IO 能力達到更高的 TPS（領先 Kafka 一倍左右）。在大包和批量的場景下，RocketMQ 和 Kafka 目前已經相差無幾，此時的瓶頸已經轉移到磁碟的吞吐能力上。

為了能夠更客觀地反映全球消息領域的各家產品的性能，幫助大家更好的選型，在 OpenMessaging 的 Benchmark 子項目里，我們專門設計了全維度的 Workload 基準測試，所有產品拉到同一個基準平台，同一套負載下，性能孰優孰劣，高下立判。今年晚些時候，我們也會在國際 InfoQ 上公布我們的數據以及優化經驗，歡迎大家來親測。

InfoQ：你怎麼看 Kafka？

馮嘉：Apache Kafka 是一款優秀的開源產品，這一點毋庸置疑，對於同行卓越的努力我們需要心懷敬畏。Kafka 利用端到端的 Batch、壓縮等優秀設計，在同類產品吞吐特性上表現卓越，這種設計也極大地提高了資源利用率。在此基礎上，Kafka 充分發展技術生態，佔據了在大數據與流處理領域的先發優勢。

相比而言，RocketMQ 在低延遲，消息重試與追蹤，海量 Topic，多租戶，一致性多副本，數據可靠性等問題上進行了大量優化，對電商，金融領域的用戶來說，是一大利好。

InfoQ：OpenMessaging 是由阿里巴巴發起的與廠商無關、平台無關的分散式消息及流處理領域的應用開發標準，目前我理解是想統一目前這些消息中間件的客戶端標準，以簡化用戶的學習成本。現在 OpenMessaging 也已經正式入駐 Linux 基金會，目前進展如何？我理解他的成本需要其他一些消息框架也加入進來？不知道在這塊其他幾家怎麼看？

馮嘉：OpenMessaging 自去年 10 月進入 Linux 基金會以來，受到了全球同行的廣泛關注。很多分散式領域的專家在 Issue 上，郵件列表裡和我們進行了激烈探討，整個模型也是在不斷的打磨，優化。

目前除了初創的成員，我們還在考慮吸納來自全球其它互聯網，金融領域的大咖企業，啟動一個類似 Linux 基金會的 Funding Program，歡迎國內有自主消息引擎的廠商加入我們，也非常歡迎積極擁抱標準化戰略的同行企業加入進來，共同打造消息領域的事實標準。整個標準的第一個正式版本（非 Alpha 版本），初步計劃在今年 4 月份發布，而阿里雲 MQ 會成為 OpenMessaging 全球第一個雲廠商標準實現，並於今年晚些時候發布。

OpenMessaging 在我們初步蹦出這個想法的時候，就跟 Apache 社區包括 RabbitMQ 團隊的同行們聊過，大家反響普遍還是很熱烈的。畢竟這塊業界還是個空缺，在 Java 生態里，JMS 2.1 在 Java EE 體系里被推遲了又推遲，Spring 社區也忍不住自己設計了一套類似的編程框架。但放眼多語言領域這塊就顯得貧瘠了。

業界迫切需要一套類似資料庫領域的 SQL 這樣的編程標準，而在整個標準的演進過程中，像 Apache ActiveMQ， Apache Pulsar，包括 Apache RocketMQ 社區都給出了很多積極的回應。在第一個標準版本實現中，大家也會看到其它幾家頂級開源消息引擎的 OpenMessaging 實現。

除此之外，在 Spring Cloud，AMQP，MQTT，Serverless 等領域，OpenMessaging 也會尋求積極探索與合作。準確一點講，OpenMessaging 已經不是一個傳統意義上的 API 標準，它更像是一個生態，一個圍繞著 Messaging 運轉的全域開源生態。

InfoQ：RocketMQ 5.0 有什麼重磅的特性會發布？你在 QCon 上著重和大家分享哪些觀點？

馮嘉：對了，和大家再預告下，阿里巴巴第 4 屆中間件性能挑戰大賽 4 月份就要和大家見面了。今年圍繞著 RocketMQ 5.0，我們設計了一道跟 RocketMQ 存儲引擎相關的題目，歡迎大家報名參賽。說到 RocketMQ 5.0，整體定位依舊是高吞吐，低延遲，任意堆積並且是 Cloud Native。關於這些特性，我會在接下來的北京 QCon 上和大家分享，非常期待和大家的現場交流，也希望大家繼續關注 RocketMQ，關注 OpenMessaging。

參考鏈接如下：

[0] http://www.infoq.com/cn/news/2017/02/RocketMQ-future-idea

[0] https://www.infoq.com/articles/alibaba-apache-rocketmq

[1]https://github.com/openmessaging/specification/blob/master/usecase.md

[2]http://openmessaging.cloud/docs/benchmarks/

[3]https://medium.com/@Alibaba_Cloud/rocketmq-into-the-500-000-tps-message-club-357cdde3ed2e

作者介紹

馮嘉，Apache RocketMQ 聯合創始人，Linux OpenMessaging 標準創始人。阿里巴巴高級技術專家，帶領團隊、社區打造了中國雲計算領域第一個 Apache 頂級開源中間件項目，創建分散式消息領域的國際標準 OpenMessaging。

馮嘉具有豐富的分散式軟體架構、高並髮網站設計、性能調優經驗，擁有國內外多項分散式、推薦領域的專利授權，在國內外期刊雜誌，技術峰會發表數篇文章與技術分享。目前專註於大規模分散式系統、分散式消息引擎、流計算領域。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！