当前位置:首页 >> 计算机软件及应用 >>

各种消息队列对比


消息队列中间件调研文档
MQ 对比
基本信息对比
主要关注前三个(标红)
ActiveMQ 关注度 成熟度 所属社 区/公 司 社区活 跃度 文档 高 多 Apache 高 成熟 RabbitMQ 高 成熟 Mozilla Public License 高 多 中 中 各个环节分布 功能齐全,被 特点 大量开源项目 使用 由于 Erlang 语言的并发 能力,性能 很好 式扩展设计,主 从 HA;支持上 万个队列;多种 消费模式;性能 很好 授权方 式 开发语 言 支持的 协议 开源 Java OpenWire、 STOMP、 REST、 XMPP、 AMQP Java、C、 客户端 支持语 言 C++、 Python、 PHP、 Perl、.net 等 持久化 事务 集群 负载均 内存、文件、 数据库 支持 支持 支持 Java、C、 C++、 Python、 PHP、Perl 等 内存、文件 不支持 支持 支持 磁盘文件 支持 支持 支持 内存、文 件 支持 支持 支持 内存、文 件 支持 支持 支持 内存、文 件 支持 支持 支持 内存、文 件 支持 支持 支持 数据库 支持 支持 支持 Java C++(不成熟) Java Java Java Java Java、C、 C++、.net AMQP 开源 Erlang 开源 Java 自己定义的一 套(社区提供 JMS--不成熟) python、 java、 php、.net 等 内存、文件、 在消息发送 端保存 不支持 不支持 不支持 JMS JMS JMS JMS JMS TCP、UDP 开源 Java 中 多 中 中 在 Linux 平台上直 接调用操 作系统的 AIO,性 能得到很 大的提升 开源 Java 开源 Java 商业 Java 商业 Java 开源 C 性能非常 好,与 MuleESB 无缝整合 性能优越的 商业 MQ 低延时,高 性能,最高 43 万条消息 每秒 低 中 高 少 低 少 低 中 Alibaba OW2 Jboss Sun Mule Progress RocketMq 中 比较成熟 Joram 中 比较成熟 HornetQ 中 比较成熟 OpenMQ 中 比较成熟 MuleMQ 低 新产品无 成功案例 SonicMQ 低 成熟 ZeroMQ 中 不成熟

作者 何鹏

关注分布式存储与计算相关框架, 包括 Hadoop、 YARN、 HBase、 Storm、 Spark、 MQ 等

peng.he.ia@gmail.com

衡 管理界 面 部署方 式 无 一般 好 社区有 web console 实现 独立、嵌入 独立 独立 优点: 模型简单, 接口易用(JMS 的接口很多场 合并不太实 用)。在阿里大 优点: 成熟的产 品,已经在很 多公司得到应 用(非大规模 场景)。有较 多的文档。各 种协议支持较 好,有多重语 言的成熟的客 户端; 缺点: 根据其他 评价 用户反馈,会 出莫名其妙的 问题,切会丢 失消息。 其重心放到 activemq6.0 产品—apollo 上去了,目前 社区不活跃, 且对 5.x 维护 较少; Activemq 不 适合用于上千 个队列的应用 场景 缺点: erlang 语 言难度较 大。集群不 支持动态扩 展。 优点: 由于 erlang 语言 的特性, mq 性能较好; 管理界面较 丰富,在互 联网公司也 有较大规模 的应用;支 持 amqp 系 诶,有多中 语言且支持 amqp 的客 户端可用 规模应用。目前 支付宝中的余 额宝等新兴产 品均使用 rocketmq。集 群规模大概在 50 台左右,单 日处理消息上 百亿;性能非常 好,可以大量堆 积消息在 broker 中;支 持多种消费,包 括集群消费、广 播消费等。开发 度较活跃,版本 更新很快。 缺点: 产品较新,文 档比较缺乏。 没有在 mq 核心中去实现 JMS 等接口, 对 已有系统而言 不能兼容。 阿里内部还 有一套未开源 的 MQ API,这 一层 API 可以将 上层应用和下 层 MQ 的实现 解耦(阿里内部 有多个 mq 的实 现,如 notify、 作者 何鹏 关注分布式存储与计算相关框架, 包括 Hadoop、 YARN、 HBase、 Storm、 Spark、 MQ 等 peng.he.ia@gmail.com 独立、嵌 入 独立、嵌 入 独立、嵌 入 独立 独立 独立 一般 无 一般 一般 好 无

metaq1.x, metaq2.x, rocketmq 等) , 使得下面 mq 可 以很方便的进 行切换和升级 而对应用无任 何影响,目前这 一套东西未开 源

