消息隊列軟體産品大比拼

我花了一周的時間評估比較了一下各種消息隊列産品，非常的有趣。我做這個事的動機是因為一個客戶有一個很高性能需求。他們的消息資訊突破了1百萬個并發。目前他們使用的是SQL server，并不理想，我建議他們使用消息隊列伺服器。

為了對一些相似的候選産品獲得一個全面的但是粗淺的性能上的了解，我們它們放在一起做了個測試。我讓每個消息産品各發送和接受1百萬千條1K的消息。測試準備的有些倉促，我并沒有修改任何的配置，隻是快速的看了一下它們的安裝文檔，安裝好每種軟體，然後就讓它們做這些最簡單的收發資訊的操作。是以這是一次真正的“開箱即裝即用”的性能表現。我完全了解，這對那些初始配置十分保守的消息隊列産品将會是個懲罰。

候選産品有：

MSMQ

這是微軟的産品裡唯一被認為有價值的東西。對我的客戶來說，如果MSMQ能證明可以應對這種任務，他們将選擇使用它。關鍵是這個東西并不複雜，除了接收和發送，沒有别的；它有一些硬性限制，比如最大消息體積是4MB。然而，通過和一些像MassTransit 或 NServiceBus這樣的軟體的連接配接，它完全可以解決這些問題。

<a href="http://activemq.apache.org/" target="_blank">ActiveMQ</a>

Java世界的中堅力量。它有很長的曆史，而且被廣泛的使用。它還是跨平台的，給那些非微軟平台的産品提供了一個天然的內建接入點。然而，它隻有跑過了MSMQ才有可能被考慮。

<a href="http://www.rabbitmq.com/" target="_blank">RabbitMQ</a>

我聽說了很多關于這個用Erlang寫成的消息中間件的優秀的特性。它支援開放的進階消息隊列協定 (AMQP，Advanced Message Queuing Protocol)，從根本上避免了生産廠商的封閉，使用任何語言的各種客戶都可以從中受益。這種協定提供了相當複雜的消息傳輸模式，是以基本上不需要MassTransit 或 NServiceBus 的配合。它還具有“企業級”的适應性和穩定性。這些東西對我的客戶來說十分的有吸引力。

<a href="http://www.zeromq.org/" target="_blank">ZeroMQ</a>

把這四個MQ産品裝上、跑起來是一個很有趣的工作。當你需要安裝一個非Windows平台的産品時，下一定的功夫那是必須的。ActiveMQ需要在目标機器上安裝Java，RabbitMQ需要Erlang環境。安裝這兩個産品都沒有遇到麻煩，但我想這是否給系統的維護增加了一層任務。如果這個中的一個被選中，我需要讓系統維護的人去了解和維護他們以前不熟悉的運作庫。ActiveMQ，

RabbitMQ 和 MSMQ 都需要啟動服務程序，這些都可以監控和配置，另外一個就有問題了。

ZeroMQ，它沒有中間件架構，不需要任何服務程序和運作時。事實上，你的應用程式端點扮演了這個服務角色。這讓部署起來非常簡單，但擔心的是，你沒有地方可以觀察它是否有問題出現。就目前我知道的，ZeroMQ僅提供非持久性的隊列。你可以在需要的地方實作自己的審計和資料恢複功能。老實說，我甚至不确信是否該把它列在此次測試中，它的運作原理和其它幾種差别太大了。

我就不瞎扯了，下面是測試結果。顯示的是發送和接受的每秒鐘的消息數。整個過程共産生1百萬條1K的消息。測試的執行是在一個Windows Vista上進行的。

Message Queue shootout

就像你看到的，ZeroMQ和其它的不是一個級别。它的性能驚人的高。公平的說，ZeroMQ跟其它幾個比起來像頭巨獸，盡管這樣，結論很清楚：如果你希望一個應用程式發送消息越快越好，你選擇ZeroMQ。當你不太在意偶然會丢失某些消息的情況下更有價值。

老實講，我更希望使用Rabbit。但這種事情是應該做更多的測試，你最終會有一個最愛，我所聽到的、讀到的各種關于Rabbit的事情讓我覺得它應該是最佳選擇。但使用這個測試結果，我很難說服他們不去使用MSMQ。

原文釋出時間為：2013-07-26

本文來自雲栖社群合作夥伴“Linux中國”