带有“新功能”标签的 62 篇文章

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

在许多消息传递场景中，您不能丢失消息。由于 AMQP 对消息持久性/处理没有太多保证，传统上使用事务来实现，但这可能会非常缓慢。为了解决这个问题，我们引入了轻量级发布者确认的 AMQP 扩展。

RabbitMQ 2.3.1 引入了一些新的插件机制，让您能够更好地控制用户如何对 Rabbit 进行身份验证，以及我们如何确定他们被授权执行哪些操作。这里有三个问题需要考虑

1. 客户端如何通过网络证明其身份？
2. 用户和身份验证信息（例如密码哈希）存储在哪里？
3. 权限信息存储在哪里？

在 AMQP 的情况下，问题 1 的答案是 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”表示它是推荐的第一个版本。规范是不完整的：有很多待办事项，而且在很大程度上，它是未经验证的。这两个事实是促使我们进行原型设计的部分原因。

原型代码在 github 上镜像：https://github.com/rabbitmq/rabbitmq-amqp1.0。它与我们所有其他插件的构建方式 相同。

AMQP 1.0 R0 规范与之前版本的 AMQP 规范不同，因为它没有定义代理模型；也就是说，它没有定义交换、队列和绑定，或者它们的等效项。该协议实际上只与将消息从一个代理传输到另一个代理有关，然后就传输结果达成一致。这意味着它适合用于连接到消息代理实现，以及其他用途——想法是，可以根据需要调整现有模型。

就我们而言，现有的模型是 AMQP 0-9-1，它有一些泛化和扩展（例如，链式绑定）。因此，我们的原型目标是能够同时使用 1.0 客户端和 0-9-1 客户端完成一些有用的工作。

好消息是，我们已经实现了这一点。事实上，可以将插件设置为替换 Rabbit 通常的网络监听器，并且它将很乐意与 AMQP 0-8、0-9-1 和 1.0 客户端进行通信。我们在这一过程中确实做了一些创造性的工作，并且有些规范部分我们并没有实现。这些将在 README 中很快详细介绍。

我们创建的大部分内容是为了在规范保持沉默的地方填充语义。其中一些内容在 我们为 AMQP 工作组完成的客户端-代理协议 工作中进行了详细介绍。我们希望原型设计能够帮助我们进一步完善这些内容。

下周，我将带着我们的原型参加 AMQP 1.0 “Connectathon”，在那里它将与核心协议的其他实现（并非全部是开源的）进行测试。同样，这将有助于消除规范中对互操作性的障碍。

RabbitMQ 2.1.1 中提供了对交换之间绑定 的支持。这是 AMQP 规范的扩展，使用此功能将（目前）导致您的应用程序仅在 RabbitMQ 上运行，而不是在其他各种 AMQP 0-9-1 代理实现上运行。但是，此扩展极大地提高了路由拓扑的表现力和灵活性，同时还解决了一些可扩展性问题。

常规绑定允许将交换绑定到队列：发布到交换的消息将（如果满足交换及其绑定的各种条件）通过各种绑定，并在每个绑定的末尾追加到队列中。这对于许多用例来说已经足够了，但灵活性很差：它始终只有一跳——消息被发布到一个交换，具有一个绑定集，因此只有一个可能的目的地集。如果您需要更高的灵活性，则需要多次发布相同的消息。使用交换到交换的绑定，发布一次的消息可以通过任意数量的交换，具有不同的类型，并且可以实现比以前更复杂的路由拓扑。

最近，Michael Bridgen 和我实现了一个桥接，用于将 RabbitMQ 代理连接到使用 0MQ 进行消息传递的应用程序。

它在这里：https://github.com/rabbitmq/rmq-0mq

那么：并行使用这两个产品可以给用户带来什么好处？

之前提到的 管理插件 现在已经进入可以查看和测试的状态。为了方便起见，我专门针对管理插件制作了一个一次性二进制版本（将来，我们将像其他插件一样发布它的二进制版本）。从 这里 下载所有 .ez 文件，并按照 这里 的说明安装它们，然后告诉我们您的想法。（更新 2010-09-22：请注意，这篇博文中提到的插件适用于 RabbitMQ 的 2.0.0 版本。我们现在已经发布了 2.1.0 版——对于此版本及更高版本，您可以从 这里 获取管理插件）。

在推出 RabbitMQ 三年半之后，我们本周发布了 RabbitMQ 2.0。

这意味着一些重大变化。其中最重要的变化是我们的新可扩展存储引擎。RabbitMQ 一直为故障恢复提供持久性。但是现在，无论已经存储了多少数据，您都可以将数据推送到 Rabbit 中，并且无需担心缓慢的消费者会中断处理。随着应用程序需求的增长，Rabbit 可以与您一起扩展，以稳定、可靠的方式进行扩展。

在介绍 RabbitMQ 2.0 之前，我要再次强调的是，随着 Rabbit 的发展，您可以相信我们对您作为客户或最终用户的承诺将保持不变，无论您是大型企业、新一代初创企业还是开源社区。与往常一样，如果您需要帮助或商业支持，请 联系我们。

长期以来，RabbitMQ 中内置的管理和监控功能一直由 rabbitmqctl 提供。虽然它是一个相当不错的管理工具（假设您喜欢命令行），但 rabbitmqctl 从未作为监控工具发挥过强大的作用。因此，我们将构建更强大的工具。