消息隊列軟件產品大比拼(轉)

轉自：外刊IT評論

我花了一週的時間評估比較了一下各類消息隊列產品，很是的有趣。我作這個事的動機是由於一個客戶有一個很高性能需求。他們的消息信息突破了1百萬個併發。目前他們使用的是SQL server，並不理想，我建議他們使用消息隊列服務器。

爲了對一些類似的候選產品得到一個全面的可是粗淺的性能上的瞭解，咱們它們放在一塊兒作了個測試。我讓每一個消息產品各發送和接受1百萬千條1K的消息。測試準備的有些倉促，我並無修改任何的配置，只是快速的看了一下它們的安裝文檔，安裝好每種軟件，而後就讓它們作這些最簡單的收發信息的操做。因此這是一次真正的「開箱即裝即用」的性能表現。我徹底理解，這對那些初始配置十分保守的消息隊列產品將會是個懲罰。

候選產品有：

• MSMQ.
  這是微軟的產品裏惟一被認爲有價值的東西。對個人客戶來講，若是MSMQ能證實能夠應對這種任務，他們將選擇使用它。關鍵是這個東西並不複雜，除了接收和發送，沒有別的；它有一些硬性限制，好比最大消息體積是4MB。然而，經過和一些像MassTransit 或 NServiceBus這樣的軟件的鏈接，它徹底能夠解決這些問題。
• ActiveMQ.
  Java世界的中堅力量。它有很長的歷史，並且被普遍的使用。它仍是跨平臺的，給那些非微軟平臺的產品提供了一個自然的集成接入點。然而，它只有跑過了MSMQ纔有可能被考慮。
• RabbitMQ.
  我據說了不少關於這個用Erlang寫成的消息中間件的優秀的特性。它支持開放的高級消息隊列協議 (AMQP，Advanced Message Queuing Protocol)，從根本上避免了生產廠商的封閉，使用任何語言的各類客戶均可以從中受益。這種協議提供了至關複雜的消息傳輸模式，因此基本上不須要MassTransit 或 NServiceBus 的配合。它還具備「企業級」的適應性和穩定性。這些東西對個人客戶來講十分的有吸引力。
• ZeroMQ.
  我在研究AMQP時從發現了這個產品。開發這個產品的公司是AMQP集團的一部分，而且還有一個叫作OpenAMQ的產品。然而，他們卻戲劇性的從AMQP分離的出去，並抱怨說這這個產品迷失了方向、變的愈來愈複雜。你能夠到這裏閱讀Dear John的關於此事的文章。ZeroMQ具備一個獨特的非中間件的模式，也就是說，跟其它幾個接受測試的產品不一樣，你不須要安裝和運行一個消息服務器，或中間件。你只須要簡單的引用ZeroMQ程序庫，可使用NuGet安裝，而後你就能夠愉快的在應用程序之間發送消息了。很是有趣的是，他們也一樣使用這方式在任何利用ZeroMQ進行強大的進程內通訊的語言裏建立Erlang風格的這種執行角色。

把這四個MQ產品裝上、跑起來是一個頗有趣的工做。當你須要安裝一個非Windows平臺的產品時，下必定的功夫那是必須的。ActiveMQ須要在目標機器上安裝Java，RabbitMQ須要Erlang環境。安裝這兩個產品都沒有遇到麻煩，但我想這是否給系統的維護增長了一層任務。若是這個中的一個被選中，我須要讓系統維護的人去理解和維護他們之前不熟悉的運行庫。ActiveMQ，
RabbitMQ 和 MSMQ 都須要啓動服務進程，這些均可以監控和配置，另一個就有問題了。

ZeroMQ，它沒有中間件架構，不須要任何服務進程和運行時。事實上，你的應用程序端點扮演了這個服務角色。這讓部署起來很是簡單，但擔憂的是，你沒有地方能夠觀察它是否有問題出現。就目前我知道的，ZeroMQ僅提供非持久性的隊列。你能夠在須要的地方實現本身的審計和數據恢復功能。老實說，我甚至不確信是否該把它列在這次測試中，它的運行原理和其它幾種差異太大了。

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

就像你看到的，ZeroMQ和其它的不是一個級別。它的性能驚人的高。公平的說，ZeroMQ跟其它幾個比起來像頭巨獸，儘管這樣，結論很清楚：若是你但願一個應用程序發送消息越快越好，你選擇ZeroMQ。當你不太在乎偶然會丟失某些消息的狀況下更有價值。

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

若是你想本身跑一下這些測試，個人測試代碼都放在了GitHub上。我很感興趣(但不是很是很是感興趣)想知道如何優化這些測試，因此，若是你能作到一個更好的測試結果，請告訴我。謝謝。