開源 VS 商業，消息中間件你不知道的那些事

11月23日，新炬網絡中間件技術專家劉拓老師在DBA+社群中間件用戶組進行了一次主題為“開源 VS 商業，消息中間件你不知道的那些事”的線上分享。小編特別整理出其中精華內容，供大家學習交流。

 

 

嘉賓簡介  

 

• 新炬網絡中間件技術專家

• 曾任職於IBM華南GTS 4年，IBM WebSphere、MQ、CICS產品線技術專家

• 5年移動運營商（廣東移動、浙江移動）運維經驗，3年JAVA開發及售后經驗

 

演講實錄  

 

隨着雲計算的興起，Docker、微服務的流行，分布式消息隊列技術成為雲計算平台中不可或缺的組件。今天由我來給大家分享下目前市場上主流的商業、開源消息中間件之間的區別。

 

什么是消息中間件MOM（Message Oriented Middleware）利用高效可靠的消息傳遞機制進行平台無關的數據交流，並基於數據通信來進行分布式系統的集成。通過提供消息傳遞和消息排隊模型，它可以在分布式環境下擴展進程間的通信。

 

 

• 異步：基於存儲轉發機制的異步通信方式，發送者將消息發送給消息服務器，消息服務器將消息存放在若干隊列中，在合適的時候再將消息轉發給接收者。

 

• 松耦合：客戶和服務對象的生命周期松耦合，由MOM來保障消息隊列及服務，二者的生命周期無需相同，即發送消息的時候接收者不一定運行，接收消息的時候發送者也不一定運行。

 

• 可靠性：由MOM來保障消息不會因網絡連接異常斷開、進程異常重啟等各種原因導致消息丟失。

 

消息傳遞模式分為PTP和Pub/Sub兩種模式。

 

 

PTP（Point–to-Point）

• 每條消息只有一個消費者。

• 發送者和接收者沒有時間依賴（no timing dependencies）。

• 接受者成功接收答復機制。

 

 

Pub/Sub（Publish/Subscribe）

• 每條消息可以有多個訂閱者。

• 發送者和接受者之間必須同步，客戶端只有訂閱后才能收到消息。

 

消息中間件有着異步通知、數據復制、日志同步、延遲隊列、廣播通知五大適用業務場景。

 

• 異步通知：為面向服務架構（SOA）提供分布式事務支持；保證全局數據一致性。比如訂單處理調度通知，訂單拆解后發送開通、計費、賬處等到期提醒，辦理告知短信，訂單狀態，二次確認等。

• 數據復制：利用消息中間件將數據從源頭復制到多個目的地；滿足搜索、離線分析和分表規則變化等需求。如系統間TF數據同步多系統，局數據增量發布等。

• 日志同步：應用通過可靠異步方式將日志同步到消息中間件；可以對日志做實時或離線分析。如統一日志平台中心日志入庫等。

• 延遲隊列：把消息中間件當做可靠的延遲隊列；分布式環境下的定時器。如受理訂單入庫，系統日志入庫等高頻率DB寫入場景。

• 廣播通知：可靠的集群內廣播通知；用於通知緩存失效等事件。如產品緩存刷新等。

 

消息協議JMS VS AMQP

 

 

JMS提供了兩種消息模型，peer-2-peer(點對點)以及publish-subscribe（發布訂閱）模型。在JMS中，消息路由非常簡單，由producer和consumer鏈接到同一個queue（p2p）或者topic（pub/sub）來實現消息的路由。JMSconsumer同時支持message selector（消息選擇器，通過消息選擇器，consumer可以只消費那些通過了selector篩選的消息。

 

 

AMQP是一種協議，更准確的說是一種binary wire-level protocol（鏈接協議）。這是其和JMS的本質差別。AMQP不從API層進行限定，而是直接定義網絡交換的數據格式。這使得實現了AMQP的provider天然性就是跨平台的。

 

在AMQP中，消息路由（messagerouting）和JMS存在一些差別，在AMQP中增加了Exchange和binding的角色。producer將消息發送給Exchange，binding決定Exchange的消息應該發送到那個queue，而consumer直接從queue中消費消息。queue和exchang的bind有consumer來決定。

 

市場上目前主流的消息中間件有IBM MQ、WebLogic JMS、ActiveMQ、Rabbit MQ、Rocket MQ、Apollo等。

 

• IBM  MQ：WebSphere MQ是IBM業務集成基礎性產品，以其獨特的安全機制、簡便快速的編程風格、高穩定性、可擴展性和跨平台性，以及強大的事務處理能力和消息通訊能力，成為業界市場占有率最高的消息中間件產品。

