一篇之前的博文介绍了流过滤，这是 RabbitMQ 3.13 中的一项新功能，也是一项令人兴奋的功能。在这篇文章中，我们将探讨流过滤的内部机制。了解设计和实现将有助于您以最优方式为您的用例配置和使用流过滤。

流过滤是 RabbitMQ 3.13 中的一项新功能。它允许在代理和使用应用程序之间节省带宽，当这些应用程序只需要流中的一部分消息时。

继续阅读以了解流过滤的工作原理并在实际中应用它。

RabbitMQ 3.12 中发布的原生 MQTT为物联网用例提供了显著的扩展性和性能提升。

RabbitMQ 3.13 将支持MQTT 5.0，因此将成为我们让 RabbitMQ 成为领先的 MQTT 代理的旅程中的下一个重要步骤。

这篇博文解释了如何在 RabbitMQ 中使用新的 MQTT 5.0 功能。

RabbitMQ 3.12 将很快发布，其中包含许多新功能和改进。这篇博文重点关注性能方面的差异。最重要的变化是经典队列的lazy模式现在是标准行为（更多信息见下文）。新的实现应该更加节省内存，同时提供比早期版本中lazy或non-lazy实现更高的吞吐量和更低的延迟。

为了获得更好的性能，我们强烈建议切换到经典队列版本 2 (CQv2)。

RabbitMQ 现在有一个官方的Discord 服务器，由核心团队启动。如果您更喜欢 Discord 而不是Slack，请随时加入并讨论所有与 RabbitMQ 相关的事情！

RabbitMQ 的核心协议一直是 AMQP 0.9.1。为了支持 MQTT、STOMP 和 AMQP 1.0，代理通过其核心协议透明地进行代理。虽然这是一种用对更多消息协议的支持扩展 RabbitMQ 的简单方法，但它会降低可扩展性和性能。

在过去 9 个月中，我们重写了MQTT 插件，不再通过 AMQP 0.9.1 进行代理。相反，MQTT 插件解析 MQTT 消息并将它们直接发送到队列。这就是我们所说的原生 MQTT。

结果是惊人的

1. 内存使用量最多减少 95%，在许多连接的情况下减少数百 GB。
2. RabbitMQ 首次能够处理数百万个连接。
3. 端到端延迟下降了 50% - 70%。
4. 吞吐量提高了 30% - 40%。

原生 MQTT 将 RabbitMQ 变成了一个 MQTT 代理，为更广泛的物联网用例打开了大门。

原生 MQTT 在 RabbitMQ 3.12 中提供。

仲裁队列是经典镜像队列的升级替代方案，在 RabbitMQ 版本 3.8 中推出。您需要迁移有两个互补的原因。

首先，经典镜像队列在 3.9 中被弃用，并在 2021 年 8 月 21 日发布了正式公告。它们将在 4.0 中完全删除。

但它们也更可靠、更可预测、对大多数工作负载来说更快，并且需要更少的维护——因此您不会觉得自己在没有明显理由的情况下被迫迁移。

仲裁队列在所有方面都更好，但它们与镜像队列在功能上不完全兼容。因此迁移看起来可能是一项艰巨的任务。

在深入了解未来性能改进之后，这篇文章概述了一些可能的迁移策略，并包括有关如何处理不兼容功能的指导。您也可以使用将 RabbitMQ 镜像经典队列迁移到仲裁队列的文档来帮助您完成迁移过程。

RabbitMQ 团队和社区成员最近发现了一个奇怪的现象，即刚启动的节点可能会消耗大量内存，例如 1.5 GiB 或更多。我们想与社区分享我们的发现，并解释现有的短期和长期解决方法。

我们打算在 2022 年 9 月 5 日发布 RabbitMQ 3.11.0。虽然我们已经在内部使用生产级工作负载测试了它一段时间，但我们需要您的帮助来检查它是否像我们相信的那样稳定可靠。

如今，当我们使用 rabbitmq-management 和 rabbitmq_auth_backend_oauth2 插件时，唯一支持的授权服务器是UAA，这使得连接到其他 OAuth 2.0 服务器变得困难。此外，rabbitmq-management 插件使用OAuth 2.0 隐式流，由于安全原因，这种流不再被推荐。

RabbitMQ 3.11 将支持与 OpenID Connect 和 OAuth 2.0 协议兼容的几乎任何授权服务器。此外，OAuth 2.0授权码授予将成为默认的授予方式，而隐式授予方式将不再受支持。