消息队列性能对比——ActiveMQ、RabbitMQ与ZeroMQ(译文)

Dissecting Message Queues

概述:

  我花了一些时间解剖各种库执行分布式消息。在这个分析中,我看了几个不同的方面,包括API特性,易于部署和维护,以及性能质量.。消息队列已经被分为两组:brokerless和brokered。

  brokerless消息队列是对等的,没有中间商参与信息的传递,而brokered队列有一些服务器端点之间。

性能分析的一些系统:

Brokerless     nanomsg     ZeroMQ

 Brokered     ActiveMQ     NATS     Kafka     Kestrel     NSQ     RabbitMQ     Redis     ruby-nats

测试环境:

  首先,让我们来看看性能指标,因为这可以说是人们最关心的。我已经测量了两个关键指标:吞吐量和延迟。

  所有的测试都运行在一台MacBook Pro 2.6 GHz的i7处理器,16GB内存。这些测试是评估一个单一的生产者和单一消费者的发布订阅拓扑结构。这提供了一个很好的基线。这将是有趣的基准缩放拓扑结构,但需要更多的仪器。

开始测试:

   1、吞吐量基准:

吞吐量基准是指系统每秒能够处理消息的数量,需要注意的是队列中可能有没有单一的“吞吐量”。我们在两个不同的端点之间发送消息,所以我们观察到的是一个“发送方”吞吐量和一个“接收方”吞吐量,即每秒可以发送的消息数和每秒可以接收的消息数.。

     我们这次测试通过发送1,000,000 个1kb 的消息并且计算两边发送和接收消息的时间,这里面选择1kb的数据是因为这种数据更加贴近我们日常开发中遇到的消息请求,许多性能测试倾向于在100到500字节的范围内使用较小的消息.,尽管每个系统都是各不相同的,我们只能够选取大体上相似的测试数据来进行测试。对于面向消息的中间件系统,只使用一个代理。

Brokeless:

      从图片我们可以看出,在发送测有很高的吞吐量,然而有趣的是,发送者与接收者的比率差距。

      ZeroMQ能够发送超过每秒5000000条消息/每秒但只能收到约600000 /秒。

      相反,nanomsg发出害羞的3000000帧/秒可接待近2000000。

Brokered:

    我们可以很直观的观察到,Brokered 消息队列比Brokerless 少了至少两个数量级以上的吞吐量。有一半的Brokered 消息队列吞吐量少于25000条消息每秒。对于Redis的吞吐量或许有一定的误导,尽管Redis 提供 发布/订阅 功能,它并不是真正设计为一个强大的消息队列。以类似的方式使用ZeroMq,Redis切断了慢用户,重要的是要指出,这不是能够可靠地处理这种体积的消息。我们可以将他看成一个特殊点。Kafla 和 ruby-nats 和Redis 有相似的特点,但是能够可靠的处理间歇性故障信息。NATs 在这方面有着优越的吞吐量

    通过上述的图示分析,我们可以看到,Brokered 队列在发送和接收两方面有着一致的吞吐量,而不像Brokerless 那样,发送方与接收方的吞吐量有着较大的差异。

   2、Latency Benchmarks 延迟基准

      第二个关键性能指标是消息延迟,这就测量了在端点之间传输消息需要多长时间。直觉可能告诉我们,这仅仅是吞吐量的逆,即如果吞吐量是消息/秒,延迟是秒/消息。然而,仔细看从ZeroMQ白皮书借这个形象,我们可以看到,这不是个案。

      现实情况是,每个消息发送的延迟线是不统一的,它可以为每一个不同的。事实上,延迟和吞吐量之间的关系是有点涉及。

      与吞吐量不同的是,延迟的测量并不区分发送方和接收方,而是作为一个整体。但是,由于每个消息都有自己的延迟,我们将看看他们的平均值。进一步,我们将看到平均消息延迟与发送的消息数有关.。直觉告诉我们,更多的信息意味着更多的排队,这意味着更高的延迟。

      下图中:

蓝色:nanomsg

红色:ZeroMq

      在一般情况下,我们的假设证明正确的,因为更多的消息被发送到系统中,每个消息的延迟增加。有趣的是,当我们接近1000000条消息时,延迟出现的速度变慢了500000点.。另一个有趣的观察是在1000和5000之间的消息延迟的初始峰值,这是更加显着nanomsg。这很难确定因果关系,但是这些变化可能反映了如何在每个库中实现消息批处理和其他网络堆栈遍历优化.。更多的数据点可以提供更好的可视性。

      我们看一下Brokered队列和一些有趣的新的类似的模式。      

ActiveMq

Kafka

RabbitMq

    他们的延迟数量级高于其他的Brokered 延迟,因此他们ACtiveMq与RabbitMq分成了自己AMQP范畴。

    现在,我们已经看到了一些关于这些不同的库如何执行的经验数据,我将看看他们如何从务实的角度来看工作。消息吞吐量和速度是很重要的,但如果库很难使用、部署或维护,则不太实用.。