• WebLogic JMS：WebLogic JMS是Oracle公司一個高性能、集群的Messaging Server，基於WebLogic產品，支持數據庫和文件持久化，完全支持XA事務。

• RocketMQ：RocketMQ是阿里開源的分布式、隊列模型的消息中間件，支持嚴格的消息順序；支持Topic與Queue兩種模式；億級消息堆積能力；比較友好的分布式特性；同時支持Push與Pull方式消費消息。

• ActiveMQ：ActiveMQ是目前市場上非常流行的開源消息傳遞和集成服務器。它的消息傳遞速度非常快，支持多種跨平台的客戶端和協議，非常容易構建企業級的集成模式，同時支持JMS1.1和J2EE1.4規范。ActiveMQ基於Apache2.0許可。

• Apollo：Apollo是以ActiveMQ原型為基礎，是一個更快、更可靠、更易於維護的消息代理工具，Apache稱Apollo為最快、最強健的STOMP（Streaming Text Orientated Message Protocol，流文本定向消息協議）服務器。

• RabbitMQ：RabbitMQ是AQMP協議用Erlang實現的消息隊列產品，它實現了代理（Broker）架構，消息在發送到客戶端之前可以在中央節點上排隊。此特性使得RabbitMQ易於使用和部署，適宜於很多場景如路由、負載均衡或消息持久化等。

 

 

這是某團隊各產品功能和性能對比的最終結果，從結果來看：

 

ActiveMQ各功能模塊相對完善，不支持集群控制台管理，在訂閱模式性能測試（10K及以下消息大小）領先其他產品。

 

IBM WMQ有最完善的功能點實現，在點對點模式讀寫混合性能測試中領先其他產品。

 

Oracle JMS是Weblogic的組件，非獨立產品，各功能模塊相對完善，在點對點模式純讀取性能測試中領先其他產品，不支持AMQP消息協議。

 

RabbitMQ有獨特的鏡像隊列功能，能支持分布式內存復制實現持久化，在分布式擴展方面相對有優勢，控制台實現性能監控非常豐富。

 

RocketMQ功能模塊支持較差，實現的消息協議是自定義的文本傳輸協議，在1M消息大小的性能測試中領先其他產品。

 

Apollo產品成熟度不夠，不支持集群模式（消息路由）。

 

 

商業產品中IBM WMQ產品成熟度高，實現功能完整，應用廣泛，兼容性強，跨平台和跨語言支持較好；Oracle JMS是基於WebLogic的一個組件，僅支持JMS和WebLogic T3消息協議，不支持AMQP協議，跨平台支持有待完善。開源產品中ActiveMQ最成熟、功能最完善。

 

基本功能專題分析

 

• 總體來看，各產品在C/C++語言客戶端API、消息優先級實現相對較好。

• RocketMQ不支持用戶名和密碼認證、死信機制、消息有效期功能。

 

 

基本功能——語言和協議支持

 

 

基本功能——用戶名密碼認證：主要通過新建用戶名和密碼，使用JMS客戶端進行連接嘗試，實現用戶名密碼不一致的情況是否允許連接。

 

• IBM WMQ由隊列管理器、隊列、通道各部分組成，可通過界面對每個組成部分都進行訪問控制。

• Oracle JMS消息隊列基於AdminServer實例，可通過界面添加用戶，指定JMS消息隊列的訪問控制。

• RabbitMQ是根據業務划分不同的virtual hosts進行訪問控制。

• RocketMQ不支持用戶名密碼認證。

• ActiveMQ / Apollo支持主題和隊列兩種模式的訪問控制。

 

基本功能——死信機制：主要通過測試消息在傳遞失敗或消息過期時是否可以標記為死信。

 

• IBM WMQ、Oracle JMS、RabbitMQ、ActiveMQ均支持讀取異常、消息過期兩種死信機制。

• RocketMQ不支持消息死信機制。

• Apollo只支持消息過期模式，可設置redelivered參數，當超過maximumRedeliveries（缺省為6次）次數時，消息會放入死信隊列。

 

基本功能——消息有效期：主要通過在JMS客戶端設置消息生存時間，在生存時間結束后啟動消費者，消息是否被丟棄或銷毀。

 

• 除RocketMQ之外的產品均支持消息有效期配置。

• RabbiMQ消息有效期最長保留時間為2^32-1毫秒。

• RocketMQ支持隊列有效期設置，當磁盤空間不夠時會刪除創建時間最久的持久化文件。

 

基本功能——消息優先級：主要通過在JMS客戶端發送一組消息，是否可配置消息的優先級，是否可按消息的優先級進行處理。

 

• IBM WMQ、Oracle JMS、ActiveMQ、Apollo均支持消息優先級和隊列優先級配置。

