仲裁队列是 RabbitMQ 3.8 版本中引入的镜像经典队列的更优替代品。您需要迁移有两个互补的原因。
首先，经典镜像队列在 3.9 中已被弃用，正式公告于 2021 年 8 月 21 日发布。它们将在 4.0 中完全移除
而且它们更可靠、更可预测，对于大多数工作负载来说速度更快，并且需要更少的维护——因此您不应觉得您的手被强迫，而没有任何明显的原因。
仲裁队列在所有方面都更好，但它们在功能上与镜像队列不是 100% 兼容的。因此，迁移可能看起来是一项艰巨的任务。
在初步了解未来的性能改进之后，这篇文章概述了一些可能的迁移策略，并包含有关如何处理不兼容功能的指南。迁移 RabbitMQ 镜像经典队列到仲裁队列文档 也可帮助您完成迁移过程。
今天，当我们使用带有 rabbitmq_auth_backend_oauth2 插件的 rabbitmq-management 时，唯一支持的授权服务器是 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 内置的监控功能。监控 Broker 及其客户端对于在问题影响环境的其余部分以及最终用户之前检测到问题至关重要。
RabbitMQ 3.8.10 通过 Prometheus 端点和 HTTP API 公开客户端身份验证尝试指标。
“我的队列使用了多少内存？” 这是一个容易提出的问题，但也是一个更复杂的问题。RabbitMQ 3.4 让您可以更清楚地了解队列如何使用内存。这篇博文谈到了一些关于这方面的内容，并解释了队列内存的一般使用情况。
什么？又一篇 “破坏性变更” 文章？嗯，是的，但希望这应该比前一篇更容易处理。但是 RabbitMQ 3.3.0 中有足够多的稍微不兼容的更改，值得在此处列出。
在这篇博文中，我们将解决在分布式系统中控制对特定资源的访问的问题。解决此问题的技术在计算机科学中是众所周知的，它被称为信号量，由 Dijkstra 在 1965 年在他的论文“协作顺序进程”中发明。我们将看到如何使用 AMQP 的构建块（如消费者、生产者和队列）来实现它。
我们架构中的不同服务将需要一定数量的资源才能运行，无论是 CPU、RAM 还是磁盘空间，我们都需要确保我们有足够的资源。如果我们不对服务器将要使用的资源数量进行限制，那么在某个时候我们就会遇到麻烦。如果您的数据库耗尽文件系统空间，您的媒体存储空间被图像填满并且从不将它们移动到其他地方，或者您的 JVM 耗尽 RAM，就会发生这种情况。如果您没有用于过期/删除旧备份的策略，即使您的备份解决方案也会成为问题。好吧，队列也不例外。我们必须确保我们的应用程序不允许队列永远增长。我们需要制定一些策略来删除/驱逐/迁移旧消息。
在 RabbitMQ 3.2.0 中，我们引入了 消费者优先级，不出所料，它允许我们为消费者设置优先级。这为我们提供了一些关于 RabbitMQ 将如何向消费者传递消息的控制，以便获得可能对我们的应用程序有益的不同类型的调度。
您何时希望在代码中使用消费者优先级？
因此，我们在 RabbitMQ 3.2.0 中添加了对联邦队列的支持。这篇博文解释了它们的用途以及如何使用它们。