MQ产品比较-ActiveMQ-RocketMQ

2019独角兽企业重金招聘Python工程师标准>>>

几种MQ产品说明：

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

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

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

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

 

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

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

针对消息中间件的选择可以从以下方面进行考虑：(主要对比ActiveMQ和RocketMQ)
优先级：我们的项目对此需求不是特别明显，RocketMQ需要新建一个特殊队列来接收优先级高的队列，无法实现从0-65535这种细粒度的控制，ActiveMQ可以精细控制
顺序：我们的消息总线中的消息应该都是无状态的，所以对消息的处理顺序没有严格的要求，如果有特殊要求的话可以在业务层进行控制，activeMQ无法保证严格的顺序，RocketMQ可以保证严格的消费顺序
持久化：都支持
稳定性：RoketMQ在稳定性上可能更值得信赖，支持多种集群方案，毕竟已经撑过几个双十一
消息过滤：ActiveMQ仅支持在客户端消费的时候进行判断是否是自己需要的消息，RocketMQ可以在broker端进行过滤，对于我们的消息总线，这里可以节省大量的网络传输是否会有消息重发造成的重复消费：RocketMQ可以保证，ActiveMQ无法保证
回溯消费：即重新将某一个时刻之前的消息重新消费一遍，我们对于这种需求应该很少，RocketMQ支持，ActiveMQ不支持（RocketMQ的队列是持久化到硬盘的，定期进行清除
事务：都支持（注意你选用的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 等接口，

 

阿里巴巴消息中间件

消息队列 MQ、Apache ActiveMQ、Apache Kafka、Apache RocketMQ、RabbitMQ 产品对比

消息队列秉持开放、共享的原则拥抱开源生态，无技术绑定。2016年阿里巴巴正式宣布将 MQ 内核引擎 RocketMQ 捐赠给 Apache 软件基金会；与此同时，全面融合 Kafka 生态，做到无缝迁移，打造更安全、更可靠、更易运维的 Kafka 企业级消息服务。

消息队列MQ：阿里内部产品名 MetaQ、Notify；开源社区产品名为 RocketMQ；产品多次在国内外获奖。

产品对比：

功能	MQ 消息队列	Apache RocketMQ （开源）	Apache ActiveMQ （开源）	Apache Kafka （开源）	RabbitMQ （开源）
安全防护	支持	不支持	支持	不支持	不支持
主子账号支持	支持	不支持	不支持	不支持	不支持
可靠性	- 同步刷盘  - 同步双写  - 超3份数据副本  - 99.99999999%	- 同步刷盘 - 异步刷盘	- 同步刷盘  - 异步刷盘	异步刷盘，丢数据概率高	同步刷盘
可用性	- 非常好，99.95% - Always Writable	好	好	好	好
横向扩展能力	- 支持平滑扩展 - 支持百万级 QPS	支持		支持	- 集群扩容依赖前端 - LVS 负载均衡调度
Low Latency	支持	不支持		不支持	不支持
消费模型	Push / Pull	Push / Pull	Push	Pull	Push / Pull
定时消息	支持（可精确到秒级）	支持（只支持18个固定 Level）	不支持	不支持	不支持
事务消息	支持	不支持	支持	不支持	不支持
全链路消息轨迹	支持	不支持	不支持	不支持	不支持
消息堆积能力	百亿级别 不影响性能	百亿级别 影响性能	影响性能	影响性能	影响性能
消息堆积查询	支持	支持		不支持	不支持
消息回溯	支持	支持	不支持	不支持	不支持
消息重试	支持	支持	支持	不支持	支持
死信队列	支持	支持	支持	不支持	支持
性能（常规）	非常好 百万级 QPS	非常好 十万级 QPS	非常好 百万级 QPS	非常好 百万级 QPS	一般 万级 QPS
性能（万级 Topic 场景）	非常好 百万级 QPS	非常好 十万级 QPS		低	低
性能（海量消息堆积场景）	非常好 百万级 QPS	非常好 十万级 QPS		低	低

转载于:https://my.oschina.net/javahongxi/blog/1529813