MQ产品比较-ActiveMQ-RocketMQ

几种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 等
持久化 内存、文件、数据库 内存、文件 磁盘文件 在消息发送端保存
事务 支持 支持 支持 不支持
集群 支持 支持 支持 不支持
负载均衡 支持 支持 支持 不支持
管理界面 一般
部署方式 独立、嵌入 独立 独立 独立
评价 优点:成熟的产品,已经在很多公司得到应用(非大规模场景)。有较多的文档。各种协议支持较好,有多重语言的成熟的客户端;缺点:根据其他用户反馈,会出莫名其妙的问题,切会丢失消息。 其重心放到activemq6.0 产品—apollo 上去了,目前社区不活跃,且对 5.x 维护较少;Activemq 不适合用于上千个队列的应用场景 优点: 由于erlang语言的特性,mq 性能较好;管理界面较丰富,在互联网公司也有较大规模的应用;支持amqp系诶,有多中语言且支持 amqp 的客户端可用缺点:erlang语言难度较大。集群不支持动态扩展。 优点:模型简单,接口易用(JMS 的接口很多场合并不太实用)。在阿里大规模应用。目前支付宝中的余额宝等新兴产品均使用rocketmq。集群规模大概在50 台左右,单日处理消息上百亿;性能非常好,可以大量堆积消息在broker 中;支持多种消费,包括集群消费、广播消费等。开发度较活跃,版本更新很快。缺点:没有在 mq 核心中去实现JMS 等接口
版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/dreamsunday/article/details/52223288