支持的 Protocols 对比
The following table lists the supported protocols of each broker. ActiveMQ RabbitMQ AMQP MQTT OpenWire REST STOMP STOMP over Websockets XMPP Over Gateway 1.0 0-8, 0-9, 0-9-1 RocketMQ HornetQ announced Qpid 1.0 ZeroMQ -

Client Interfaces 对比
Access to a message broker is not only reserved for Java applications. For many brokers there are client APIs in different programming languages. It is even common for client and broker to use different platforms, eg when a Java application accesses an Erlang written RabbitMQ broker.Since AMQP has standardized the protocol on the "cable level", it is even possible to connect the AMQP client library of a broker of another broker. For this to work the AMQP versions have to match because each version of the protocol are not compatible.Through the STOMP protocol different client platforms can be connected to a broker. STOMP is favorited to access a broker with scripting languages such as Perl, PHP and Ruby. ActiveMQ C C++ Erlang Haskell Java JMS
作者 何鹏

RabbitMQ

RocketMQ -

HornetQ -

Qpid

ZeroQ

-

-

peng.he.ia@gmail.com

关注分布式存储与计算相关框架, 包括 Hadoop、 YARN、 HBase、 Storm、 Spark、 MQ 等

ActiveMQ Java proprietary .NET Objective-C Perl PHP Python Ruby -

RabbitMQ

RocketMQ -

HornetQ

Qpid -

ZeroQ

-

-

-

mq benchmark[
结论

文献 1]

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

传统 MQ 对比
场景设计:
? ? ? ?

Scenario A: Enqueuing 20,000 messages of 1024 bytes each, then dequeuing them afterwards. Scenario B: Enqueuing and dequeuing simultaneously 20,000 messages of1024 bytes each. Scenario C: Enqueuing and dequeuing simultaneously 200,000 messages of32 bytes each. Scenario D: Enqueuing and dequeuing simultaneously 200 messages of32768 bytes each.

Scenario A

作者 何鹏

关注分布式存储与计算相关框架, 包括 Hadoop、 YARN、 HBase、 Storm、 Spark、 MQ 等

peng.he.ia@gmail.com

Scenario B

Scenario C

作者 何鹏

关注分布式存储与计算相关框架, 包括 Hadoop、 YARN、 HBase、 Storm、 Spark、 MQ 等

peng.he.ia@gmail.com

Scenario D

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

作者 何鹏

关注分布式存储与计算相关框架, 包括 Hadoop、 YARN、 HBase、 Storm、 Spark、 MQ 等

peng.he.ia@gmail.com

简介
rocketmq 的前身为 metaq,metaq 的第一个版本是可以看成是 linkedin 的 kafka(scala)的 java 版本,并对其增 加了事务的支持。rocketmq 为 metaq3.0,相比于原始 kafka,其擅长点出了原始的 log collecting 之外,还增加诸如 HA、事务等特性,使得从功能点上讲,可以替代传统大部分 MQ。 目前已经在阿里开始大规模应用,并且预计未来会逐渐在阿里取代 notify,meta 2.x 以前的所有队列。由于 rocketmq 还比较新,且官方没有给出相应的 benchmark。而 rocketmq 社区主要活跃者均是中国国内人员,因此不便 于直接对比 rocketmq 和其他队列。在这里用 kafka 和其他队列进行对比,rocketmq 的性能比 kafka 还要好一些。

kafka rabbitmq benchmark
测试场景描述: os: linux cpu: 8core 2GHZ memory:16GB disks: 6 disks raid 10 network: 1Gbps 在各个对比中, 均启动单个 producer, 产生 1000 万条消息, 单条消息大小为 200bytes; kafka 支持批量发送和接受, 因此测试中分别批量值(batchsize)分别设置为 1 和 50,其中设置为 1 可以看成退化成传统 MQ。针对 Producer 其 测试结果如下:

