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