基本信息对比
主要关注前三个(标红)
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 还要好一些。