在一般情况下，我们的假设证明正确的，因为更多的消息被发送到系统中，每个消息的延迟增加。有趣的是，当我们接近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 RabbitMQActiveMQ 和 RabbitMQ 都是AMQP 的一种具体实现。他们扮演着一个保证小心能够正常交付的角色。AcitveMQ 和 RabbitMQ 都支持 持久性或非持久性的信息交付。默认情况下，消息会存储到磁盘中，可以保证消息队列重启时数据的一致，避免消息的丢失。它们还支持同步和异步发送消息，前者对延迟有实质性影响。为了保证交付，这些代理使用消息确认，这也导致巨大的延迟代价。
就可用性和容错性而言，这些代理通过共享存储或无共享支持集群。队列可以跨集群节点进行复制，因此没有单点故障或消息丢失。
AMQP是一个非平凡的协议，其创作者声称过度设计。这些额外的保证是以牺牲主要复杂性和性能折衷为代价的。从根本上说，客户更难实现和使用。
由于它们是消息代理，ActiveMQ和RabbitMQ是需要在分布式系统中管理的额外移动部件，这会带来部署和维护成本。
Redis最后是Redis。虽然Redis是轻量级消息和临时存储的理想选择，但我不能主张将其用作分布式消息传递系统的主干。它的pub / sub很快，但它的功能有限。它需要大量的工作来建立一个健壮的系统。存在更好地适合于该问题的解决方案，诸如上面描述的那些解决方案，并且还存在一些缩放问题。
除此之外，Redis易于使用，易于部署和管理，并且占用空间相对较小。根据用例，它可以是一个伟大的选择实时消息。