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