MQ作爲中間件，消息隊列是分佈式應用間交換信息的重要組件。消息隊列可存儲在內存和磁盤上，隊列可以存儲消息直至它們被應用程序接收。通過消息隊列在應用程序不知道彼此位置的情況下可以獨立處理信息或在處理消息前不需要等待接收該消息。所有消息隊列可以解決應用解耦、異步消息等問題，是實現高性能、高可用、可伸縮和一致性架構中不可或缺的一環。

目前業界有很多MQ產品，小編作如下對比：

ZeroMQ：號稱最快的消息隊列系統，尤其針對大吞吐量的需求場景。擴展性好，開發比較靈活，採用C語言實現，實際上只是一個socket庫的重新封裝，如果做爲消息隊列使用，需要開發大量的代碼。ZeroMQ僅提供非持久性的隊列，也就是說如果down機，數據將會丟失。其中，Twitter的Storm中使用ZeroMQ作爲數據流的傳輸。

RabbitMQ：結合erlang語言本身的併發優勢，支持很多的協議：AMQP，XMPP, SMTP, STOMP，也正是如此，使的它變的非常重量級，更適合於企業級的開發。性能較好，但是不利於做二次開發和維護。

ActiveMQ: 歷史悠久的開源項目，是Apache下的一個子項目。已經在很多產品中得到應用，實現了JMS1.1規範，可以和spring-jms輕鬆融合，實現了多種協議，不夠輕巧（源代碼比RocketMQ多），支持持久化到數據庫，對隊列數較多的情況支持不好，不過我們的項目中並不會建很多的隊列。

Redis：做爲一個基於內存的K-V數據庫，其提供了消息訂閱的服務，可以當作MQ來使用，目前應用案例較少，且不方便擴展。對於RabbitMQ和Redis的入隊和出隊操作，各執行100萬次，每10萬次記錄一次執行時間。測試數據分爲 128Bytes、512Bytes、1K和10K四個不同大小的數據。實驗表明：入隊時，當數據比較小時Redis的性能要高於RabbitMQ，而如 果數據大小超過了10K，Redis則慢的無法忍受；出隊時，無論數據大小，Redis都表現出非常好的性能，而RabbitMQ的出隊性能則遠低於 Redis。

RocketMQ: 阿里巴巴的MQ中間件，在其多個產品下使用，並能夠撐住雙十一的大流量，他並沒有實現JMS規範，使用起來很簡單。部署由一個 命名服務（nameserver）和一個代理（broker）組成，nameserver和broker以及producer都支持集羣，隊列的容量受機器硬盤的限制，隊列滿後可以支持持久化到硬盤（也可以自己適配代碼，將其持久化到NOSQL數據庫中），隊列滿後會影響吞吐量，可以採用主備來保證穩定性，支持回溯消費，可以在broker端進行消息過濾。

Jafka/Kafka：Kafka是Apache下的一個子項目，是一個高性能跨語言分佈式Publish/Subscribe消息隊列系統，而Jafka是在Kafka 之上孵化而來的，即Kafka的一個升級版。

具有以下特性：快速持久化，可以在O(1)的系統開銷下進行消息持久化；高吞吐，在一臺普通的服務器上既可以 達到10W/s的吞吐速率；完全的分佈式系統，Broker、Producer、Consumer都原生自動支持分佈式，自動實現複雜均衡；支持 Hadoop數據並行加載，對於像Hadoop的一樣的日誌數據和離線分析系統，但又要求實時處理的限制，這是一個可行的解決方案。Kafka通過 Hadoop的並行加載機制來統一了在線和離線的消息處理，這一點也是本課題所研究系統所看重的。

Apache Kafka相對於ActiveMQ是一個非常輕量級的消息系統，除了性能非常好之外，還是一個工作良好的分佈式系統。

針對消息中間件的選擇可以從以下方面進行考慮，以ActiveMQ和RocketMQ對比作爲案例。

優先級：我們的項目對此需求不是特別明顯，RocketMQ需要新建一個特殊隊列來接收優先級高的隊列，無法實現從0-65535這種細粒度的控制，ActiveMQ可以精細控制。

順序：我們的消息總線中的消息應該都是無狀態的，所以對消息的處理順序沒有嚴格的要求，如果有特殊要求的話可以在業務層進行控制，activeMQ無法保證嚴格的順序，RocketMQ可以保證嚴格的消費順序。

持久化：都支持

穩定性：RoketMQ在穩定性上可能更值得信賴，支持多種集羣方案。

消息過濾：ActiveMQ僅支持在客戶端消費的時候進行判斷是否是自己需要的消息，RocketMQ可以在broker端進行過濾，對於我們的消息總線，這裏可以節省大量的網絡傳輸是否會有消息重發造成的重複消費：RocketMQ可以保證，ActiveMQ無法保證。

回溯消費：即重新將某一個時刻之前的消息重新消費一遍，我們對於這種需求應該很少，RocketMQ支持，ActiveMQ不支持（RocketMQ的隊列是持久化到硬盤的，定期進行清除。

事務：都支持

定時消費：RocketMQ支持

消息堆積：就是當緩存消息的內存滿了之後的解決方案，一種是丟棄策略，這種不會影響吞吐量，還有一種就是將消息持久化到磁盤，這種會影響吞吐量，在評估影響程度上，RocketMQ的成績稍微好一點。

客戶端不在線：RocketMQ可以在客戶端上線後繼續將未消費的消息推送到客戶端。