关于此主题有一篇较新的博文，它使用了更现代的工具并自动化了大部分过程。
仲裁队列是经典镜像队列的优秀替代品，它在 RabbitMQ 3.8 版本中引入。您需要迁移的原因有两个互补。
首先，经典镜像队列已在 3.9 版本中弃用，于 2021 年 8 月 21 日正式发布了公告。它们将在 4.0 版本中完全移除。
而且它们更可靠、更可预测，对大多数工作负载更快，维护也更少——所以您不应该觉得自己被无缘无故地逼迫。
仲裁队列在所有方面都更好，但它们在功能上与镜像队列不是 100% 兼容的。因此，迁移看起来可能是一项艰巨的任务。
在对未来的性能改进进行一窥之后，本文概述了几种可能的迁移策略，并提供了如何处理不兼容功能的指南。此外，还有迁移您的 RabbitMQ 镜像经典队列到仲裁队列文档可帮助您完成迁移过程。
今天，当我们使用 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 授权码授予将成为默认授予，并且不再支持隐式授予。
自 3.8.0 版本引入原生 Prometheus 支持以来，我们一直在不断改进 RabbitMQ 内置的监控功能。监控代理及其客户端对于在问题影响其他环境并最终影响最终用户之前检测问题至关重要。
RabbitMQ 3.8.10 通过 Prometheus 端点和 HTTP API 暴露客户端身份验证尝试指标。
“我的队列使用了多少内存？”这是一个很容易提出的问题，但回答起来却有些复杂。RabbitMQ 3.4 让您更清楚地了解队列如何使用内存。这篇博文讨论了这个问题，并解释了队列内存使用的一般情况。
什么？又一篇 “Breaking things” 的文章？是的，但希望这次比上次要容易处理得多。但 RabbitMQ 3.3.0 中有足够多稍微不兼容的更改，值得在此列出。
在这篇博文中，我们将解决在分布式系统中控制对特定资源的访问的问题。解决这个问题的方法在计算机科学中是众所周知的，它被称为信号量（Semaphore），由 Dijkstra 在 1965 年的论文“Cooperating Sequential Processes”中发明。我们将看到如何使用 AMQP 的构建块（如消费者、生产者和队列）来实现它。
我们架构中的不同服务在运行过程中需要一定量的资源，无论是 CPU、RAM 还是磁盘空间，我们都需要确保有足够的资源。如果我们不对服务器将要使用的资源数量设置限制，迟早会遇到麻烦。当数据库耗尽文件系统空间、媒体存储填满图片且从不转移它们，或者 JVM 耗尽 RAM 时，就会发生这种情况。即使是备份解决方案，如果不设置过期/删除旧备份的策略，也会成为一个问题。嗯，队列也不例外。我们必须确保我们的应用程序不会让队列无休止地增长。我们需要有某种策略来删除/驱逐/迁移旧消息。
在 RabbitMQ 3.2.0 中，我们引入了 消费者优先级，顾名思义，它允许我们为消费者设置优先级。这让我们能够在一定程度上控制 RabbitMQ 如何将消息传递给消费者，以实现对应用程序有益的另一种调度方式。
您会在什么时候在代码中使用消费者优先级？
我们在 RabbitMQ 3.2.0 中添加了对联合队列的支持。这篇博文解释了它们的作用以及如何使用它们。