Java rocketmq 和ribbmq区别 rocketmq和rabbitmq选型

转载

mob64ca13feda16 2024-05-12 20:03:39

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

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

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对比

3.1 对比1

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

Java rocketmq 和ribbmq区别 rocketmq和rabbitmq选型_持久化

3.2 对比2

	Kafka	ActiveMQ	RabbitMQ	RocketMq	ZeroMQ
单机吞吐量	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 功能较为完善，基于分布式，扩展性好	支持将消息队列的功能集成到系统进程中。
关注度	高	高	高	中	中
成熟度	成熟	成熟	成熟	比较成熟	不成熟
所属社区/公司	Apache	Apache	Mozilla Public License	Alibaba
社区活跃度	高	高	高	中	低
文档	多	多	多	中	中
特点	严格的消息顺序(partition内)、丰富的消息拉取模型、高效订阅者水平扩展、实时的消息订阅、亿级的消息堆积能力。	功能齐全，被大量开源项目使用	由于Erlang 语言的并发能力，性能很好	各个环节分布式扩展设计，主从 HA；支持上万个队列；多种消费模式；性能很好	低延时，高性能，最高 43万条消息每秒
授权方式	开源	开源	开源	开源	开源
开发语言	支持多语言，Java优先	Java	Erlang	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 等接口，

四、优缺点总结

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