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
