自从 RabbitMQ 2.0.0 中引入了新的持久化机制（是的，它已经不算那么新了）以来，RabbitMQ 在处理不断增长、大到无法完全存储在内存中的队列方面，一直表现得相当不错。RabbitMQ 会尽早开始将消息写入磁盘，并以温和的速率持续进行，这样当内存变得非常紧张时，我们已经完成了大部分繁重的工作，从而避免了突然的写入高峰。只要您的消息速率不是太高或太不稳定，这一切都应该能顺利进行，而不会对任何连接的客户端造成实际影响。
最近与一位客户的讨论促使我们重新审视了一个我们认为已经相对解决的问题，并促使我们做出了一些改变。
注意：这篇博文讨论的是为 RabbitMQ 2.5.0 发布的一个 federation 插件预览版。如果您使用的是 2.6.0 或更高版本，federation 是主发行版的一部分；您可以像获取任何其他插件一样获取它。
又一天，又一款新插件发布😃今天发布的是 **federation**。如果您想跳过这篇博文直接下载插件，请前往此处。详细说明请参见此处。
Federation 的高级目标是在广域网和管理域中扩展发布/订阅消息。
为此，我们引入了 **federation exchange** 的概念。federation exchange 像一个给定类型的普通 exchange 一样工作（它可以模拟任何已安装的 exchange 类型的路由逻辑），但它也知道如何连接到 **上游** exchange（这些上游 exchange 本身也可能是 federation exchange）。
RabbitMQ 2.4.0 引入了一项扩展，允许发布者在 CC 和 BCC 消息头中指定多个路由键。BCC 标头在消息传递之前被从消息中移除。直接和主题交换是仅有的使用路由键的标准交换类型，因此此功能的路由逻辑仅适用于这些交换类型。
在许多消息传递场景中，您不能丢失消息。 由于 AMQP 在消息持久化/处理方面提供的保证很少，因此传统的实现方式是使用 事务，但这可能会慢得无法接受。 为了解决这个问题，我们引入了一个 AMQP 的扩展，即轻量级 Publisher Confirms。
RabbitMQ 2.3.1 引入了几个新的插件机制，让您可以更全面地控制用户如何向 Rabbit 进行身份验证，以及我们如何确定他们被授权执行哪些操作。这里有三个问题值得关注：
对于 AMQP，第一个问题通过 SASL 来解答——这是一个嵌入在 AMQP（以及其他各种协议）中的可插拔身份验证机制的简单协议。SASL 允许客户端和服务器协商并使用身份验证机制，而无需“外部”协议了解身份验证的工作细节。
SASL 提供了许多“机制”。从一开始，RabbitMQ 就支持 PLAIN 机制，它基本上是在传输过程中以明文形式发送用户名和密码（当然，整个连接可能由 SSL 保护）。它也支持 AMQPLAIN 机制（概念上与 PLAIN 相同，但如果您有一个 AMQP 编解码器，实现起来会更容易）。RabbitMQ 2.3.1 添加了一个插件系统，允许您添加或配置更多机制，我们编写了一个实现 SASL EXTERNAL 机制的示例插件。
我很高兴地宣布 AMQP 0.7 发布了，正如我在上一篇博文中承诺的那样。那么，有什么变化呢？
我们一如既往地在对一项新协议的支持进行原型设计。这项新协议名为“AMQP 1.0 R0”，它是 AMQP 工作组（RabbitMQ，以及后来的 VMware，都是其成员）提出的新版本。“R0”表示它是修订版建议的第一个版本。该规范尚不完整：有许多待办事项（TODO），并且在很大程度上尚未经过验证。这两个事实也是促使我们进行原型设计的因素之一。
原型代码已在 github 上镜像：http://github.com/rabbitmq/rabbitmq-amqp1.0。它的构建方式与我们所有的插件完全相同。
AMQP 1.0 R0 规范与之前版本的 AMQP 规范不同之处在于，它不定义 broker 模型；也就是说，它不定义 exchange、queue 和 binding，或者它们的等价物。该协议实际上只关乎将消息从一个代理传输到另一个代理，然后就结果达成一致。这意味着它可以附加到消息 broker 实现上，以及其他用途——其理念是人们可以调整现有模型以适应需求。
在我们的案例中，现有的模型是 AMQP 0-9-1 的模型，并包含一些泛化和扩展（例如，链式 binding）。因此，我们原型设计的目标是能够同时使用 1.0 客户端和 0-9-1 客户端连接并完成一些有用的工作。
好消息是，我们已经实现了这一点。实际上，该插件可以配置为替代 Rabbit 原有的网络监听器，并能够愉快地与 AMQP 0-8、0-9-1 和 1.0 客户端进行通信。在此过程中，我们确实进行了一些创新，并且有一些规范的部分是我们没有实现的。这些内容稍后将在 README 文件中详细说明。
其中一项重要的创新是填补规范中未定义的部分。其中一些细节已在我们为 AMQP 工作组所做的客户端-broker 协议工作中有所说明。我们希望原型设计能帮助进一步完善这部分内容。
下周，我将把我们的原型带到AMQP 1.0 “Connectathon”，届时它将与其他核心协议的实现（并非所有实现都是开源的）进行测试。同样，这将有助于消除规范中互操作性方面的障碍。
RabbitMQ 2.1.1 版本带来了对交换机之间绑定的支持。这是 AMQP 规范的扩展，使用此功能将（目前）导致您的应用程序只能与 RabbitMQ 配合使用，而无法与市面上其他众多 AMQP 0-9-1 消息中间件兼容。然而，这项扩展极大地提高了路由拓扑的表达能力和灵活性，并同时解决了一些可伸缩性问题。
常规绑定允许交换机绑定到队列：发布到交换机的消息，只要满足交换机及其绑定的各种条件，就会通过各种绑定，并最终附加到每个绑定末尾的队列中。这对于许多用例来说已经足够了，但灵活性非常有限：它总是只有一步——消息被发布到一个交换机，具有一套绑定，因此只有一套可能的目的地。如果您需要更灵活的方式，则不得不多次发布同一条消息。通过交换机到交换机绑定，一条消息可以经过任意数量的不同类型的交换机，实现比以往任何时候都更复杂的路由拓扑。