标记为 "HowTo" 的 18 篇文章

RabbitMQ 包含许多很棒的新功能。但是为了实现其中一些功能，我们需要做一些更改。因此，在这篇博文中，我将列出其中的一些内容，以防您需要对此做任何事情。

您在 Rabbit 中有一个队列。您有一些客户端从该队列中消费。如果您根本不设置 QoS 设置 (basic.qos)，那么 Rabbit 将尽快将队列中的所有消息推送到客户端，速度取决于网络和客户端的允许程度。消费者将在内存中膨胀，因为他们缓冲了 RAM 中的所有消息。如果您询问 Rabbit，队列可能看起来是空的，但可能有数百万条消息未被确认，因为它们位于客户端中，准备由客户端应用程序处理。如果您添加一个新的消费者，则队列中没有剩余消息要发送给新的消费者。消息只是在现有客户端中缓冲，并且可能会在那里停留很长时间，即使有其他消费者可以更快地处理这些消息。这是相当不理想的。

因此，默认的 QoS prefetch 设置为客户端提供无限缓冲区，这可能会导致不良行为和性能。但是您应该将 QoS prefetch 缓冲区大小设置为多少呢？目标是让消费者的工作饱和，但要尽量减少客户端的缓冲区大小，以便更多消息保留在 Rabbit 的队列中，从而可供新消费者使用，或者只是在消费者空闲时发送给他们。

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

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

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

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

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

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

RabbitMQ 2.3.1 引入了几个新的插件机制，让您可以更好地控制用户如何针对 Rabbit 进行身份验证，以及我们如何确定他们被授权做什么。这里有三个相关问题

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

问题 1 在 AMQP 的情况下通过 SASL 回答 - 一种用于可插拔身份验证机制的简单协议，它嵌入在 AMQP（和各种其他协议）中。SASL 让客户端和服务器协商并使用身份验证机制，而“外部”协议无需知道身份验证如何工作的任何细节。

SASL 提供了许多“机制”。从一开始，RabbitMQ 就支持 PLAIN 机制，该机制基本上包括在线路上以明文形式发送用户名和密码（当然，整个连接可能受到 SSL 的保护）。它还支持变体 AMQPLAIN 机制（在概念上与 PLAIN 相同，但如果您有 AMQP 编解码器，则更容易实现）。RabbitMQ 2.3.1 添加了一个插件系统，允许您添加或配置更多机制，并且我们编写了一个示例插件，实现了 SASL EXTERNAL 机制。

对于那些远离互联网的人来说，node.js 是一个基于 Google V8 的事件驱动 JavaScript 引擎。因为它本质上是一个高效的大型事件循环，所以它非常适合在状态之间来回传输数据的程序。而且编程很有趣，显然很多人都有这种看法，因为围绕它涌现了大量库。

在这些库中，更令人印象深刻的是 Socket.IO。可以将 Socket.IO 与 node.js 的内置 Web 服务器结合使用来制作 WebSocket 服务器，并为浏览器提供套接字抽象，当没有 WebSocket 时，该抽象会降级为 XHR 技巧。（我很乐意相信 node.js 和 Socket.IO 是由仁慈且有远见的先驱种族为我们制造的；但当然，它们是由勤奋聪明的工程师制造的。谢谢你们，工程师们！）

一旦浏览器中有了套接字抽象，一个全新的世界就会打开。具体来说，对于我们的目的而言，消息传递的全新世界。由于 node.js 有一个 AMQP 客户端，我们可以轻松地将其与 RabbitMQ 连接起来；不仅可以桥接到其他协议和后端系统，还可以提供浏览器之间以及应用程序服务器之间的消息传递，等等。

继我们与 ZeroMQ 的 Martin Sustrik 进行的 工作之后，我决定制作一个非常简单的协议，用于浏览器套接字，反映 ZeroMQ 中使用的消息传递模式（以及 RMQ-0MQ 中的模式）—— 发布/订阅、请求/回复 和 推送/拉取（或管道）。我编写了一个 node.js 库，该库使用 RabbitMQ 通过其路由和缓冲来实现消息模式；然后桥接是免费的，因为 RabbitMQ 有许多协议适配器和各种语言的客户端。

消息传递模式的简要说明

发布/订阅适用于应将已发布消息传递给多个订阅者的情况。在一般情况下，可以使用各种类型的路由来为每个订阅者过滤消息。这可以用于将通知从后端系统广播到用户的浏览器，例如。

请求/回复用于通过消息传递进行 RPC；请求在工作进程之间进行循环分配，回复路由回请求套接字。这可以由浏览器用于查询后端服务；甚至浏览器之间互相查询。

管道用于将进程链接在一起。消息以循环方式推送到工作进程，这些工作进程本身可能会推送到处理的另一个阶段。这可以用于协调用户集（或实际上是个人）之间的工作流程。

在充分简化之后，这里是 rabbit.js。

它只需要安装一个最基本的 RabbitMQ 和 node.js；以及 node-amqp 和 Socket.IO 库。说明和这些东西的位置在 README 中。（请注意，您需要 我的 node-amqp 分支。）

它还包括一个微型消息套接字服务器；也就是说，一个 node.js 服务器，它接受套接字连接并以长度前缀消息进行通信。由于一切都通过 RabbitMQ，因此您可以通过套接字与连接到 Socket.IO 的浏览器进行对话。您还可以使用来自 node.js 本身运行的代码中的进程内管道服务器。

总而言之，我惊讶于我可以用几行代码和一些技术完成这么多工作，这些技术都恰到好处——node.js 用于有趣的联网服务器编程，Socket.IO 用于神奇的浏览器套接字，以及 RabbitMQ 用于无泪的消息传递。

我正在设置我的旧 MacBook，从我的室友那里收回，使其可用于编程。