幾種MQ產品說明：
ZeroMQ : 擴展性好，開發比較靈活，采用C語言實現，實際上他只是一個socket庫的重新封裝，如果我們做為消息隊列使用，需要開發大量的代碼
RabbitMQ :結合erlang語言本身的並發優勢，性能較好，但是不利於做二次開發和維護
ActiveMQ: 歷史悠久的開源項目，已經在很多產品中得到應用，實現了JMS1.1規范，可以和spring-jms輕松融合，實現了多種協議，不夠輕巧（源代碼比RocketMQ多）.，支持持久化到數據庫，對隊列數較多的情況支持不好，不過我們的項目中並不會建很多的隊列.ActiveMQ是Apache下的一個子項目。
Redis 做為一個基於內存的K-V數據庫，其提供了消息訂閱的服務，可以當作MQ來使用，目前應用案例較少，且不方便擴展
RocketMQ: 阿里巴巴的MQ中間件，在其多個產品下使用，並能夠撐住雙十一的大流量，他並沒有實現JMS規范，使用起來很簡單。部署由一個 命名服務（nameserver）和一個代理（broker）組成，nameserver和broker以及producer都支持集群，隊列的容量受機器硬盤的限制，隊列滿后可以支持持久化到硬盤（也可以自己適配代碼，將其持久化到NOSQL數據庫中），隊列滿后會影響吞吐量，可以采用主備來保證穩定性，支持回溯消費，可以在broker端進行消息過濾.
Kafka/Jafka
Kafka是Apache下的一個子項目，是一個高性能跨語言分布式發布/訂閱消息隊列系統，而Jafka是在Kafka之上孵化而來的，即Kafka的一個升級版。具有以下特性：快速持久化，可以在O(1)的系統開銷下進行消息持久化；高吞吐，在一台普通的服務器上既可以達到10W/s的吞吐速率；完全的分布式系統，Broker、Producer、Consumer都原生自動支持分布式，自動實現負載均衡；支持Hadoop數據並行加載，對於像Hadoop的一樣的日志數據和離線分析系統，但又要求實時處理的限制，這是一個可行的解決方案。Kafka通過Hadoop的並行加載機制統一了在線和離線的消息處理。Apache Kafka相對於ActiveMQ是一個非常輕量級的消息系統，除了性能非常好之外，還是一個工作良好的分布式系統。
Kafka設計的初衷就是處理日志的，可以看做是一個日志系統，針對性很強，所以它並沒有具備一個成熟MQ應該具備的特性.
針對消息中間件的選擇可以從以下方面進行考慮：(主要對比ActiveMQ和RocketMQ)
優先級：我們的項目對此需求不是特別明顯，RocketMQ需要新建一個特殊隊列來接收優先級高的隊列，無法實現從0-65535這種細粒度的控制，ActiveMQ可以精細控制
順序：我們的消息總線中的消息應該都是無狀態的，所以對消息的處理順序沒有嚴格的要求，如果有特殊要求的話可以在業務層進行控制，activeMQ無法保證嚴格的順序，RocketMQ可以保證嚴格的消費順序
持久化：都支持
穩定性：RoketMQ在穩定性上可能更值得信賴，支持多種集群方案，畢竟已經撐過幾個雙十一
消息過濾：ActiveMQ僅支持在客戶端消費的時候進行判斷是否是自己需要的消息，RocketMQ可以在broker端進行過濾，對於我們的消息總線，這里可以節省大量的網絡傳輸是否會有消息重發造成的重復消費：RocketMQ可以保證，ActiveMQ無法保證
回溯消費：即重新將某一個時刻之前的消息重新消費一遍，我們對於這種需求應該很少，RocketMQ支持，ActiveMQ不支持（RocketMQ的隊列是持久化到硬盤的，定期進行清除
事務：都支持
定時消費：RocketMQ支持
消息堆積：就是當緩存消息的內存滿了之后的解決方案，一種是丟棄策略，這種不會影響吞吐量，還有一種就是將消息持久化到磁盤，這種會影響吞吐量，在評估影響程度上，RocketMQ的成績稍微好一點
客戶端不在線：RocketMQ可以在客戶端上線后繼續將未消費的消息推送到客戶端
目前比較活躍的幾種MQ中間件產品的對比如下：（僅統計開源的項目）
| ActiveMQ | RabbitMQ | RocketMq | ZeroMQ | |
| 關注度 | 高 | 高 | 中 | 中 |
| 成熟度 | 成熟 | 成熟 | 比較成熟 | 不成熟 |
| 所屬社區/公司 | Apache | Mozilla Public License |
Alibaba | |
| 社區活躍度 | 高 | 高 | 中 | 低 |
| 文檔 | 多 | 多 | 中 | 中 |
| 特點 | 功能齊全，被大量開源項目使用 | 由於Erlang 語言的並發能力，性能很好 | 各個環節分布式擴展設計，主從 HA；支持上萬個隊列；多種消費模式；性能很好 | 低延時，高性能，最高 43萬條消息每秒 |
| 授權方式 | 開源 | 開源 | 開源 | 開源 |
| 開發語言 | Java | Erlang | Java | C |
| 支持的協議 | OpenWire、 STOMP、 REST、XMPP、 AMQP |
AMQP | 自己定義的一 套(社區提供 JMS--不成熟) |
TCP、UDP |
| 客戶端支持語言 | Java、C、 C++、 Python、 PHP、 Perl、.net 等 |
Java、C、 C++、 Python、 PHP、Perl 等 |
Java C++（不成熟） |
python、 java、 php、.net 等 |
| 持久化 | 內存、文件、數據庫 | 內存、文件 | 磁盤文件 | 在消息發送端保存 |
| 事務 | 支持 | 不支持 | 支持 | 不支持 |
| 集群 | 支持 | 支持 | 支持 | 不支持 |
| 負載均衡 | 支持 | 支持 | 支持 | 不支持 |
| 管理界面 | 一般 | 好 | 無社區有 web console 實現 |
無 |
| 部署方式 | 獨立、嵌入 | 獨立 | 獨立 | 獨立 |
| 評價 | 優點： 成熟的產品，已經在很多公司得到應用（非大規模場景）。有較多的文檔。各種協議支持較好，有多重語言的成熟的客戶端； 缺點： 根據其他用戶反饋，會出莫名其妙的問題，切會丟失消息。 其重心放到activemq6.0 產品—apollo 上去了，目前社區不活躍，且對 5.x 維護較少； Activemq 不適合用於上千個隊列的應用場景 |
優點： 由於erlang語言的特性，mq 性能較好；管理界面較豐富，在互聯網公司也有較大規模的應用；支持amqp系誒，有多中語言且支持 amqp 的客戶端可用 缺點： erlang語言難度較 大。集群不支持動態擴展。 |
優點： 模型簡單，接口易用（JMS 的接口很多場合並不太實用）。在阿里大規模應用。目前支付寶中的余額寶等新興產 品均使用rocketmq。集群規模大概在50 台左右，單日處理消息上百億；性能非常好，可以大量堆 積消息在broker 中；支持多種消費，包括集群消費、廣播消費等。開發度較活躍，版本更新很快。 缺點： 沒有在 mq 核心中去實現JMS 等接口， |
性能怪獸Kafka
Kafka是LinkedIn開源的分布式發布-訂閱消息系統，目前歸屬於Apache定級項目。”Apache Kafka is publish-subscribe messaging rethought as a distributed commit log.”，官網首頁的一句話高度概括其職責。Kafka並沒有遵守JMS規范，他只用文件系統來管理消息的生命周期。Kafka的設計目標是：
（1）以時間復雜度為O(1)的方式提供消息持久化能力，即使對TB級以上數據也能保證常數時間復雜度的訪問性能。
（2）高吞吐率。即使在非常廉價的商用機器上也能做到單機支持每秒100K條以上消息的傳輸。
（3）支持Kafka Server間的消息分區，及分布式消費，同時保證每個Partition內的消息順序傳輸。
（4）同時支持離線數據處理和實時數據處理。
（5）Scale out：支持在線水平擴展。