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

在 RabbitMQ 3.2.0 版本中，我们引入了消费者优先级，顾名思义，它允许我们为消费者设置优先级。这为我们提供了一定的控制权，以便 RabbitMQ 可以将消息传递给消费者，从而获得可能对我们的应用程序有利的不同类型的调度。

在什么情况下您需要在代码中使用消费者优先级？

我们已在 RabbitMQ 3.2.0 版本中添加了对联邦队列的支持。这篇博文解释了它们的用途以及如何使用它们。

图表​

我们已经讨论了 RabbitMQ 3.0 如何破坏现有功能，但这并不是很积极。让我们来看看一些新功能！只是一些 - 3.0 版本中更改了很多内容，而我们没有一整天的时间...

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

我为 RabbitMQ 编写了一个插件，增加了对 MQTT 3.1 协议的支持。MQ 遥测传输是一种轻量级的 PUB/SUB 协议，专为资源受限的设备和带宽受限的情况而设计，使其非常适合传感器和移动设备。该实现是一个协议适配器插件，允许 MQTT 客户端与实现其他协议的客户端同时连接到 RabbitMQ 代理。我们鼓励需要将低开销协议与健壮、可扩展且具有高可靠性和企业功能的代理相结合的项目考虑此选项。

很长一段时间以来，在 RabbitMQ 总部，我们一直在努力寻找一种在 Web 浏览器中公开消息传递的好方法。过去，我们尝试了很多方法，从旧且著名的 JsonRPC 插件（基本上通过 AJAX 公开 AMQP），到 Rabbit-Socks（尝试创建通用协议中心），再到管理插件（可用于浏览器发送和接收消息等基本操作）。

随着时间的推移，我们了解到 Web 上的消息传递与我们习惯的消息传递非常不同。我们之前的尝试都没有真正解决这个问题，而且 Web 上的消息传递在一段时间内可能仍然无法完全解决。

话虽如此，RabbitMQ 用户一直在询问一个简单的事情，虽然不完美，但远非在浏览器中进行消息传递的最糟糕方式：通过 Websockets 公开 STOMP。

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

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

之前的 RabbitMQ 版本 (2.7.0) 带来了更好的插件管理方式、客户端的一站式 URI 连接、Java 客户端中的线程安全消费者，以及许多性能改进和错误修复。最新版本 (2.7.1) 本质上是一个错误修复版本；尽管它也使 RabbitMQ 与 Erlang R15B 兼容，并增强了一些管理界面。之前的版本没有发布博文，所以我将这两个版本合并到这一篇中。  (这些是我个人的评论，不具有约束力；委托或遗漏的错误完全由我个人承担 -- Steve Powell。)

自从 RabbitMQ 2.0.0 版本中引入新持久化器（是的，它已经不算新了），RabbitMQ 在处理不断增长并达到无法保存在 RAM 中的大小的队列方面，已经有了一个相对不错的故事。RabbitMQ 很早就开始将消息写入磁盘，并以平缓的速度继续这样做，以便在 RAM 真正紧张时，我们已经完成了大部分的艰苦工作，从而避免了突然的写入突发。前提是您的消息速率不太高或太突发，否则这一切都应该在不对任何连接的客户端产生任何实际影响的情况下发生。

最近与一位客户的讨论使我们重新审视了我们认为已经相当完善的问题，并促使我们做出了一些改变。