MQ大对比

基本信息对比  

主要关注前三个(标红) 

ActiveMQ 

RabbitMQ 

RocketMq 

Joram

HornetQ

OpenMQ

MuleMQ

SonicMQ

ZeroMQ

关注度 

成熟度 

成熟

成熟

比较成熟

比较成熟

比较成熟

比较成熟

新产品无成功案例

成熟

不成熟

所属社区/公司 

Apache

 Mozilla

Public

License

Alibaba

OW2

Jboss

Sun

Mule

Progress

  

社区活跃度 

文档 

特点 

功能齐全,被大量开源项目使用

由于Erlang 语言的并发能力,性能很好

 各个环节分布式扩展设计,主从 HA;支持上万个队列;多种消费模式;性能很好

  

在 Linux 平台上直接调用操作系统的 AIO,性能得到很大的提升

  

性能非常

好,与

MuleESB 无缝整合

性能优越的商业 MQ

低延时,高性能,最高 43万条消息每秒

授权方式 

开源

开源

开源

开源

开源

开源

商业

商业

开源

开发语言 

Java

Erlang

Java

Java

Java

Java

Java

Java

C

支持的协议 

OpenWire、

STOMP、

REST、XMPP、

AMQP

AMQP

自己定义的一

套(社区提供

JMS--不成熟)

JMS

JMS

JMS

JMS

JMS

TCP、UDP

客户端支持语言 

Java、C、

C++、

Python、

PHP、

Perl、.net 等

Java、C、

C++、

Python、 PHP、Perl 等

Java

C++(不成熟)

Java

Java

Java

Java

Java、C、

C++、.net

python、 java、 php、.net 等

持久化 

内存、文件、数据库

内存、文件

磁盘文件

内存、文件

内存、文件

内存、文件

内存、文件

内存、文件、数据库

在消息发送端保存

事务 

支持

不支持

支持

支持

支持

支持

支持

支持

不支持

集群 

支持

支持

支持

支持

支持

支持

支持

支持

不支持

负载均衡

支持

支持

支持

支持

支持

支持

支持

支持

不支持

管理界面 

一般

无社区有 web

console 实现

一般

一般

一般

部署方式 

独立、嵌入

独立

独立

独立、嵌入

独立、嵌入

独立、嵌入

独立

独立

独立

评价 

优点

   成熟的产品,已经在很多公司得到应用(非大规模场景)。有较多的文档。各种协议支持较好,有多重语言的成熟的客户端;缺点

根据其他用户反馈,会出莫名其妙的问题,切会丢

失消息。

其重心放到

activemq6.0 产品—apollo 上去了,目前社区不活跃,且对 5.x 维护较少;

Activemq 不适合用于上千个队列的应用场景

优点:   由于

erlang语言的特性,mq 性能较好;管理界面较丰富,在互联网公司也有较大规模的应用;支持amqp系诶,有多中语言且支持 amqp 的客

户端可用

缺点:

  erlang语言难度较

大。集群不支持动态扩展。

优点

   模型简单,接口易用(JMS 的接口很多场合并不太实

用)。在阿里大规模应用。目前支付宝中的余额宝等新兴产

品均使用

rocketmq。集群规模大概在

50 台左右,单日处理消息上

百亿;性能非常好,可以大量堆

积消息在

broker 中;支持多种消费,包括集群消费、广播消费等。开发度较活跃,版本

更新很快。

缺点

  产品较新,文档比较缺乏。

没有在 mq 核心中去实现

JMS 等接口,对

已有系统而言不能兼容。

  阿里内部还有一套未开源

的 MQ API,这一层API可以将上层应用和下层 MQ 的实现解耦(阿里内部有多个mq的实现,如 notify、

metaq1.x, metaq2.x,

rocketmq 等),使得下面mq可以很方便的进行切换和升级而对应用无任

何影响,目前这

一套东西未开源

结论 

在传统的 MQ 中rabbitmq 的性能表现最好,kafka 的性能优于 rabbitmq;

传统 MQ 对比  

Kafka vs rabbitmq  

结论在 kafka 和 rabbitmq 的对比中,kafka 的性能表现较好。

rabbitmq

kafka

rocketmq

设计初衷

更多工作是保证消息递交;认为 consumer 是一直处于 alive 状态去消费消息的; broker 设计的比较重,需要记录很多状态;

