RabbitMQ
是使用Erlang編寫的一個開源的消息隊列，本身支持很多的協議：AMQP，XMPP, SMTP, STOMP，也正是如此，使的它變的非常重量級，更適合於企業級的開發。同時實現了一個經紀人(Broker)構架，這意味着消息在發送給客戶端時先在中心隊列排隊。對路由(Routing)，負載均衡(Load balance)或者數據持久化都有很好的支持。
Redis
是一個Key-Value的NoSQL數據庫，開發維護很活躍，雖然它是一個Key-Value數據庫存儲系統，但它本身支持MQ功能，所以完全可以當做一個輕量級的隊列服務來使用。對於RabbitMQ和Redis的入隊和出隊操作，各執行100萬次，每10萬次記錄一次執行時間。測試數據分爲128Bytes、512Bytes、1K和10K四個不同大小的數據。實驗表明：入隊時，當數據比較小時Redis的性能要高於RabbitMQ，而如果數據大小超過了10K，Redis則慢的無法忍受；出隊時，無論數據大小，Redis都表現出非常好的性能，而RabbitMQ的出隊性能則遠低於Redis。
|
|
入隊 |
出隊 |
||||||
|
|
128B |
512B |
1K |
10K |
128B |
512B |
1K |
10K |
|
Redis |
16088 |
15961 |
17094 |
25 |
15955 |
20449 |
18098 |
9355 |
|
RabbitMQ |
10627 |
9916 |
9370 |
2366 |
3219 |
3174 |
2982 |
1588 |
ZeroMQ
號稱最快的消息隊列系統，尤其針對大吞吐量的需求場景。ZMQ能夠實現RabbitMQ不擅長的高級/複雜的隊列，但是開發人員需要自己組合多種技術框架，技術上的複雜度是對這MQ能夠應用成功的挑戰。ZeroMQ具有一個獨特的非中間件的模式，你不需要安裝和運行一個消息服務器或中間件，因爲你的應用程序將扮演了這個服務角色。你只需要簡單的引用ZeroMQ程序庫，可以使用NuGet安裝，然後你就可以愉快的在應用程序之間發送消息了。但是ZeroMQ僅提供非持久性的隊列，也就是說如果down機，數據將會丟失。其中，Twitter的Storm中使用ZeroMQ作爲數據流的傳輸。
Webservice 和MQ(MessageQueue)都是解決跨平臺通信的常用手段，兩者有哪些區別呢？
個人認爲最本質的區別在於 Webservice近乎實時通信，而MQ卻通常是延時通信。 什麼意思呢？ 因爲webservice其實就是本地服務器程序調用遠程服務器上的方法，屬於兩者之間的交互，請求的時候需要等被請求的服務器做出迴應後，另一端纔會有所動作，也就是說，如果你請求的service服務器關閉了，或者中斷了，那麼你這邊肯定就得不到答覆了，你的這次請求就算是打水漂丟失了。 而MQ 則相當於是多了一箇中間件 我所發送的請求 都必須先傳達給 這個消息隊列組件，然後由這個消息隊列組件再去到另一個服務器上去請求，有了響應之後再 返回給 當初的請求程序，因爲MessageQueue組件會把消息持久化放在本地，所以哪怕突然死機了，請求消息也是不會丟失的。 比如我們有些複雜的生成報表的請求，生成一張報表可能會相當繁雜，要這麼幾分鐘，那我們肯定不可能在那乾等，這時候就使用MQ，按這個請求報表的需求傳給MQ,等到接收程序處理完返回之後，我這邊會收到通知，這樣就比較好。 常見的MQ組件 包括MSMQ ,Apache ActiveMQ以及一些開源mq等。
