几种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。

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相结合的模式。