• RabbitMQ、RocketMQ不支持消息優先級配置，只支持隊列優先級配置，即配置一個優先級高的隊列，和一個普通優先級的隊列，將優先級不同的消息發往不同隊列進行處理。

 

運維管理專題分析

 

• 總體來看，各產品在運維管理模塊實現都較為完善，沒有明顯短板。

• 商業產品在管理工具和日志系統相對較為完善。

• RabbitMQ監控系統的功能實現更為豐富。

 

 

運維管理——管理工具：在管理界面測試是否可以進行隊列的創建、刪除、啟動等基本功能。

 

• 商業產品在管理界面上支持較為完善，能通過管理界面進行隊列的創建、刪除及隊列的啟停等動作。

• 開源產品在管理界面上只支持隊列的創建、刪除，不支持隊列的啟停等動作。

• IBM WMQ、Oracle有完善的配置文件、命令行、接口支持。

• RabbitMQ、RocketMQ管理界面不支持隊列的啟停，可通過命令行、接口實現，支持Rest API接口。

• ActvieMQ / Apollo管理界面除不支持隊列的啟停外，不支持集中化管理，通過JMX配置文件實現，支持Rest API接口。

 

運維管理——日志系統：可以修改實例的日志級別，使其可以記錄系統的重要事件，比如新的入站連接、新消息入站等。

 

• 商業產品在日志系統上做得最為完善，日志配置也比較簡單。

• 開源產品在消息可見性、日志分割支持力度不夠。

• RabbitMQ基於AMQP協議，不支持第三方Log4j的日志打印實現。

• RocketMQ不支持TRACE日志跟蹤。

 

運維管理——監控系統：可監控消息中間件運行狀態，可監控到集群內所有節點隊列數、隊列中消息數、出入隊消息數、連接數等。

 

• RabbitMQ在監控系統模塊表現最為優秀，集群性能、隊列性能、消息發送次數、持久化大小、TPS性能等均有豐富的實現。

• RocketMQ不支持隊列內存占用和持久化大小的實現。

• IBM MQ、Oracle JMS不支持隊列內存占用、持久化大小、TPS性能的實現。

• ActiveMQ / Apollo僅支持單個隊列的控制台實現，但對單個隊列的監控實現較為豐富，不支持TPS性能的實現。

 

集群功能、事務支持、高可用、穩定性專題分析

 

• 除Apollo外各產品均能較好的實現集群所需功能。

• Apollo不支持集群功能（消息路由），能通過配置文件實現水平擴展，能通過failover協議實現負載均衡。

• RabbitMQ需通過第三方軟件HAProxy來實現負載均衡。

 

 

集群功能：通過配置集群實例，能實現隊列的水平擴展、動態擴展，能實現消息的路由和負載均衡。

 

• 除Apollo外各產品均能較好的實現集群所需功能。

• Apollo不支持集群功能（消息路由），能通過配置文件實現水平擴展，能通過failover協議實現負載均衡。

• RabbitMQ需通過第三方軟件HAProxy來實現負載均衡。

 

事務支持：通過應用程序測試是否支持本地事務的commit、rollback等機制。

 

• 所有產品均能較好的實現本地事務支持功能，包括事務提交、事務回滾等。

• RabbitMQ需購買商業JMS客戶端實現。

• Rocket采用自定義文本協議實現事務提交、回滾等功能。

 

高可用：通過測試當隊列服務器出現故障或者網絡故障時，客戶端可以自動連接到其他隊列，保持業務的不間斷。

 

• 所有產品均能實現FAILOVER機制，RabbitMQ需通過HAProxy來實現FAILOVER。

• 僅RabbitMQ能實現消息的無持久化內存復制。

• IBM WMQ、RabbitMQ、RocketMQ、ActiveMQ能實現Master-Slave模式高可用。

 

穩定性：通過持續發送消息，主機CPU在60%以上壓力下，消息中間件運行情況。

 

• 各產品均表現出良好的穩定性，在連續12小時高並發測試情況下，均能保持100%的消息處理正確率。

 

 

擴展功能專題分析

 

• 各產品在文件傳輸功能、事件消息機制、網絡限流方面均能較好的實現。

• RabbitMQ文件傳輸、大文件傳輸、交易一致性、延遲隊列功能需購買JMS客戶端實現。

• RocketMQ不支持大文件傳輸。

• Apollo不支持續傳重傳、延遲隊列功能。

 

 

文件傳輸功能：通過測試服務器之間的文件傳輸，統計數據發送和接收正確率，檢驗是否有文件丟失或重復。

 

• 所有產品均能實現文件傳輸功能。商業產品本身支持文件傳輸功能，開源產品需通過應用程序實現。

