在 RabbitMQ 总部，我们相当长一段时间以来一直在努力寻找一种好方法来在 Web 浏览器中公开消息传递。过去我们尝试了许多方法，从老牌的 JsonRPC 插件（基本上通过 AJAX 公开 AMQP）到 Rabbit-Socks（试图创建通用的协议集线器），再到管理插件（可用于发送和接收来自浏览器消息等基本功能）。
随着时间的推移，我们了解到 Web 上的消息传递与我们习惯的方式截然不同。我们所做的任何尝试都未能真正解决这个问题，而且 Web 上的消息传递可能在很长一段时间内都不是一个完全解决的问题。
尽管如此，RabbitMQ 用户一直在询问一个简单的事情，虽然它并不完美，但它远非在浏览器中进行消息传递的最糟糕方式：通过 Websockets 公开 STOMP。
你在 RabbitMQ 中有一个队列。有一些客户端正在从该队列消费。如果你根本不设置 QoS 设置（basic.qos），那么 RabbitMQ 会尽可能快地将队列中的所有消息推送到客户端，只要网络和客户端允许。消费者将在内存中膨胀，因为它们会在自己的 RAM 中缓冲所有消息。如果你询问 RabbitMQ，队列可能看起来是空的，但可能有数百万条消息未被确认，因为它们位于客户端中，随时准备被客户端应用程序处理。如果你添加一个新的消费者，队列中就没有消息可以发送给新消费者了。消息只是被现有客户端缓冲，并且可能需要很长时间才能被处理，即使有其他消费者变得可用，可以更快地处理这些消息。这很不理想。
因此，默认的 QoS prefetch 设置为客户端提供了一个无限缓冲区，这可能导致行为和性能不佳。但是，QoS prefetch 缓冲区大小应该设置为多少？目标是让消费者保持饱和工作，但要最小化客户端的缓冲区大小，以便更多消息保留在 RabbitMQ 的队列中，从而可供新消费者使用，或者在消费者空闲时发送给它们。
欢迎回来！上次我们讨论了流量控制和延迟；今天，让我们来谈谈不同功能如何影响我们看到的性能。这里有一些简单的场景。和上次一样，它们都是围绕一个发布者和一个消费者以最快速度发布消息的主题进行的变体。
周末期间，RabbitMQ 共同赞助了 London 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 消息代理来解决当前的问题？
RabbitMQ 的上一个版本 (2.7.0) 带来了更好的插件管理方式、客户端的统一 URI 连接、Java 客户端中的线程安全消费者，以及一系列性能改进和错误修复。而最新版本 (2.7.1) 主要是一个错误修复版本；但它也使 RabbitMQ 与 Erlang R15B 兼容，并增强了部分管理界面。由于上一个版本没有发布博客文章，因此我将两个版本合并在这篇文章中介绍。 (这些是我个人的观点，不具有约束力；任何错误或遗漏均由我本人负责——Steve Powell。)
我们一直在思考如何将 SockJS 及其可能性呈现给更广泛的受众。一个可运行的演示比解释枯燥的理论更有价值，但是，如果您只是一个普通的技术人员，没有任何设计技能，您能展示什么呢？
遇到这类问题时，打开历史书回顾一下上一代没有艺术技能的计算机极客的做法总是好的。他们在做什么？在绿色的字符控制台上，他们玩着极客的电脑游戏，尤其是MUD（多人地下城）非常流行。
嘿，我们也能做到！