充分考虑消息堆积因素,认为 consumer 不一定处于 alive 状态;

考虑各个角色的分布式;为追求吞吐量设计;

broker 设计较轻,不保存 consumer 的消费状态

同 kafka;

且考虑了事务特性;

路由特性

提供了丰富的 routing,实现了 amqp 的 exchange、

binding、queuing 等 model, queue、topic 等 routing 都

支持;

topic routing only

topic routing only

集群特性

对应用透明的集群式实现;

虽然是集群式的实现,但是集群对 producer 并不是完全透明,producer 需要确认消息发送到哪一个

同 kafka

partition;同时也利用这一点实现了消息的顺序递交特性(partition 内的消息是顺序的);

HA

通过 mirror queue 来支持

(master/slave)

master 提供服务,slave 仅备份

通过 replica 来支持 queue 的 master/slave 的可以自动切换(当 master 宕掉后)

支持,但需要人工切换 master 和 slave 的角色;

消息处理量

消息量~=20k/sec;

消息量>100k/sec

消息量>100k/sec

队列数目

<1000

支持上万队列

支持上万队列

顺序投递

不支持

支持

支持

事务性

不支持

不支持

支持

rocketmq 简介

 rocketmq 的前身为 metaq,metaq 的第一个版本是可以看成是 linkedin 的 kafka(scala)的 java 版本,并对其增加了事务的支持。rocketmq 为 metaq3.0,相比于原始 kafka,其擅长点出了原始的 log collecting 之外,还增加诸如 HA、事务等特性,使得从功能点上讲,可以替代传统大部分 MQ。 rocketmq 已经在阿里开始大规模应用,并且会逐渐在阿里取代 notify,meta 2.x 以前的所有队列。在这里用 kafka 和其他队列进行对比,rocketmq 的性能比 kafka 还要好一些。

### 消息队列(MQ对比分析 #### 性能方面 不同消息队列在性能上的表现差异显著。例如,Kafka因其分布式架构设计和高吞吐量的特点,在处理海量数据时表现出色[^3]。相比之下,RabbitMQ虽然提供了更高的稳定性和可靠性,但在面对量的消息堆积时,其性能可能会有所下降。 #### 功能特点 每种消息队列的功能侧重点各不相同。RabbitMQ以其丰富的功能集著称,支持复杂的路由规则以及多种协议,非常适合需要灵活消息传递的应用场景[^5]。然而,对于某些特定需求如事务支持,RocketMQ则更具优势,因为它针对可靠传输及事务性进行了专门优化。而ActiveMQ尽管历史悠久,但由于缺乏规模生产环境下的验证,加上社区活跃度较低,逐渐失去了竞争力。 #### 适用场景 选择合适的MQ取决于具体的应用场景。当涉及到广播通知或者实现系统的解耦时,使用消息队列是非常有效的解决方案之一[^4]。如果项目更注重最终的一致性而非即时性强一致性的保障,则多数标准的消息队列都能够胜任这项工作;但如果业务逻辑特别强调结果反馈的重要性,那么RPC可能比传统意义上的消息队列更适合该情况。 以下是几种常见MQ及其主要优劣点总结: | 名字 | 主要优点 | 缺点 | |------------|----------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------| | **Kafka** | 极高的吞吐率、良好的扩展能力和持久化的日志存储机制 | 不完全满足通用型消息中间件的需求,缺少部分基础特性 | | **RabbitMQ** | 支持多语言客户端接入、复杂的消息路由策略 | Erlang开发门槛较高,不适合所有开发者深入学习 | | **RocketMQ** | 出色的规模集群管理和事务消息的支持 | 社区相对较小,生态系统还不够完善 | | **ActiveMQ** | 成熟的产品线,兼容性强 | 处理流量的能力不足 | ```python # 示例代码展示如何连接到 RabbitMQ 进行基本操作 import pika connection = pika.BlockingConnection(pika.ConnectionParameters('localhost')) channel = connection.channel() channel.queue_declare(queue='hello') def callback(ch, method, properties, body): print(f"Received {body}") channel.basic_consume(queue='hello', on_message_callback=callback, auto_ack=True) print('Waiting for messages.') channel.start_consuming() ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

小小哭包

创作不易,给作者加个鸡腿吧

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值