• RabbitMQ文件傳輸功能需購買JMS客戶端實現。

 

事件消息機制功能：通過在測試時，人為進行網絡斷連等異常事件，在出現異常事件后消息節點會收到異常事件信息。

 

• 所有產品均能實現事件消息機制功能。

• IBM WMQ支持各種事件的配置是否啟用，如權限事件、禁止事件、本地事件等等。

 

網絡限流功能：通過調整消息中間件的配置參數，測試允許使用的網絡帶寬，進行數據傳輸，檢查限流功能。

 

• IBM WMQ對網絡限流支持較為全面，能通過消息大小限制、批次傳輸限制、消息總量限制、內存使用限制、磁盤使用限制等各種配置實現對網絡限流功能。

• Oracle JMS可通過消息大小限制、消息總量限制實現對網絡限流功能。

• RabbitMQ支持通過對內存使用限制、磁盤使用限制實現對網絡限流功能。

• RocketMQ支持通過消息大小限制實現網絡限流功能。

• ActiveMQ支持通過內存使用限制實現網絡限流功能。

• Apollo支持通過消息總量限制實現網絡限流功能。

 

 

續傳重傳功能：通過人為斷開網絡來測試消息中間件的斷點續傳能力，統計數據發送和接收正確率，檢查是否有數據丟失或重復。

 

• 除Apollo之外的產品均支持續傳重傳功能。

• Apollo不支持ConnectionControl command處理，不能實現自動重連，所以不支持重傳功能。預計在Apollo1.8版本中實現該特性。

 

大文件傳輸效率：通過進行大文件傳輸測試消息中間件對大文件傳輸的支持程度。

 

• IBM WMQ、Oracle JMS、ActiveMQ、Apollo支持大文件傳輸。

• RabbitMQ需購買JMS客戶端實現。

• RocketMQ不支持大文件傳輸。

 

 

交易一致性：通過驗證消息中間件是否支持交易最終一致性。

 

• 除Rocket之外的產品均支持交易一致性功能。

• RabbitMQ需購買JMS客戶端實現。

• 開源版RocketMQ不支持分布式事物，商業版ONS支持。

 

延遲隊列：通過應用程序設置消息延時時間，在延時時間后消息是否被丟棄或銷毀，無法被處理。

 

• 除Apollo之外各產品均支持延遲隊列功能。

• RabbitMQ需購買JMS客戶端實現。

 

總體性能測試結果

 

• 各產品在水平擴展性能測試方面，均有優秀的表現。

• 點對點性能測試方面，RabbitMQ、Oracle JMS表現尚可，ActiveMQ、IBM WMQ、RocketMQ略有不足，Apollo差距較大。

• 訂閱性能測試方面，ActiveMQ一枝獨秀，表現優秀，RocketMQ、IBM WMQ表現尚可，Oracle JMS、Apollo仍有差距，RabbitMQ差距較大。

 

 

水平擴展專題分析：通過兩節點、四節點配置進行消息大小1KB、持久化、讀寫混合的性能測試，得出水平擴展的數據。

 

• 從各產品的水平擴展能力來看，RabbitMQ和Rocket的處理能力明顯優於其他產品。2節點的處理能力，RabbiMQ和RocketMQ優勢較為明顯。

 

 

點對點性能測試專題分析：通過進行點對點模式，分1K、2K、10K、1M四種消息大小、對8個隊列組成的集群進行性能測試。

 

• IBM WMQ在讀寫混合性能測試中表現優秀，純寫入性能測試表現不理想。

• Oracle JMS在純讀取性能測試中表現優秀，純寫入性能測試表現不理想。

• RabbitMQ在持久化方面支持內存復制模式，在純寫入性能測試表現優秀，純讀取性能測試不理想。

• RocketMQ不支持非持久化，純讀取性能測試表現優秀，純寫入性能測試不理想。

• ActiveMQ在混合性能測試中表現優秀，純寫入性能測試表現良好，純讀取性能測試表現不理想。

• Apollo整體表現較差，僅在非持久化純寫入和純讀取性能測試表現尚可。

 

 

訂閱性能測試專題分析：通過進行訂閱模式，分1K、2K、10K、1M四種消息大小、對8個隊列組成的集群進行性能測試。

 

• ActiveMQ整體表現非常優秀，無論是非持久化還是持久化。

• RocketMQ不支持非持久化，持久化方面整體有着較好的表現。

• IBM WMQ整體表現均衡，讀寫混合性能測試中表現稍好。

• Oracle JMS整體表現均衡，在非持久化讀寫混合性能測試表現優秀。

• Apollo整體表現一般，讀寫混合性能測試表現較好。

• RabbitMQ整體表現仍有差距，非持久化性能測試不理想。