几周以来，我们一直在为 RabbitMQ 开发新网站。我们计划在 RabbitMQ 3.13.0 发布后不久推出这次重要的升级！此时，我们非常希望您能 访问新网站 并告诉我们您的想法 :-)

在这篇博文中，我将介绍我们这样做的原因以及它将为您带来的改进。

之前的帖子介绍了 RabbitMQ 3.13 中的一项令人兴奋的新功能——流过滤。在本帖中，我们将介绍流过滤的内部机制。了解其设计和实现将有助于您以最适合您的用例的方式来配置和使用流过滤。

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

继续阅读以了解流过滤的工作原理并查看其实际应用。

RabbitMQ 3.12 中发布的原生 MQTT 为 IoT 用例带来了显著的可伸缩性和性能改进。

RabbitMQ 3.13 将支持MQTT 5.0，因此将是我们成为领先 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 版本中完全移除。

而且它们更可靠、更可预测，对大多数工作负载更快，维护也更少——所以您不应该觉得自己被无缘无故地逼迫。

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

在对未来的性能改进进行一窥之后，本文概述了几种可能的迁移策略，并提供了如何处理不兼容功能的指南。此外，还有迁移您的 RabbitMQ 镜像经典队列到仲裁队列文档可帮助您完成迁移过程。

RabbitMQ 团队和社区成员最近发现了一个奇怪的现象，新启动的节点可能会消耗惊人的大量内存，例如 1.5 GiB 左右。我们想与社区分享我们的发现，并解释可用的短期和长期解决方案。

我们计划于2022年9月5日发布RabbitMQ 3.11.0。虽然我们已经对它进行了长时间的内部测试，并使用了生产环境般的负载，但我们需要您的帮助来检查它是否像我们认为的那样稳定可靠。