针对 consumer:

作者 何鹏

关注分布式存储与计算相关框架, 包括 Hadoop、 YARN、 HBase、 Storm、 Spark、 MQ 等

peng.he.ia@gmail.com

结论 开启批量模式时,kafka 的 produce 吞吐量极高。当关闭批量模式(batchsize=1)时,kafka 性能不亚于 rabbitmq 和 activemq。对于 consumer,由于 kafka 的设计使得 broker 不需要维护相应的 delivery state,并且数据的存储设计 较好,因此吞吐量远远超过其他 MQ。当然,此 benchmark 是由 kafka 公布,其中 activemq、rabbitmq 并没有进行 相应调优,并且只有单个 producer、consumer 的测试,刚好符合 kafka 的顺序读写特点,因此只能说具有一定参考 意义。具体还是需要结合应用场景,进行相应的模拟测试,才能得出是否适应自己业务使用的结论。

kafka vs rabbitmq in detail

rabbitmq 设计初衷

kafka

rocketmq 同 kafka; 且考虑了事务特性;

充分考虑消息堆积因素, 认 更多工作是保证消息递交; 为 consumer 不 一 定 处 于 认为 consumer 是一直处于 alive 状态; alive 状态去消费消息的; 考虑各个角色的分布式; broker 设计的比较重, 需要 为追求吞吐量设计; 记录很多状态; broker 设计较轻,不保存 consumer 的消费状态 提供了丰富的 routing,实 topic routing only 现了 amqp 的 exchange、 binding、 queuing 等 model, queue、topic 等 routing 都 支持; 对应用透明的集群式实现; 虽然是集群式的实现, 但是 集群对 producer 并不是完 全透明, producer 需要确认 消 息 发 送 到 哪 一 个
关注分布式存储与计算相关框架, 包括 Hadoop、 YARN、 HBase、 Storm、 Spark、 MQ 等

路由特性

topic routing only

集群特性

同 kafka

作者 何鹏

peng.he.ia@gmail.com

partition;同时也利用这一 点实现了消息的顺序递交 特性(partition 内的消息是 顺序的) ; HA 通过 mirror queue 来支持 (master/slave) master 提供服务,slave 仅 备份 消息量~=20k/sec; <1000 不支持 不支持 通过 replica 来支持 queue 的 master/slave 的可 以自动切换(当 master 宕 掉后) 消息量>100k/sec 支持上万队列 支持 不支持 支持,但需要人工切换 master 和 slave 的角色;

消息处理量 队列数目 顺序投递 事务性

消息量>100k/sec 支持上万队列 支持 支持

Kafka is a general purpose message broker, like RabbItMQ, with similar distributed deployment goals, but with very different assumptions on message model semantics. I would be skeptical of the "AMQP is more mature" argument and look at the facts of how either solution solves your problem. a) Use Kafka if you have a fire hose of events (100k+/sec) you need delivered in partitioned order 'at least once' with a mix of online and batch consumers, you want to be able to re-read messages, you can deal with current limitations around node-level HA (or can use trunk code), and/or you don't mind supporting incubator-level software yourself via forums/IRC. b) Use Rabbit if you have messages (20k+/sec) that need to be routed in complex ways to consumers, you want per-message delivery guarantees, you don't care about ordered delivery, you need HA at the cluster-node level now, and/or you need 24x7 paid support in addition to forums/IRC. Neither offers great "filter/query" capabilities - if you need that, consider using Storm on top of one of these solutions to add computation, filtering, querying, on your streams. queryable cache. Or use something like Cassandra as your Kafka is also definitely not "mature" even though it is "production ready".

