我们很想听听有关 ActiveMQ、RabbitMQ 和 ZeroMQ 优缺点的任何经验。也欢迎提供有关任何其他有趣消息队列的信息。
17 回答
编辑:我最初的回答非常关注 AMQP。我决定重写它以提供有关该主题的更广泛的观点。
这 3 种消息传递技术在构建分布式系统方面有不同的方法:
RabbitMQ是 AMQP 协议(与 Apache Qpid 一起)的主要实现之一。因此,它实现了代理架构,这意味着消息在发送到客户端之前在中央节点上排队。这种方法使 RabbitMQ 非常易于使用和部署,因为只需几行代码即可支持路由、负载平衡或持久消息队列等高级场景。然而,它也降低了可扩展性和“速度”,因为中央节点增加了延迟并且消息信封非常大。
ZeroMq是一个非常轻量级的消息传递系统,专为高吞吐量/低延迟场景而设计,例如您在金融界可以找到的场景。Zmq 支持许多高级消息传递方案,但与 RabbitMQ 相反,您必须通过组合框架的各个部分(例如:套接字和设备)自己实现其中的大部分。Zmq 非常灵活,但你必须学习80 页左右的指南(我建议任何编写分布式系统的人阅读,即使你不使用 Zmq)才能做任何比发送消息更复杂的事情2 对等之间。
ActiveMQ处于中间地带。与 Zmq 一样,它可以使用代理和 P2P 拓扑进行部署。与 RabbitMQ 一样,实现高级场景更容易,但通常以原始性能为代价。这是消息传递的瑞士军刀:-)。
最后,所有 3 款产品:
- 拥有最常用语言(C++、Java、.Net、Python、Php、Ruby 等)的客户端 API
- 有强大的文档
- 得到积极支持
为什么你错过了Sparrow、Starling、Kestrel、Amazon SQS、Beanstalkd、Kafka、IronMQ?
消息队列服务器
消息队列服务器有多种语言版本,Erlang (RabbitMQ)、C (beanstalkd)、Ruby (Starling 或 Sparrow)、Scala (Kestrel、Kafka) 或 Java (ActiveMQ)。可以在这里找到简短的概述
麻雀
- 由亚历克斯·麦考撰写
- Sparrow 是一个用 Ruby 编写的轻量级队列,可以“说 memcache”</li>
八哥
- 由布莱恩库克在推特上撰写
- Starling 是一个基于 MemCached 的消息队列服务器
- 用红宝石写的
- 将作业存储在内存中(消息队列)
- 文档:一些很好的教程,例如关于八哥和工作的 railscast或关于八哥的博客文章
红隼
- 写的罗比指针
- 用 Scala 编写的 Starling 克隆(从 Ruby 到 Scala 的 Starling 端口)
- 队列存储在内存中,但记录在磁盘上
兔MQ
- RabbitMQ 是 Erlang 中的消息队列服务器
- 将作业存储在内存中(消息队列)
Apache ActiveMQ
- ActiveMQ 是 Java 中的开源消息代理
豆茎
- 由 Philotic, Inc. 编写,用于提高 Facebook 应用程序的响应时间
- 主要用 C 编写的内存工作队列服务
- 文档:http : //nubyonrails.com/articles/about-this-blog-beanstalk-messaging-queue
亚马逊 SQS
卡夫卡
- 用 Scala 写在 LinkedIn
- LinkedIn 使用它来卸载所有页面和其他视图的处理
- 默认使用持久性,对热数据使用 OS 磁盘缓存(具有比上述任何启用持久性的更高的吞吐量)
- 支持在线处理和离线处理
ZMQ
- 充当并发框架的套接字库
- 比 TCP 更快,适用于集群产品和超级计算
- 通过 inproc、IPC、TCP 和多播传送消息
- 通过 fanout、pubsub、pipeline、request-reply 连接 N 对 N
- 用于可扩展多核消息传递应用程序的异步 I/O
EagleMQ
- EagleMQ是一个开源、高性能和轻量级的队列管理器。
- 用 C 写的
- 将所有数据存储在内存中并支持持久性。
- 它有自己的协议。支持使用队列、路由和通道。
IronMQ
- IronMQ
- 写在围棋
- 完全托管的队列服务
- 提供云版本和本地版本
我希望这对我们有帮助。 资源
More information than you would want to know:
http://wiki.secondlife.com/wiki/Message_Queue_Evaluation_Notes
UPDATE
Just elaborating what Paul added in comment. The page mentioned above is dead after 2010, so read with a pinch of salt. Lot of stuff has been been changed in 3 years.
这实际上取决于您的用例。
将 0MQ 与 ActiveMQ 或 RabbitMQ 进行比较是不公平的。ActiveMQ 和 RabbitMQ 是需要安装和管理的消息系统。它们提供的功能远远超过 ZeroMQ。他们有真正的持久队列,支持事务等。
ZeroMQ 是一个轻量级的面向消息的套接字实现。它也适用于进程内异步编程。可以在 ZeroMQ 上运行“企业消息系统”,但您必须自己实现很多。
所以:
ActiveMQ、RabbitMQ、Websphere MQ 和 MSMQ 是“企业消息队列”
ZeroMQ 是一个面向消息的 IPC 库。
这里有 RabbitMQ 和 ActiveMQ 的比较。开箱即用,ActiveMQ 被配置为保证消息传递 - 与不太可靠的消息传递系统相比,这可能给人以缓慢的印象。如果您愿意,您可以随时更改性能配置,并获得至少与任何其他消息传递系统一样好的性能。至少你有这个选择。论坛和 ActiveMQ 常见问题解答上有很多关于可扩展性、性能和高可用性配置的信息。此外,当规范最终确定时,ActiveMQ 将支持 AMQP 1.0,以及其他有线格式,如 STOMP。
ActiveMQ 的另一个优点是它是一个 Apache 项目,因此开发人员社区存在多样性——而且它不依赖于一家公司。
I have not used ActiveMQ or RabbitMQ but have used ZeroMQ. The big difference as I see it between ZeroMQ and ActiveMQ etc. is that 0MQ is brokerless and does not have built in reliabilty for message delivery. If you are looking for an easy to use messaging API supporting many messaging patterns,transports, platforms and language bindings then 0MQ is definitely worth a look. If you are looking for a full blown messaging platform then 0MQ may not fit the bill.
See www.zeromq.org/docs:cookbook for plenty examples of how 0MQ can be used.
I an successfully using 0MQ for message passing in an electricity usage monitoring application (see http://rwscott.co.uk/2010/06/14/currentcost-envi-cc128-part-1/)
我正在使用 zeroMQ。我想要一个简单的消息传递系统,我不需要代理的复杂性。我也不想要一个庞大的面向 Java 的企业系统。
如果您想要一个快速、简单的系统并且需要支持多种语言(我使用 C 和 .net),那么我建议您查看 0MQ。
关于 ActiveMQ,我只能加 2 美分,但因为这是最受欢迎的之一:
你想写的语言可能很重要。尽管 ActiveMQ 对大多数人来说确实有一个客户端,但与 Java 库相比,它们的 C# 实现还远未完成。
这意味着一些基本功能是不稳定的(故障转移协议......好吧......在某些情况下失败,没有重新交付支持)而其他根本不存在。由于 .NET 对项目来说似乎并不那么重要,因此开发速度相当缓慢,而且似乎没有任何发布计划。主干经常坏掉,所以如果你考虑到这一点,如果你想让事情继续下去,你可能想考虑为项目做出贡献。
然后是 ActiveMQ 本身,它有很多不错的功能,但也有一些非常奇怪的问题。出于稳定性原因,我们使用 Fuse (Progress) 版本的 activemq,但即便如此,您也需要记住一些奇怪的“错误”:
- 在某些情况下停止发送消息的代理
- 使队列显示消息的日志错误不再存在(它们没有传递给消费者,但仍然存在)
- 优先级仍未实现(自人类开始以来就在问题列表中)
- 等等等等
总而言之,如果你能忍受它的问题,它是一个非常好的产品:
A) 在使用 .NET 时不要害怕积极参与
B) 在 Java 中开发 ;-)
就个人而言,我已经尝试了以上三个。在我看来,RabbitMQ 是最好的性能,但它没有故障转移和恢复选项。ActiveMQ 的功能最多,但速度较慢。
更新: HornetQ也是您可以考虑的一个选项,它是 JMS Complaint,如果您正在寻找基于 JMS 的解决方案,它是比 ActiveMQ 更好的选择。
ZeroMQ 真的是零队列!这真是一个错误!它没有队列、主题、持久性,什么都没有!它只是套接字 API 的中间件。如果这是你看起来很酷的!否则算了!它不像 activeMQ 或 rabbitmq。
我在这里写了关于 AMQP、Qpid 和 ZeroMQ 的初步经验:http ://ron.shoutboot.com/2010/09/25/is-ampq-for-you/
我的主观意见是,如果您确实需要持久消息传递设施并且不太担心代理可能会成为瓶颈,那么 AMQP 很好。此外,AMQP 目前缺少 C++ 客户端(Qpid 没有赢得我的支持;但不确定 ActiveMQ 客户端),但可能正在进行中。ZeroMQ 可能是其他方式。
我已经在生产环境中使用 ActiveMQ 大约 3 年了。虽然它完成了工作,但排列可以正常工作且没有错误的客户端库版本可能是一个问题。目前正在寻求过渡到 RabbitMQ。
There is some discussion in the comments of this blog post, about Twitter writing their own message queue, which may be interesting.
Steve did extensive load and stress testing of ActiveMQ, RabbitMQ, etc. ActiveMQ is actually quite slow (much slower than Kestrel), RabbitMQ consistently crashes with too many producers and too few consumers.
You probably won't have Twitter-like load initially however :)
很少有应用程序像 ActiveMQ 那样拥有如此多的调优配置。使 ActiveMQ 脱颖而出的一些特性是:
可配置的预取大小。可配置的线程。可配置的故障转移。向生产者发送可配置的管理通知。...详情请见:
如果你也对商业实现感兴趣,你应该从my-channels看看 Nirvana 。
Nirvana 在金融服务行业中被大量用于大规模低延迟交易和价格分配平台。
支持跨企业、Web 和移动域的各种客户端编程语言。
如果透明 HA 或负载平衡对您很重要,集群功能非常先进,值得一看。
Nirvana 可免费下载用于开发目的。
关于 ZeroMQ aka 0MQ,正如您可能已经知道的那样,它可以让您每秒获得最多的消息(上次我检查时它们在他们的 ref 服务器上大约每秒 400 万条消息),但您可能也已经知道,文档不存在。您将很难找到如何启动服务器,更不用说如何使用它们了。我想这就是为什么还没有人贡献 0MQ 的部分原因。
玩得开心!
Abie,这一切都取决于您的用例。与其依赖其他人对其用例的描述,不如随意将您的用例发布到 rabbitmq-discuss 列表。在推特上提问也会得到一些回应。最好的祝愿,亚历克西斯