MQ产品比较-ActiveMQ-RocketMQ

时间:2022-06-10 22:49:53

几种MQ产品说明:

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

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

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

Redis 做为一个基于内存的K-V数据库,其提供了消息订阅的服务,可以当作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可以在客户端上线后继续将未消费的消息推送到客户端
      目前比较活跃的几种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 等接口,