今天，我们在 CloudFoundry.com 上推出了 RabbitMQ 服务。此服务将 RabbitMQ 的消息功能带给在 Cloud Foundry 上构建应用程序的开发人员。您可以阅读 主要公告，该公告发布在 Cloud Foundry 博客上。还有 关于更多详细信息的常见问题解答，发布在 Cloud Foundry 知识库中。CloudFoundry.com 是一项免费的测试版服务。因此，请在那里注册（如果您还没有），然后看看 RabbitMQ 服务，尝试一下示例应用程序，并编写您自己的应用程序。然后告诉我们如何改进它。

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

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

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

最近，我看到一条推文说“ZeroMQ 使一切 Erlang 化！”或者类似的话。虽然我知道并非所有发布在网络上的内容都认真对待，但最近确实出现了一系列类似的说法，应该阻止。

在文章《多线程魔法》[^1] 中，Pieter Hintjens 和 Martin Sustrik 有说服力地解释了为什么与锁和共享内存相比，消息传递更能有效地提供并发性。我认为他们在分析中是公平的——除了暗示使用 ZeroMQ 会将您选择的编程语言转换为本地的 Erlang。

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

又一天，另一个新插件发布😃今天是**联邦**。如果您想跳过这篇文章，直接下载插件，请访问 这里。详细说明请访问 这里。

联邦的总体目标是在 WAN 和管理域之间扩展发布/订阅消息传递。

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

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

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

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

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

我决定对我的 AMQP 编码器/解码器 (AMQ 协议 gem) 进行一些基准测试，与 AMQP gem 中的旧编码器/解码器进行对比，看看它是否性能更好。到目前为止，我只进行了一些最基本的优化，例如将可重用值存储在常量中，没有任何特殊之处（暂时）。

我进行了两组基准测试：使用 我为 RBench 创建的分支 进行 CPU 时间基准测试，该分支支持自定义格式化程序（例如将结果写入 YAML 文件），并使用 `Object.count_objects`（Ruby 1.9）进行内存基准测试。

在许多消息传递场景中，您不能丢失消息。由于 AMQP 对消息持久性/处理的保证很少，因此传统的做法是使用事务，这可能非常慢。为了解决这个问题，我们以轻量级发布者确认的形式引入了一个 AMQP 扩展。