在 Rabbit 总部，我们一直在欣赏 "RabbitMQ in Action"，这是 RabbitMQ 和消息传递的入门书籍。本书是 Manning 系列 的一部分，由 Jason Williams 和 Alvaro Videla 撰写，他们都因对 Rabbit 社区的诸多贡献而闻名。
今天，我们要感谢 Jason 和 Alvaro。谢谢 Jason 和 Alvaro！你们做得非常出色，我们请你们喝不尽的啤酒。
但还有更多... Manning 慷慨地为本博客的读者提供了 37% 的促销折扣。所有信息都将在下面 Jason Williams 本人的客座文章中揭晓...
在 RabbitMQ 总部，很长一段时间以来，我们一直在努力寻找一种在网络浏览器中公开消息传递的好方法。过去，我们尝试了很多方法，从旧且著名的 JsonRPC 插件（基本上通过 AJAX 公开 AMQP），到 Rabbit-Socks（尝试创建通用协议中心），再到管理插件（可用于基本操作，例如从浏览器发送和接收消息）。
随着时间的推移，我们了解到网络上的消息传递与我们习惯的非常不同。我们之前的尝试都没有真正解决这个问题，而且在一段时间内，网络上的消息传递可能仍然无法完全解决。
尽管如此，RabbitMQ 用户一直在询问一件简单的事情，虽然不完美，但远非在浏览器中进行消息传递的最糟糕方式：通过 Websockets 公开 STOMP。
您在 Rabbit 中有一个队列。您有一些客户端正在从该队列中消费。如果您根本不设置 QoS 设置 (basic.qos)，那么 Rabbit 将尽可能快地将队列中的所有消息推送到客户端，速度取决于网络和客户端的允许速度。消费者将在内存中膨胀，因为他们会将所有消息缓冲到自己的 RAM 中。如果您询问 Rabbit，队列可能看起来是空的，但可能有数百万条消息未被确认，因为它们位于客户端中，准备由客户端应用程序处理。如果您添加新的消费者，则队列中没有消息可以发送给新的消费者。消息只是在现有客户端中缓冲，并且可能在那里停留很长时间，即使有其他消费者可以更快地处理这些消息。这是相当不理想的。
因此，默认的 QoS prefetch 设置为客户端提供无限缓冲区，这可能会导致不良的行为和性能。但是，您应该将 QoS prefetch 缓冲区大小设置为多少？目标是保持消费者的工作饱和，但最小化客户端的缓冲区大小，以便更多消息保留在 Rabbit 的队列中，从而可供新消费者使用，或者在消费者空闲时发送给他们。
欢迎回来！上次 我们讨论了流量控制和延迟；今天我们来谈谈不同的功能如何影响我们看到的性能。以下是一些简单的场景。和以前一样，它们都是一个发布者和一个消费者尽可能快地发布的变体主题。
周末，RabbitMQ 共同赞助了 伦敦 Realtime，为期两晚两天的不掺杂质的黑客马拉松。这一切都由看似不知疲倦的* GoSquared 团队组织，这是一次非常令人印象深刻的首次努力。
作为共同赞助商，我们有一个 iPad 奖品要颁发。我们决定允许使用 RabbitMQ、SockJS 或 Cloud Foundry 中的一个或多个的黑客作品。这意味着在评判时，大约一半的 27 个黑客作品符合资格，使得选择相当困难。
所以今天我想谈谈 RabbitMQ 性能的某些方面。影响您可以从 RabbitMQ 服务器获得的总体性能水平的变量非常多，今天我们将尝试调整其中一些变量，看看我们可以看到什么。
或者：如何在 WebSockets 或 SockJS 上正确进行多路复用
您可能知道，WebSockets 是一项很酷的全新 HTML5 技术，它允许您异步发送和接收消息。我们的兼容层 - SockJS - 模拟了它，即使在旧浏览器或代理后面也能工作。从概念上讲，WebSockets 非常简单。API 基本上是：连接、发送和接收。但是，如果您的 Web 应用程序有许多模块，并且每个模块都希望能够发送和接收数据怎么办？
AtomizeJS 是一个 JavaScript 库，用于编写在浏览器中运行的分布式程序，而无需在服务器上编写任何特定于应用程序的逻辑。
在 RabbitMQ 总部，我们花费大量时间争论。偶尔，是关于重要的事情，例如消息传递的真正含义，以及可用于实现消息传递的不同 API 的范围。RabbitMQ 和 AMQP 为消息传递提供了一个非常明确的接口：您确实有动词发送和接收，并且您需要考虑您的消息传递模式是什么。在底层有很多（通常是非常聪明的东西）正在进行，但是，接口相当底层且明确，这提供了很好的灵活性。但是，有时，这种风格的 API 并不是您尝试解决的问题的最自然选择 - 您真的会陷入僵局并思考“我在这里需要的是 AMQP 消息代理”，还是您从先前的知识中意识到您可以选择使用 AMQP 消息代理来解决您当前的问题？
SockJS 0.2 版本已发布
您可以在常用的 playground 中进行测试
RabbitMQ 的先前版本 (2.7.0) 带来了一种更好的插件管理方式、客户端一站式 URI 连接、Java 客户端中的线程安全消费者，以及许多性能改进和错误修复。最新版本 (2.7.1) 本质上是一个错误修复版本；尽管它也使 RabbitMQ 与 Erlang R15B 兼容，并增强了一些管理界面。之前的版本没有发布博客文章，所以我将这两个版本合并到这篇文章中。（这些是我个人的评论，不具有约束力；委托或遗漏的错误完全是我自己的 -- Steve Powell。）