消息队列篇—常用消息队列MQ产品介绍及对比

MQ作为中间件，消息队列是分布式应用间交换信息的重要组件。消息队列可存储在内存和磁盘上，队列可以存储消息直至它们被应用程序接收。通过消息队列在应用程序不知道彼此位置的情况下可以独立处理信息或在处理消息前不需要等待接收该消息。所有消息队列可以解决应用解耦、异步消息等问题，是实现高性能、高可用、可伸缩和一致性架构中不可或缺的一环。

 

目前业界有很多MQ产品，小编作如下对比：

 

ZeroMQ：号称最快的消息队列系统，尤其针对大吞吐量的需求场景。扩展性好，开发比较灵活，采用C语言实现，实际上只是一个socket库的重新封装，如果做为消息队列使用，需要开发大量的代码。ZeroMQ仅提供非持久性的队列，也就是说如果down机，数据将会丢失。其中，Twitter的Storm中使用ZeroMQ作为数据流的传输。

 

RabbitMQ：结合erlang语言本身的并发优势，支持很多的协议：AMQP，XMPP, SMTP, STOMP，也正是如此，使的它变的非常重量级，更适合于企业级的开发。性能较好，但是不利于做二次开发和维护。

 

ActiveMQ: 历史悠久的开源项目，是Apache下的一个子项目。已经在很多产品中得到应用，实现了JMS1.1规范，可以和spring-jms轻松融合，实现了多种协议，不够轻巧（源代码比RocketMQ多），支持持久化到数据库，对队列数较多的情况支持不好，不过我们的项目中并不会建很多的队列。

 

Redis 做为一个基于内存的K-V数据库，其提供了消息订阅的服务，可以当作MQ来使用，目前应用案例较少，且不方便扩展。对于RabbitMQ和Redis的入队和出队操作，各执行100万次，每10万次记录一次执行时间。测试数据分为 128Bytes、512Bytes、1K和10K四个不同大小的数据。实验表明：入队时，当数据比较小时Redis的性能要高于RabbitMQ，而如 果数据大小超过了

 

10K，Redis则慢的无法忍受；出队时，无论数据大小，Redis都表现出非常好的性能，而RabbitMQ的出队性能则远低于 Redis。

RocketMQ: 阿里巴巴的MQ中间件，在其多个产品下使用，并能够撑住双十一的大流量，他并没有实现JMS规范，使用起来很简单。部署由一个 命名服务（nameserver）和一个代理（broker）组成，nameserver和broker以及producer都支持集群，队列的容量受机器硬盘的限制，队列满后可以支持持久化到硬盘（也可以自己适配代码，将其持久化到NOSQL数据库中），队列满后会影响吞吐量，可以采用主备来保证稳定性，支持回溯消费，可以在broker端进行消息过滤。

 

Jafka/Kafka：Kafka是Apache下的一个子项目，是一个高性能跨语言分布式Publish/Subscribe消息队列系统，而Jafka是在Kafka 之上孵化而来的，即Kafka的一个升级版。具有以下特性：快速持久化，可以在O(1)的系统开销下进行消息持久化；高吞吐，在一台普通的服务器上既可以 达到10W/s的吞吐速率；完全的分布式系统，Broker、Producer、Consumer都原生自动支持分布式，自动实现复杂均衡；支持 Hadoop数据并行加载，对于像Hadoop的一样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。Kafka通过 Hadoop的并行加载机制来统一了在线和离线的消息处理，这一点也是本课题所研究系统所看重的。Apache Kafka相对于ActiveMQ是一个非常轻量级的消息系统，除了性能非常好之外，还是一个工作良好的分布式系统。

 

针对消息中间件的选择可以从以下方面进行考虑：（主要针对ActiveMQ和RocketMQ对比作为案例）

优先级：我们的项目对此需求不是特别明显，RocketMQ需要新建一个特殊队列来接收优先级高的队列，无法实现从0-65535这种细粒度的控制，ActiveMQ可以精细控制

顺序：我们的消息总线中的消息应该都是无状态的，所以对消息的处理顺序没有严格的要求，如果有特殊要求的话可以在业务层进行控制，activeMQ无法保证严格的顺序，RocketMQ可以保证严格的消费顺序

持久化：都支持

稳定性：RoketMQ在稳定性上可能更值得信赖，支持多种集群方案，毕竟已经撑过几个双十一

消息过滤：ActiveMQ仅支持在客户端消费的时候进行判断是否是自己需要的消息，RocketMQ可以在broker端进行过滤，对于我们的消息总线，这里可以节省大量的网络传输是否会有消息重发造成的重复消费：RocketMQ可以保证，ActiveMQ无法保证

回溯消费：即重新将某一个时刻之前的消息重新消费一遍，我们对于这种需求应该很少，RocketMQ支持，ActiveMQ不支持（RocketMQ的队列是持久化到硬盘的，定期进行清除

事务：都支持

定时消费：RocketMQ支持

消息堆积：就是当缓存消息的内存满了之后的解决方案，一种是丢弃策略，这种不会影响吞吐量，还有一种就是将消息持久化到磁盘，这种会影响吞吐量，在评估影响程度上，RocketMQ的成绩稍微好一点

客户端不在线：RocketMQ可以在客户端上线后继续将未消费的消息推送到客户端