幾種MQ消息隊列對比與消息隊列之間的通訊問題

消息隊列	開發語言	協議支持	設計模式	持久化支持	事務支持	負載均衡支持	功能特色	缺點
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。一、Master Slave集羣方式：Master提供服務，Slave實時備份Master的數據，以保證消息的可靠性。當Master失效時，Slave自動升級爲Master，客戶端自動鏈接到Slave；二、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相結合的模式。