带有“HowTo”标签的 18 篇文章

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

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

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

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

最近，我们推出了一个用于 Cloud Foundry 的 RabbitMQ 服务，从而可以轻松地启动一个消息代理以与您在 Cloud Foundry 上的应用程序一起使用。在线上有教程介绍如何将其与 Ruby on Rails 和使用 Spring 的 Java 应用程序一起使用。在这里，我们将研究如何在 Node.JS 应用程序中使用 RabbitMQ 服务。

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

又一天，另一个新的插件发布😃今天是联合。如果您想跳过此帖子并直接下载插件，请访问此处。详细说明此处。

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

为此，我们引入了联合交换的概念。联合交换就像给定类型的普通交换（它可以模拟任何已安装交换类型的路由逻辑），但还知道如何连接到上游交换（这反过来本身可能也是联合交换）。

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，从我的室友那里收回，以便能够用于编程。