我们架构中的不同服务在运行过程中需要一定量的资源，无论是 CPU、RAM 还是磁盘空间，我们都需要确保有足够的资源。如果我们不对服务器将要使用的资源数量设置限制，迟早会遇到麻烦。当数据库耗尽文件系统空间、媒体存储填满图片且从不转移它们，或者 JVM 耗尽 RAM 时，就会发生这种情况。即使是备份解决方案，如果不设置过期/删除旧备份的策略，也会成为一个问题。嗯，队列也不例外。我们必须确保我们的应用程序不会让队列无休止地增长。我们需要有某种策略来删除/驱逐/迁移旧消息。
在 RabbitMQ 3.2.0 中，我们引入了 消费者优先级，顾名思义，它允许我们为消费者设置优先级。这让我们能够在一定程度上控制 RabbitMQ 如何将消息传递给消费者，以实现对应用程序有益的另一种调度方式。
您会在什么时候在代码中使用消费者优先级？
我们在 RabbitMQ 3.2.0 中添加了对联合队列的支持。这篇博文解释了它们的作用以及如何使用它们。
我们已经讨论了 RabbitMQ 3.0 如何会“搞砸”一些东西，但这并不积极。让我们来看看一些新功能！仅仅是其中的一部分——3.0 版本有很多改变，而我们没有一整天的时间……
RabbitMQ 包含许多很棒的新功能。但为了实现其中的一些功能，我们需要改变一些东西。所以在这篇博文中，我将列出其中一些内容，以防您需要对它们进行任何操作。
我为 RabbitMQ 编写了一个插件，它增加了对 MQTT 3.1 协议的支持。MQ Telemetry Transport 是一种轻量级的 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。)