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

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

最近我们为 Cloud Foundry 推出了 RabbitMQ 服务，使其可以轻松启动消息代理，以便与 Cloud Foundry 上的应用程序一起使用。网上有关于将其与 Ruby on Rails 以及使用 Spring 的 Java 应用程序一起使用的教程。在这里，我们将研究如何将 RabbitMQ 服务与 Node.JS 应用程序一起使用。

今天，我们在 CloudFoundry.com 上推出了 RabbitMQ 服务。这项服务将 RabbitMQ 的消息传递功能带给在 Cloud Foundry 上构建应用程序的开发人员。您可以阅读 Cloud Foundry 博客上的 主要公告。Cloud Foundry 知识库中还提供了 包含更多详细信息的 FAQ。 CloudFoundry.com 是一项免费的 Beta 服务。因此，请在那里注册（如果您尚未注册），然后查看 RabbitMQ 服务，试用示例应用程序，并编写自己的应用程序。并告诉我们如何改进它。

我从根本上不同意我们当前 AMQP 客户端库公开的 API。

它们不完善是有原因的：从一开始我们就故意避免在 API 中进行创新。我们的客户端库的目的是公开通用的 AMQP，而不是任何一种消息传递视图。但是，在我看来，尝试将 AMQP 直接映射到客户端库 API 是错误的，并且会导致过度复杂化和难以使用的抽象。

没有共同点：盲目遵循 AMQP 模型的客户端库将是复杂的；易于使用的客户端库必须是有主见的。

最近我看到一条推文说“ZeroMQ Erlangizes everything!” 或类似的话。虽然我意识到并非网上发布的所有内容都是认真的，但似乎最近确实出现了一系列类似的说法，应该阻止这种说法。

在文章 Multi-threading Magic[^1] 中，Pieter Hintjens 和 Martin Sustrik 令人信服地解释了为什么消息传递比锁和共享内存更适合并发。而且我认为，他们的分析是公平的——除了暗示使用 ZeroMQ 会将您选择的编程语言转换为国产 Erlang 之外。

注意：这篇博文讨论了为 RabbitMQ 2.5.0 发布的 federation 插件预览版。如果您使用的是 2.6.0 或更高版本，则 federation 是主要版本的一部分；以与其他任何插件相同的方式获取它。

又一天，又一个新插件发布😃今天发布的是 federation。如果您想跳过这篇文章并直接下载插件，请转到此处。详细说明请参见此处。

federation 的高级目标是在 WAN 和管理域中扩展发布/订阅消息传递。

为此，我们引入了 federation 交换机的概念。federation 交换机的行为类似于给定类型的普通交换机（它可以模拟任何已安装交换机类型的路由逻辑），但也知道如何连接到上游交换机（这些交换机本身也可能是 federation 交换机）。

RabbitMQ 团队很高兴地宣布 RabbitMQ 2.5.0 发布。

我们在 RabbitMQ 总部的大多数人除了 Erlang 之外，还花时间使用多种函数式语言，例如 Haskell、Scheme、Lisp、OCaml 等。虽然 Erlang 有很多值得喜欢的地方，例如它的 VM/Emulator，但我们都不可避免地会怀念其他语言的功能。就我而言，在回到 RabbitMQ 阵营之前，我在 Haskell 工作了几年，各种各样的功能都“缺失”了，例如惰性求值、类型类、额外的中缀运算符、指定函数优先级的能力、更少的括号、偏函数应用、更一致的标准库和 do-notation。这是一个相当长的列表，我需要一段时间才能在 Erlang 中实现所有这些功能，但这里有两个入门功能。

在我们之前的博文中，我们讨论了主题路由优化的一些方法，并简要描述了其中最重要的两种。在这篇文章中，我们将讨论我们在实现 DFA 时尝试的一些事情，以及我们在 trie 和 DFA 上进行的一些性能基准测试。

RabbitMQ 2.4.0 引入了一个扩展，允许发布者在 CC 和 BCC 消息头中指定多个路由键。BCC 标头在传递之前从消息中删除。直接和主题交换机是唯一使用路由键的标准交换机类型，因此此功能的路由逻辑仅适用于这些交换机类型。