我们想知道如何向更广泛的受众介绍 SockJS 及其可能性。有一个可用的演示比解释枯燥的理论更有价值，但是如果你只是一个无聊的技术专家，没有任何设计技能，你能展示什么呢？

对于这样的问题，翻开历史书，回顾一下上一代没有艺术技能的电脑极客总是好的。他们在做什么？在带有绿色字母的控制台上，他们玩着极客电脑游戏，MUD（多人地下城）尤其受欢迎。

嘿，我们可以做到！

自从 new persister 在 RabbitMQ 2.0.0 中出现（是的，它已经不那么 new 了），Rabbit 在处理不断增长和增长的队列方面有一个相对不错的故事，这些队列的大小使得它们无法保存在 RAM 中。Rabbit 相当早地开始将消息写入磁盘，并以缓慢的速度继续这样做，以便在 RAM 真正变得紧张时，我们已经完成了大部分艰苦的工作，从而避免了突然的写入爆发。如果您的消息速率不是太高或太突发，那么这一切都应该发生，而不会对任何连接的客户端产生任何实际影响。

最近与一位客户的讨论使我们回到我们认为已经相当解决的问题，并促使我们做出一些改变。

在 RabbitMQ 2.6.0 中，我们引入了高可用队列。这些需要对 AMQP 进行新的扩展，以及相当数量的文档，但到目前为止，关于它们如何工作的文章很少。

最近在 Web 技术领域发生了很多热门事件。JavaScript 似乎正在举起火炬，无论是在浏览器端还是服务器端。在 RabbitMQ 总部，我们对消息传递领域的广泛发展感兴趣，我们对 JavaScript 在消息传递方面的角度感到特别兴奋 - 即 WebSockets 和相关技术。

我被要求在PubSubHuddle 聚会期间做一个简短的演示。演讲内容是关于 WebSockets 的当前发展、问题以及使用它们构建 Web 应用程序。

我们在 RabbitMQ 总部面临的问题之一是，虽然我们可能对代理的工作原理了解很多，但我们往往没有设计使用 RabbitMQ 并且需要长期可靠、无人值守工作的应用程序的大量经验。我们花了很多时间回答邮件列表上的问题，并且我们在这里和那里做咨询工作，但在某些情况下，正是由于构建应用程序的用户联系我们，我们才真正开始思考 RabbitMQ 的长期行为。最近，我们被促使认真思考队列的基本性能，这导致了对配置 Rabbits 的一些认识。

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

WebSocket 技术正在赶上，但在所有浏览器都支持它之前还需要一段时间。与此同时，有大量项目旨在替代 WebSockets，并为 Web 应用程序启用“实时”功能。但是所有尝试都只解决了通用问题的一部分，并且没有任何单一的解决方案可以工作、可扩展并且不需要特殊的部署技巧。

虽然 firehose 是一个非常酷的功能，但我一直认为很遗憾我们没有一个简单的 GUI 来放在上面并使其系统管理员可以访问。所以我写了一个。您可以在这里下载它。

我们非常高兴地宣布 RabbitMQ 作为 Heroku 插件的 beta 版本可用。通过我们在 CloudFoundry 上的 RabbitMQ 服务，这扩展了我们对支持云应用程序开发者社区的承诺。

我们认为云消息传递在两个意义上是基础的。首先，作为构建可以扩展到云用例的应用程序的核心能力，正如我们在博客文章中启动 CloudFoundry 上的 RabbitMQ 所解释的那样。其次，因为消息传递可以扩展以解决常见问题，例如集成和数据推送。例如：将传统的本地应用程序与虚拟化和云部署连接起来。