当前位置:   article > 正文

MQ选型对比RabbitMQ RocketMQ ActiveMQ Kafka_rabbitmq对比

rabbitmq对比

参考地址:MQ选型对比RabbitMQ RocketMQ ActiveMQ

ActiveMQ、RabbitMQ、RocketMQ、Kafka四种消息中间件分析介绍

RocketMQ介绍与应用场景_流楚丶格念的博客-CSDN博客_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端进行消息过滤.

二、优缺点对比 

针对消息中间件的选择可以从以下方面进行考虑:(主要对比ActiveMQRocketMQ)

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

三、开源MQ对比

3.1 对比1

目前比较活跃的几种MQ中间件产品的对比如下:(仅统计开源的项目)

这里写图片描述

3.2 对比2

Kafka    ActiveMQRabbitMQRocketMqZeroMQ
单机吞吐量10 万级,高吞吐,一般配合大数据类的系统来进行实时数据计算、日志采集等场景万级,比RocketMQ、
Kafka 低一个数量级

万级,比RocketMQ、
Kafka 低一个数量级

10 万级,支撑高吞吐

100万级别,最早设计用于股票实时交易系统
topic 数量对吞
吐量的影响
topic 从几十到几百个时候,吞吐量会大幅度下降,在同等机器下, Kafka 尽量保证 topic 数量不要过多,如果要支撑大规模的 topic,需要增加更多的机器资源topic 可以达到几百/几千的级别,吞吐量会有较小幅度的下降,这是RocketMQ 的一大优势,在同等机器下,可以支撑大量的 topic
时效性延迟在 ms 级以内ms 级微秒级,这是RabbitMQ 的一大特点,延迟最低ms 级微妙级别/毫秒级别延迟
可用性非常高,分布式,一个数据多个副本,少数机器宕机,不会丢失数据,不会导致不可用高,基于主从架构实现高可用同ActiveMQ非常高,分布式架构不是一个独立的服务,要嵌套到自己的程序里面去
消息可靠性经过参数优化配置,可以做到 0 丢失有较低的概率丢失数据基本不丢失经过参数优化配置,可以做到 0 丢失
功能支持功能较为简单,主要支持简单的 MQ 功能,在大数据领域的实时计算以及日志采集被大规模使用MQ领域的功能及其完备基于 erlang 开发,并发能力很强,性能极好,延时很低MQ 功能较为完善,基于分布式,扩展性好支持将消息队列的功能集成到系统进程中。
关注度  
成熟度  成熟成熟成熟比较成熟不成熟
所属社区/公司ApacheApache Mozilla
Public
License
Alibaba  
社区活跃度  
文档  
特点  严格的消息顺序(partition内)、丰富的消息拉取模型、高效订阅者水平扩展、实时的消息订阅、亿级的消息堆积能力。功能齐全,被大量开源项目使用由于Erlang 语言的并发能力,性能很好   各个环节分布式扩展设计,主从 HA;支持上万个队列;多种消费模式;性能很好低延时,高性能,最高 43万条消息每秒  
授权方式  开源开源开源开源开源
开发语言  支持多语言,Java优先JavaErlang  Java  C
支持的协议  Protocol Buffer(基于TCP层的协议)OpenWire、
STOMP、
REST、XMPP、
AMQP
AMQP  自己定义的一
套(社区提供
JMS--不成熟)
TCP、UDP
客户端支持语言  java,python、c++、php等Java、C、
C++、
Python、
PHP、
Perl、.net 等  
Java、C、
C++、
Python、 PHP、Perl 等
Java  
C++(不成熟)  
 
python、 java、 php、.net 等
持久化  内存、文件内存、文件、数据库内存、文件磁盘文件在消息发送端保存
事务  支持支持支持支持支持
集群  支持支持支持支持不支持
负载均衡支持支持支持支持不支持
管理界面  可使用AKMQ第三方产品一般无社区有 web
console   实现
部署方式  独立独立、嵌入独立独立独立
评价  Apache软件基金会开发、开源、高吞吐量,社区活跃度高,商业版本为Confluent.优点:
   成熟的产品,已经在很多公司得到应用(非大规模场景)。有较多的文档。各种协议支持较好,有多重语言的成熟的客户端;
缺点:
根据其他用户反馈,会出莫名其妙的问题,切会丢失消息。 其重心放到activemq6.0 产品—apollo 上去了,目前社区不活跃,且对 5.x 维护较少;
Activemq 不适合用于上千个队列的应用场景

  由于erlang语言的特性,mq 性能较好;管理界面较丰富,在互联网公司也有较大规模的应用;支持amqp系诶,有多中语言且支持 amqp 的客户端可用。开源、稳定、社区活跃度高。
 
缺点:
  erlang语言难度较大。集群不支持动态扩展。

优点:
   模型简单,接口易用(JMS   的接口很多场合并不太实用)。在阿里大规模应用。目前支付宝中的余额宝等新兴产
品均使用rocketmq。集群规模大概在50 台左右,单日处理消息上百亿;性能非常好,可以大量堆积消息在broker   中;支持多种消费,包括集群消费、广播消费等。开发度较活跃,版本更新很快。
 缺点:
  没有在 mq 核心中去实现JMS 等接口,

四、优缺点总结

消息队列优点缺点
RabbitMQ1.支持AMQP协议
2.基于erlang语言开发 ,高并发性能较好
3.工作模式较为灵活
4.支持延迟消息
5.提供较为友好的后台管理页面
6.单机部署 ,1~2WTPS
1.不支持水平扩容
2.消息吞吐量三者最差
3.当产生消息堆积 ,性能下降明显
4.消息重发机制需要手动设置
5.不支持消息重复消费
RocketMQ1.高可用 ,高吞吐量 ,海量消息堆积 ,低延迟性能上 ,都表现出色
2.api与架构设计更加贴切业务场景
3.支持顺序消息
4.支持事务消息
5.支持消息过滤
6.支持重复消费
7.支持延迟消息
8.支持消息跟踪
9.天然支持集群、负载均衡
10.支持指定次数和时间间隔的失败消息重发
11.单机部署 ,5~10WTPS
1.生态圈相较Kafka有所不如
2.消息吞吐量与消息堆积能力也不如Kafka
3.不支持主从自动切换
4.只支持Java
Kafka1.高可用 ,高吞吐量 ,低延迟性能上 ,都表现出色
2.使用人数多 ,技术生态圈完善
3.支持顺序消息
4.支持多种客户端
5.支持重复消费
1.依赖分区 ,消费者数量受限于分区数
2.单机消息过多时 ,性能下降明显
3.不支持事务消息
4.不支持指定次数和时间间隔的失败消息重发

实现如下功能时,选用RocketMQ是一个不错的选择 :

  1. 支持事务消息
  2. 支持延迟消息
  3. 天然支持集群、负载均衡
  4. 支持指定次数和时间间隔的失败消息重发 详细的技术选型对比如下 :

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/从前慢现在也慢/article/detail/970824
推荐阅读
相关标签
  

闽ICP备14008679号