ZeroMQ and Nanomsg

    从技术上讲,nanomsg不是一个消息队列,而是一个执行socket风格的图书馆分布式消息通过各种便捷的方式。因此,除了在应用程序中嵌入库本身之外,没有什么可以部署的.。这使得部署一个非问题。

    Nanomsg是一个由ZeroMQ的作者写的,和我讨论过,在对库的工作以一个非常类似的方式。从发展的角度来看,nanomsg提供全面清洁的API。与ZeroMQ不同,认为不存在一个上下文中,套接字绑定到。此外,nanomsg提供可插拔的运输和通讯协议,使其更加开放的延伸。其额外的内置可扩展性协议也使它相当有吸引力。

    像ZeroMQ一样,它保证消息将被原子性地传递完整和有序,但不保证它们的交付。局部的消息将无法交付,并且部分消息可能无法被交付。

    ZeroMq 的研发者 Martin Sustrik:很清楚的指出:

      Guaranteed delivery is a myth. Nothing is 100% guaranteed. That’s the nature of the world we live in. What we should do instead is to build an internet-like system that is resilient in face of failures and routes around damage.(保证交付是一个神话。没有100%保证。这就是我们生活的世界的性质。我们应该做的是建立一个互联网般的系统,面对失败和路线损坏时弹性。)

ActiveMQ and RabbitMQ

    ActiveMQ 和 RabbitMQ 都是AMQP 的一种具体实现。他们扮演着一个保证小心能够正常交付的角色。AcitveMQ 和 RabbitMQ 都支持 持久性或非持久性的信息交付。默认情况下,消息会存储到磁盘中,可以保证消息队列重启时数据的一致,避免消息的丢失。它们还支持同步和异步发送消息,前者对延迟有实质性影响。为了保证交付,这些代理使用消息确认,这也导致巨大的延迟代价。

    就可用性和容错性而言,这些代理通过共享存储或无共享支持集群。队列可以跨集群节点进行复制,因此没有单点故障或消息丢失。

    AMQP是一个非平凡的协议,其创作者声称过度设计。这些额外的保证是以牺牲主要复杂性和性能折衷为代价的。从根本上说,客户更难实现和使用。

    由于它们是消息代理,ActiveMQ和RabbitMQ是需要在分布式系统中管理的额外移动部件,这会带来部署和维护成本。

Redis

  最后是Redis。虽然Redis是轻量级消息和临时存储的理想选择,但我不能主张将其用作分布式消息传递系统的主干。它的pub / sub很快,但它的功能有限。它需要大量的工作来建立一个健壮的系统。存在更好地适合于该问题的解决方案,诸如上面描述的那些解决方案,并且还存在一些缩放问题。

  除此之外,Redis易于使用,易于部署和管理,并且占用空间相对较小。根据用例,它可以是一个伟大的选择实时消息

附上原博文地址:http://bravenewgeek.com/dissecting-message-queues/

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏吴生的专栏

消息中间件选型分析——从Kafka与RabbitMQ的对比来看全局

消息队列中间件(简称消息中间件)是指利用高效可靠的消息传递机制进行与平台无关的数据交流,并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型,它...

4267
来自专栏跨界架构师

分布式系统关注点——「负载均衡」到底该如何实施?

        前面两篇《分布式系统关注点——初识「高可用」》、《分布式系统关注点——仅需这一篇,吃透「负载均衡」妥妥的》看完后,相信大家对实现高可用的思路和负...

934
来自专栏智能计算时代

在裸机与虚拟机上运行容器:性能和优点

根据最近的研究,Docker正在像野火一样蔓延,特别是在企业中,它的采用率从2015年的13%上升到了27%以上;另有35%的公司计划使用Docker。根据这些...

3854
来自专栏无题

各RDB与Nosql性能与特点总结

最近考虑到数据库包括各种缓存到底面对高并发情况性能到底是怎么样的,所以多方收集整理成此篇,以后也会持续更新。 mysql: 1.性能从10万条规模升到100万...

38410
来自专栏编程一生

《两地书》--Kubernetes(K8s)基础知识(docker容器技术)

  大家都知道历史上有段佳话叫“司马相如和卓文君”。“皑如山上雪,皎若云间月”。卓文君这么美,却也抵不过多情女儿薄情郎。

1894
来自专栏互联网研发闲思录

互联网研发中负载均衡算法一点探索

    负载均衡在线上服务中有着很重要作用,因为一台web服务比如tomcat,能够处理qps(每秒处理请求数) 是有限的。那么就需要有有前端负载均衡服务...

1916
来自专栏韩伟的专栏

浅析海量用户的分布式系统设计(1)

为什么海量的用户访问,会让一个服务器端系统变得更复杂?本文就是想从最基本的地方开始,探寻服务器端系统技术的基础概念。

30.7K6
来自专栏编程一生

《两地书》--Kubernetes(K8s)基础知识(docker容器技术)

1144
来自专栏进击的程序猿

不妥协:分布式事务的一致性,可用性和性能

本文是论文No compromises: distributed transactions with consistency, availability, an...

906
来自专栏企鹅号快讯

分布式系统一致性分类,你知道几种?

为了提升系统的可用性、性能、扩展性,我们可以从两个方面着手, 要去建立多个副本。可以放到不同的物理机、机架、机房、地域。一个副本的失效可以让请求转到其他副本。 ...

94610

扫码关注云+社区