我花了一週的時間評估比較了一下各種訊息佇列產品，非常的有趣。我做這個事的動機是因為一個客戶有一個很高效能需求。他們的訊息資訊突破了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上。我很感興趣(但不是非常非常感興趣)想知道如何優化這些測試，所以，如果你能做到一個更好的測試結果，請告訴我。謝謝。
原文：mikehadlow 譯文：外刊IT評論