導(dǎo)讀：本文是從《Message Queue Shootout!》這篇文章翻譯而來，譯文來自外刊IT評(píng)論《消息隊(duì)列軟件產(chǎn)品大比拼》。

內(nèi)容如下：

我花了一周的時(shí)間評(píng)估比較了一下各種消息隊(duì)列產(chǎn)品，非常的有趣。我做這個(gè)事的動(dòng)機(jī)是因?yàn)橐粋€(gè)客戶有一個(gè)很高性能需求。他們的消息信息突破了1百萬個(gè)并發(fā)。目前他們使用的是SQL server，并不理想，我建議他們使用消息隊(duì)列服務(wù)器。

為了對(duì)一些相似的候選產(chǎn)品獲得一個(gè)全面的但是粗淺的性能上的了解，我們它們放在一起做了個(gè)測(cè)試。我讓每個(gè)消息產(chǎn)品各發(fā)送和接受1百萬千條1K的消息。測(cè)試準(zhǔn)備的有些倉(cāng)促，我并沒有修改任何的配置，只是快速的看了一下它們的安裝文檔，安裝好每種軟件，然后就讓它們做這些最簡(jiǎn)單的收發(fā)信息的操作。所以這是一次真正的“開箱即裝即用”的性能表現(xiàn)。我完全理解，這對(duì)那些初始配置十分保守的消息隊(duì)列產(chǎn)品將會(huì)是個(gè)懲罰。

候選產(chǎn)品有：

MSMQ.

這是微軟的產(chǎn)品里唯一被認(rèn)為有價(jià)值的東西。對(duì)我的客戶來說，如果MSMQ能證明可以應(yīng)對(duì)這種任務(wù)，他們將選擇使用它。關(guān)鍵是這個(gè)東西并不復(fù)雜，除了接收和發(fā)送，沒有別的；它有一些硬性限制，比如最大消息體積是4MB。然而，通過和一些像MassTransit或NServiceBus這樣的軟件的連接，它完全可以解決這些問題。

ActiveMQ.

Java世界的中堅(jiān)力量。它有很長(zhǎng)的歷史，而且被廣泛的使用。它還是跨平臺(tái)的，給那些非微軟平臺(tái)的產(chǎn)品提供了一個(gè)天然的集成接入點(diǎn)。然而，它只有跑過了MSMQ才有可能被考慮。

RabbitMQ.

我聽說了很多關(guān)于這個(gè)用Erlang寫成的消息中間件的優(yōu)秀的特性。它支持開放的高級(jí)消息隊(duì)列協(xié)議(AMQP，Advanced Message Queuing Protocol)，從根本上避免了生產(chǎn)廠商的封閉，使用任何語言的各種客戶都可以從中受益。這種協(xié)議提供了相當(dāng)復(fù)雜的消息傳輸模式，所以基本上不需要MassTransit或NServiceBus的配合。它還具有“企業(yè)級(jí)”的適應(yīng)性和穩(wěn)定性。這些東西對(duì)我的客戶來說十分的有吸引力。

ZeroMQ.

我在研究AMQP時(shí)從發(fā)現(xiàn)了這個(gè)產(chǎn)品。開發(fā)這個(gè)產(chǎn)品的公司是AMQP集團(tuán)的一部分，并且還有一個(gè)叫做OpenAMQ的產(chǎn)品。然而，他們卻戲劇性的從AMQP分離的出去，并抱怨說這這個(gè)產(chǎn)品迷失了方向、變的越來越復(fù)雜。你可以到這里閱讀Dear John的關(guān)于此事的文章。ZeroMQ具有一個(gè)獨(dú)特的非中間件的模式，也就是說，跟其它幾個(gè)接受測(cè)試的產(chǎn)品不同，你不需要安裝和運(yùn)行一個(gè)消息服務(wù)器，或中間件。你只需要簡(jiǎn)單的引用ZeroMQ程序庫，可以使用NuGet安裝，然后你就可以愉快的在應(yīng)用程序之間發(fā)送消息了。非常有趣的是，他們也同樣使用這方式在任何利用ZeroMQ進(jìn)行強(qiáng)大的進(jìn)程內(nèi)通信的語言里創(chuàng)建Erlang風(fēng)格的這種執(zhí)行角色。

把這四個(gè)MQ產(chǎn)品裝上、跑起來是一個(gè)很有趣的工作。當(dāng)你需要安裝一個(gè)非Windows平臺(tái)的產(chǎn)品時(shí)，下一定的功夫那是必須的。ActiveMQ需要在目標(biāo)機(jī)器上安裝Java，RabbitMQ需要Erlang環(huán)境。安裝這兩個(gè)產(chǎn)品都沒有遇到麻煩，但我想這是否給系統(tǒng)的維護(hù)增加了一層任務(wù)。如果這個(gè)中的一個(gè)被選中，我需要讓系統(tǒng)維護(hù)的人去理解和維護(hù)他們以前不熟悉的運(yùn)行庫。ActiveMQ，

RabbitMQ和MSMQ都需要啟動(dòng)服務(wù)進(jìn)程，這些都可以監(jiān)控和配置，另外一個(gè)就有問題了。

ZeroMQ，它沒有中間件架構(gòu)，不需要任何服務(wù)進(jìn)程和運(yùn)行時(shí)。事實(shí)上，你的應(yīng)用程序端點(diǎn)扮演了這個(gè)服務(wù)角色。這讓部署起來非常簡(jiǎn)單，但擔(dān)心的是，你沒有地方可以觀察它是否有問題出現(xiàn)。就目前我知道的，ZeroMQ僅提供非持久性的隊(duì)列。你可以在需要的地方實(shí)現(xiàn)自己的審計(jì)和數(shù)據(jù)恢復(fù)功能。老實(shí)說，我甚至不確信是否該把它列在此次測(cè)試中，它的運(yùn)行原理和其它幾種差別太大了。

我就不瞎扯了，下面是測(cè)試結(jié)果。顯示的是發(fā)送和接受的每秒鐘的消息數(shù)。整個(gè)過程共產(chǎn)生1百萬條1K的消息。測(cè)試的執(zhí)行是在一個(gè)Windows Vista上進(jìn)行的。

就像你看到的，ZeroMQ和其它的不是一個(gè)級(jí)別。它的性能驚人的高。公平的說，ZeroMQ跟其它幾個(gè)比起來像頭巨獸，盡管這樣，結(jié)論很清楚：如果你希望一個(gè)應(yīng)用程序發(fā)送消息越快越好，你選擇ZeroMQ。當(dāng)你不太在意偶然會(huì)丟失某些消息的情況下更有價(jià)值。

老實(shí)講，我更希望使用Rabbit。但這種事情是應(yīng)該做更多的測(cè)試，你最終會(huì)有一個(gè)最愛，我所聽到的、讀到的各種關(guān)于Rabbit的事情讓我覺得它應(yīng)該是最佳選擇。但使用這個(gè)測(cè)試結(jié)果，我很難說服他們不去使用MSMQ。

如果你想自己跑一下這些測(cè)試，我的測(cè)試代碼都放在了GitHub上。我很感興趣(但不是非常非常感興趣)想知道如何優(yōu)化這些測(cè)試，所以，如果你能做到一個(gè)更好的測(cè)試結(jié)果，請(qǐng)告訴我。謝謝。

譯文出自：外刊IT評(píng)論

轉(zhuǎn)載于:https://www.cnblogs.com/waw/articles/2187698.html

總結(jié)

以上是生活随笔為你收集整理的消息队列软件产品大比拼的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。