自从 RabbitMQ 2.0.0 中引入了新的持久化机制（是的，它已经不算那么新了）以来，RabbitMQ 在处理不断增长、大到无法完全存储在内存中的队列方面，一直表现得相当不错。RabbitMQ 会尽早开始将消息写入磁盘，并以温和的速率持续进行，这样当内存变得非常紧张时，我们已经完成了大部分繁重的工作，从而避免了突然的写入高峰。只要您的消息速率不是太高或太不稳定，这一切都应该能顺利进行，而不会对任何连接的客户端造成实际影响。

最近与一位客户的讨论促使我们重新审视了一个我们认为已经相对解决的问题，并促使我们做出了一些改变。

在 RabbitMQ 2.6.0 中，我们引入了高可用性队列。这需要对 AMQP 进行新的扩展，并需要大量的文档，但到目前为止，很少有人写过关于它们如何工作的内容。

最近 Web 技术领域发生了很多令人兴奋的事情。JavaScript 似乎正在引领潮流，无论是在浏览器端还是服务器端。在 RabbitMQ 总部，我们对消息传递领域的最新发展很感兴趣，并且对 JavaScript 在消息传递方面的应用——即 WebSockets 和相关技术——特别感到兴奋。

有人让我参加PubSubHuddle聚会时做一个简短的演讲。这次演讲的主题是WebSocket的当前发展、它的挑战以及使用它们构建Web应用程序。

我们在 RabbitMQ 总部面临的一个问题是，虽然我们对消息代理的工作原理了如指掌，但我们并没有太多关于设计使用 RabbitMQ 并需要长期可靠、无人值守运行的应用程序的经验。我们花了很多时间在邮件列表中回答问题，也会在这里那里做一些咨询工作，但在某些情况下，是用户构建的应用程序促使我们真正思考 RabbitMQ 的长期行为。最近，我们被要求深入思考队列的基本性能，这让我们对 Rabbit 的配置有了新的认识。

突然间，离 PubSub huddle 只剩下一周了。这是一个在伦敦举行的为期一天的关于消息传递的会议。不只是 RabbitMQ，还有 ZeroMQ、MQTT、XMPP 和 PuSH。

WebSocket 技术正在快速发展，但要等到所有浏览器都支持还需要一段时间。在此期间，有大量的项目旨在替代 WebSockets 并为 Web 应用程序启用“实时”功能。但所有这些尝试只解决了通用问题的一部分，而且没有一个单一的解决方案是有效的、可扩展的且不需要特殊部署技巧的。

虽然 Firehose 是一个很酷的功能，但我一直认为我们没有一个简单的 GUI 来使其对系统管理员来说更易于访问，这真是一种遗憾。所以我写了一个。您可以在 此处 下载。

我们很高兴地宣布，RabbitMQ 作为 Heroku 插件 已发布 beta 版。我们继 CloudFoundry 上的 RabbitMQ 服务 之后，此举将进一步拓展我们对云应用程序开发社区的支持。

我们认为，消息传递在云环境中至关重要，体现在两个方面。首先，它是一种核心能力，可以构建能够适应云用例的可伸缩应用程序，正如我们在 博客文章 中启动 CloudFoundry 上的 RabbitMQ 时所解释的那样。其次，消息传递可以扩展以解决集成和数据推送等常见问题。例如：连接传统的本地应用程序与虚拟化和云部署。

“实时 Web”或使用 Web 浏览器进行消息传递的想法已经存在一段时间了。最初被称为“长轮询”，然后是“Comet”，最新的形式叫做“WebSockets”。毫无疑问，它正朝着正确的方向发展，WebSockets 是一项很棒的技术。

但在争取实时功能的过程中，我们忽略了真正重要的事情——如何实际使用消息传递。在 Web 上下文中，一切都是请求-响应驱动的，将典型的 Web 堆栈与异步消息传递相结合并不容易。