MQ选型对比RabbitMQ RocketMQ ActiveMQ Kafka

几种MQ产品说明：

     ZeroMQ :  扩展性好，开发比较灵活，采用C语言实现，实际上他只是一个socket库的重新封装，如果我们做为消息队列使用，需要开发大量的代码

    RabbitMQ :结合erlang语言本身的并发优势，性能较好，但是不利于做二次开发和维护

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

    Redis 做为一个基于内存的K-V数据库，其提供了消息订阅的服务，可以当作MQ来使用，目前应用案例较少，且不方便扩展

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

 

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

Kafka设计的初衷就是处理日志的，可以看做是一个日志系统，针对性很强，所以它并没有具备一个成熟MQ应该具备的特性.

针对消息中间件的选择可以从以下方面进行考虑：(主要对比ActiveMQ和RocketMQ)
     优先级：我们的项目对此需求不是特别明显，RocketMQ需要新建一个特殊队列来接收优先级高的队列，无法实现从0-65535这种细粒度的控制，ActiveMQ可以精细控制
        顺序：我们的消息总线中的消息应该都是无状态的，所以对消息的处理顺序没有严格的要求，如果有特殊要求的话可以在业务层进行控制，activeMQ无法保证严格的顺序，RocketMQ可以保证严格的消费顺序
    持久化：都支持
   稳定性：RoketMQ在稳定性上可能更值得信赖，支持多种集群方案，毕竟已经撑过几个双十一
  消息过滤：ActiveMQ仅支持在客户端消费的时候进行判断是否是自己需要的消息，RocketMQ可以在broker端进行过滤，对于我们的消息总线，这里可以节省大量的网络传输是否会有消息重发造成的重复消费：RocketMQ可以保证，ActiveMQ无法保证
  回溯消费：即重新将某一个时刻之前的消息重新消费一遍，我们对于这种需求应该很少，RocketMQ支持，ActiveMQ不支持（RocketMQ的队列是持久化到硬盘的，定期进行清除
          事务：都支持
  定时消费：RocketMQ支持
   消息堆积：就是当缓存消息的内存满了之后的解决方案，一种是丢弃策略，这种不会影响吞吐量，还有一种就是将消息持久化到磁盘，这种会影响吞吐量，在评估影响程度上，RocketMQ的成绩稍微好一点
  客户端不在线：RocketMQ可以在客户端上线后继续将未消费的消息推送到客户端
      目前比较活跃的几种MQ中间件产品的对比如下：（仅统计开源的项目）

 

 

	ActiveMQ	RabbitMQ	RocketMq	ZeroMQ
关注度	高	高	中	中
成熟度	成熟	成熟	比较成熟	不成熟
所属社区/公司	Apache	Mozilla Public License	Alibaba
社区活跃度	高	高	中	低
文档	多	多	中	中
特点	功能齐全，被大量开源项目使用	由于Erlang 语言的并发能力，性能很好	各个环节分布式扩展设计，主从 HA；支持上万个队列；多种消费模式；性能很好	低延时，高性能，最高 43万条消息每秒
授权方式	开源	开源	开源	开源
开发语言	Java	Erlang	Java	C
支持的协议	OpenWire、 STOMP、 REST、XMPP、 AMQP	AMQP	自己定义的一 套(社区提供 JMS--不成熟)	TCP、UDP
客户端支持语言	Java、C、 C++、 Python、 PHP、 Perl、.net 等	Java、C、 C++、 Python、 PHP、Perl 等	Java   C++（不成熟）	python、 java、 php、.net 等
持久化	内存、文件、数据库	内存、文件	磁盘文件	在消息发送端保存
事务	支持	不支持	支持	不支持
集群	支持	支持	支持	不支持
负载均衡	支持	支持	支持	不支持
管理界面	一般	好	无社区有 web console   实现	无
部署方式	独立、嵌入	独立	独立	独立
评价	优点：    成熟的产品，已经在很多公司得到应用（非大规模场景）。有较多的文档。各种协议支持较好，有多重语言的成熟的客户端； 缺点： 根据其他用户反馈，会出莫名其妙的问题，切会丢失消息。 其重心放到activemq6.0 产品—apollo 上去了，目前社区不活跃，且对 5.x 维护较少； Activemq 不适合用于上千个队列的应用场景	优点：   由于erlang语言的特性，mq 性能较好；管理界面较丰富，在互联网公司也有较大规模的应用；支持amqp系诶，有多中语言且支持 amqp 的客户端可用   缺点：   erlang语言难度较 大。集群不支持动态扩展。	优点：    模型简单，接口易用（JMS   的接口很多场合并不太实用）。在阿里大规模应用。目前支付宝中的余额宝等新兴产 品均使用rocketmq。集群规模大概在50 台左右，单日处理消息上百亿；性能非常好，可以大量堆 积消息在broker   中；支持多种消费，包括集群消费、广播消费等。开发度较活跃，版本更新很快。  缺点：   没有在 mq 核心中去实现JMS 等接口，

 

 

性能怪兽Kafka

Kafka是LinkedIn开源的分布式发布-订阅消息系统，目前归属于Apache定级项目。”Apache Kafka is publish-subscribe messaging rethought as a distributed commit log.”，官网首页的一句话高度概括其职责。Kafka并没有遵守JMS规范，他只用文件系统来管理消息的生命周期。Kafka的设计目标是：

（1）以时间复杂度为O(1)的方式提供消息持久化能力，即使对TB级以上数据也能保证常数时间复杂度的访问性能。

（2）高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条以上消息的传输。

（3）支持Kafka Server间的消息分区，及分布式消费，同时保证每个Partition内的消息顺序传输。

（4）同时支持离线数据处理和实时数据处理。

（5）Scale out：支持在线水平扩展。