Details (caveat - my opinion, I've not used either in great anger, and I have more exposure to RabbitMQ) Firstly, on RabbitMQ vs. Kafka. different design philosophies. They are both excellent solutions, RabbitMQ being more mature, but both have very Fundamentally, I'd say RabbitMQ is broker-centric, focused around delivery Whereas Kafka

guarantees between producers and consumers, with transient preferred over durable messages.

is producer-centric, based around partitioning a fire hose of event data into durable message brokers with cursors, supporting batch consumers that may be offline, or online consumers that want messages at low latency. RabbitMQ uses the broker itself to maintain state of what's consumed (via message acknowledgements) - it uses Erlang's Mnesia to maintain delivery state around the broker cluster. Kafka doesn't have message acknowledgements, it assumes the consumer tracks of what's been consumed so far. reliably maintain their state across a cluster. RabbitMQ presumes that consumers are mostly online, and any messages "in wait" (persistent or not) are held opaquely (i.e. no cursor). RabbitMQ pre-2.0 (2010) would fall over if your consumers were too slow, but now it's robust for online and batch consumers - but clearly large amounts of persistent messages sitting in the broker was not the main design case for AMQP in general.
作者 何鹏

Both Kafka brokers & consumers use Zookeeper to

Kafka was based from the beginning around both online and batch
peng.he.ia@gmail.com

关注分布式存储与计算相关框架, 包括 Hadoop、 YARN、 HBase、 Storm、 Spark、 MQ 等

consumers, and also has producer message batching - it's designed for holding and distributing large volumes of messages. RabbitMQ provides rich routing capabilities with AMQP 0.9.1's exchange, binding and queuing model. very simple routing approach - in AMQP parlance it uses topic exchanges only. Both solutions run as distributed clusters, but RabbitMQ's philosophy is to make the cluster transparent, as if it were a virtual broker. Kafka makes it explicit, by forcing the producer to know it is partitioning a topic's messages across several nodes, this has the benefit of preserving ordered delivery within a partition, which is richer than what RabbitMQ exposes, which is almost always unordered delivery (the AMQP 0.9.1 model says "one producer channel, one exchange, one queue, one consumer channel" is required for in-order delivery). Put another way, Kafka presumes that producers generate a massive stream of events on their own timetable - there's no room for throttling producers because consumers are slow, since the data is too massive. The whole job of Kafka is to provide the "shock absorber" between the flood of events and those who want to consume them in their own way -some online, others offline - only batch consuming on an hourly or even daily basis. Kafka can deliver "at least once" semantics per partition (since maintains delivery order), just like RabbitMQ, but it does it in a very different way. Performance-wise, if you require ordered durable message delivery, currently it looks like there's no comparison: Kafka currently blows away RabbitMQ in terms of performance on synthetic benchmarks . cluster with 6-disk RAID 10. http://research.microsoft.com/en... Of course this was written by the LinkedIn guys without necessarily expert RabbitMQ input, so YMMV. Finally, a reminder: Kafka is an early Apache incubator project. It doesn't necessarily have all the hard-learned aspects in RabbitMQ. Now, a word on AMQP. Frankly, it seems the standard is a mess. Officially there is a 1.0 proposed specification This paper indicates 500,000 messages published per second and 22,000 messages consumed per second on a 2-node Kafka has a

that is going through the OASIS standards process. In practice it is a forked standard, one (0.9.1) supported by vendors, the other (1.0) supported by the working group. exist until 2013, if ever. As an external observer with no inside knowledge, here is what it looks like: spec, from 2003 to 2008, culminating in a widely adopted release (0.9.1). transport protocol (sort of like TCP++), and declared it 1.0. the working group spent 5 years on a A set of generally available, widely-adopted, production-quality AMQP 1.0 implementations across the major releases (Qpid from Redhat, RabbitMQ, etc.) won't

Then a subset of more powerful working

group members rewrote the spec by late 2011, completely shifting the focus of the spec from a messaging model to a So, we have the strange case where the "mature" AMQP is the non-standard 0.9.1 specification and the "immature" AMQP is the actual 1.0 standard. This isn't to suggest 1.0 isn't good technology, it likely is, but that it's a much lower-level spec than AMQP intended to be for most of its published life, and is not widely supported yet beyond prototypes and one GA implementation that I know of (IIT SwiftMQ). The RabbitMQ folks have a prototype that has layers the 0.9.1 model on top of 1.0 but have not committed to a GA timeframe. So, in my opinion, AMQP has lost some of its sheen, as while there's ample evidence it is interoperable from the
作者 何鹏 关注分布式存储与计算相关框架, 包括 Hadoop、 YARN、 HBase、 Storm、 Spark、 MQ 等 peng.he.ia@gmail.com

various connect-fests over the years, the standards politics have delayed the official standard and called into question its widespread support. On the bright side, one can argue that AMQP has already succeeded in its goal of helping to Now there are many break the hold TIBCO had on high performance, low latency messaging through 2007 or so.

options. Bet on the broker you choose to use, and don't expect bug-free interoperability for a few years (if ever). Just wanted to add a comment on Stuarts answer. Don't use rabbit if you need clustering for HA their clustering does not actually support network partitions. This is well explained in their documentation.

参考文献: 1. http://blog.x-aeon.com/2013/04/10/a-quick-message-queue-benchmark-activemq-rabbitmq-hornetq-qpid-apollo/ 2. http://www.quora.com/RabbitMQ/RabbitMQ-vs-Kafka-which-one-for-durable-messaging-with-good-query-features 3. https://www.rabbitmq.com/tutorials/amqp-concepts.html 4. http://activemq.apache.org/version-5-getting-started.html 5. http://predic8.com/activemq-hornetq-rabbitmq-apollo-qpid-comparison.htm 6. paper: Kafka: a Distributed Messaging System for Log Processing 7. http://my.oschina.net/geecoodeer/blog/194829 8.

作者 何鹏

关注分布式存储与计算相关框架, 包括 Hadoop、 YARN、 HBase、 Storm、 Spark、 MQ 等

peng.he.ia@gmail.com


相关文章:
消息队列(Message Queue)简介及其使用
路由服务器查看站点链接的开销,确定经过多个站点传递消息的最快和最有效的方法,以此决定如 何传递消息。 2. 队列类型(Queue Type) 有两种主要的队列类型:由您...
消息队列介绍及原理
消息队列介绍及原理_电子/电路_工程科技_专业资料。消息队列 MQ 技术的介绍和原理 (2010-03-14 00:00:00) 转载 标签: 杂谈 ▼ 消息队列技术是分布式应用间...
下面是一个应用消息队列进行通信的应用程序
16 根针呀! 这样就建立了个消息队列: CommondQ = OSQCreate(&commondMsg【0】,16) ; 接下来就是收消息队列了 MSG = OSQPend(commondQ,OS_TICKS_PER_...
基于Redis实现分布式消息队列
基于Redis实现分布式消息队列_计算机软件及应用_IT/计算机_专业资料。基于 Redis 实现分布式消息队列 [日期:2015-05-18] 来源:Linux 社区 作者:stationxp [字体:大...
消息队列及中转软件总结
队列的使用除去了接收和发送应用程序同时执行的要求,一般情况下 都需要有一个队列维护服务。 消息服务器在分布式系统应用间消息通信起到了 至关重要的作用。 ...
利用消息队列实现多进程通信过程
(3) 消息队列还可以将货物进行分类服务,标记各种类别的服务,这样就可以根据货物 类别分别出货。 消息队列是 IPC 对象的一种与同样提供先进先出服务的管道相比,它...
操作系统大作业(消息队列通信)
2014/12/17 计算机科学技术 实验成绩: 一、实验目的 熟练掌握消息队列通信的个功能及使用方法, 掌握 txt 文件的创建及转 换,掌握如何显示一个 txt 文件。 ...
MQ介绍与选型
MQ 选型 RabbitMQ 使用 Erlang 编写的一个开源的消息队列,本身支持很多的...对于 RabbitMQ 和 Redis 的入队和出队操作,执行 100 万次,每 10 ...
MSMQ(消息队列)学习笔记
二、名词解释 1. 消息 消息是由通信的双方所需要传递的信息。它可以是各式...2) 系统队列: “日记队列” 可选地存储发送消息的副本队列中移除的消息...
应用消息队列应对大并发访问的解决方案
应用消息队列应对大并发访问的解决方案_信息与通信_工程科技_专业资料。应用消息队列应对大并发访问的解决方案 摘要:为了让使用此消息队列的开发人员了解此消息队列的...
更多相关标签: