我们已经在单独的博客文章中宣布了 3.13 的两个主要新功能

• 支持 MQTT 协议版本 5
• 支持流过滤

这篇文章重点介绍此版本中经典队列的更改

• 经典队列存储格式版本 1 已弃用
• 经典队列消息存储的新实现

我们已经为 RabbitMQ 的新网站工作了几个星期。我们计划在 RabbitMQ 3.13.0 发布后不久发布这项重大升级！此时，我们希望**您访问新网站**并告诉我们您的想法 :-)

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

一篇之前的文章介绍了流过滤，这是 RabbitMQ 3.13 中的一项令人兴奋的新功能。在这篇文章中，我们将介绍流过滤的内部原理。了解设计和实现将帮助您以最适合您用例的方式配置和使用流过滤。

流过滤是 RabbitMQ 3.13 中的一项新功能。当这些应用程序只需要流消息的子集时，它允许节省 broker 和消费应用程序之间的带宽。

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

RabbitMQ 3.12 中发布的 Native MQTT 为 IoT 用例带来了显着的扩展性和性能改进。

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

这篇博文解释了如何在 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，broker 通过其核心协议透明地进行代理。 虽然这是一种使用对更多消息传递协议的支持来扩展 RabbitMQ 的简单方法，但它会降低可扩展性和性能。

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

结果令人惊叹

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

Native MQTT 将 RabbitMQ 变成 MQTT broker，为更广泛的 IoT 用例打开了大门。

Native MQTT 在 RabbitMQ 3.12 中发布。

仲裁队列是 RabbitMQ 3.8 版本中引入的镜像经典队列的卓越替代品。 并且有两个互补的原因说明您需要迁移。

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

但它们也更可靠和可预测，对于大多数工作负载来说更快，并且需要的维护更少 - 因此您不应该觉得您的手在没有明显原因的情况下被强迫。

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

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

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