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

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

另外，在 4 月 20 日舉辦的 QCon 全球軟體開發大會上，馮嘉也將會獨家揭祕 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。