| 消息隊列 | 開發語言 | 協議支持 | 設計模式 | 持久化支持 | 事務支持 | 負載均衡支持 | 功能特點 | 缺點 |
| RabbitMQ | Erlang | AMQP，XMPP，SMTP，STOMP | 代理(Broker)模式（消息在發送給客戶端時先在中心隊列排隊） | 支持持久化到文件 | 不支持 | 支持 | 性能較好；管理界面較豐富；在互聯網公司有較大規模的應用； 設計的核心是保證消息正確遞交（認為消費者是一直處於活動狀態去消費消息的）， 因此設計的比較重，需要記錄很多狀態 |
雖然產品開源，但Erlang語言應用不夠普遍； 集群不支持動態擴展 |
| ZeroMQ | C++ | ZeroMQ是一個並發框架做的socket庫 （是一個傳輸層API庫），並不是真正的消息隊列/消息中間件 |
點對點模式，通過引用ZeroMQ程序庫， 在應用之間發送消息，任何應用程序節點都可作為一個MQ |
不支持 | 不支持 | 不支持 | 低延時，高性能，最高每秒43萬條消息 | 非持久性隊列，宕機后數據將會丟失 |
| ActiveMQ | Java | OpenWire，Stomp REST，WS Notification，XMPP，AMQP，JMS | 支持代理模式，也支持點對點模式 | 支持持久化到文件或數據庫 | 支持 | 支持 | 成熟的產品，在很多公司得到應用；有較多的文檔；各種協議支持較好， 有多種語言的成熟的客戶端；完全支持JMS1.1和J2EE 1.4規范 （持久化，XA消息，事務)；支持Spring，可以很容易內嵌到使用Spring的系統里 |
根據其他用戶反饋，會出現丟失消息的問題； 其重心已放到下一代產品Apollo，目前社區不夠活躍，對 5.x 維護較少 |
關於消息隊列之間的通信問題，可以通過采用ActiveMQ的Broker Cluster集群方式實現，ActiveMQ的集群方式主要由兩種：Master Slave和Broker Cluster。
1、Master Slave集群方式：Master提供服務，Slave實時備份Master的數據，以保證消息的可靠性。當Master失效時，Slave自動升級為Master，客戶端自動連接到Slave；
2、Broker Cluster集群方式：在多個ActiveMQ實例之間進行消息的路由。如：生產者應用連接一個ActiveMQ實例，稱為MQ1，所有消息都由該實例提供。兩個消費者應用分別連接另外兩個ActiveMQ實例，分別為MQ2和MQ3，兩個消息消費者需要消費MQ1上的消息，但它們連接的都不是MQ1，可以通過該集群方式方式把MQ1上的消息路由到MQ2和MQ3。
Broker Cluster的集群分為Static Discovery和Dynamic Discovery兩種。
（1）Static Discovery 方式：通過硬編碼的方式使用所有已知ActiveMQ實例節點的URI地址。為了保證消費者不因某個節點的失效而導致不能消費消息，在消費者應用中需要配置所有節點的URI。這種靜態路由存在的原因可能是因為靜態處理的方式使路由速度更快。
（2）Dynamic Discover 方式:在配置ActiveMQ實例時，不需要知道所有其它實例的URI地址，只需在所有實例的配置文件中進行相應設置，就可以實現消息在所有ActiveMQ實例之間進行路由。
Master Slave模式不支持負載均衡，但可以通過消息的實時備份或共享，保證消息服務的可靠性；Broker Cluster模式支持負載均衡，可以提高消息的消費能力，但不能保證消息的可靠性。
所以為了支持負載均衡，同時又保證消息的可靠性，可以采用Msater Slave與Broker Cluster相結合的模式。