仲裁队列是 RabbitMQ 版本 3.8 中引入的经典镜像队列的优越替代品。迁移有以下两个互补的原因。
首先，经典镜像队列在 3.9 版本中已弃用，并于 2021 年 8 月 21 日发布正式公告。它们将在 4.0 中完全删除。
但它们也更可靠、更可预测，对于大多数工作负载而言更快，并且需要更少的维护 - 因此你不应感觉自己是被迫无故而为之。
仲裁队列在所有方面都更好，但它们在功能方面与镜像队列并不完全兼容。因此，迁移看起来可能是一项艰巨的任务。
在提前了解未来性能改进后，本文概述了一些可能的迁移策略，并包括有关如何处理不兼容功能的指南。 将 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 为您提供了更清晰的队列内存使用情况视图。本博客文章对此进行了简要介绍，并解释了队列内存使用的一般情况。
什么？又一篇 "突破极限" 文章？好吧，是的，但希望这次比上次需要处理的要少。但是 RabbitMQ 3.3.0 中有足够多的略微不兼容的更改，因此值得在这里列出它们。
在这篇博客文章中，我们将解决控制对分布式系统中特定资源访问的问题。解决此问题的技术在计算机科学中是众所周知的，称为信号量，它是 Dijkstra 在 1965 年的论文“合作顺序进程”中发明的。我们将了解如何使用 AMQP 的构建块（如消费者、生产者和队列）来实现它。
我们架构中的不同服务将需要一定量的资源来运行，无论这些资源是 CPU、RAM 还是磁盘空间，我们都需要确保有足够的资源。如果我们不对服务器将使用多少资源设置限制，那么在某个时候我们就会遇到麻烦。如果数据库用完文件系统空间，媒体存储用图像填满且从不将其移至其他位置，或者 JVM 用完 RAM，就会发生这种情况。即使您的备份解决方案也会有问题，因为您没有过期/删除旧备份的策略。好吧，队列也不例外。我们必须确保我们的应用程序不会允许队列永远增长。我们需要制定一些策略来删除/逐出/迁移旧消息。
在 RabbitMQ 3.2.0 中，我们引入了 消费者优先级，不出所料，它允许我们为消费者设置优先级。这为我们提供了一些控制权，可以控制 RabbitMQ 如何将消息传递给消费者，以便获得可能对我们的应用程序有益的不同类型的调度。
您会在代码中何时使用消费者优先级？
因此我们在 RabbitMQ 3.2.0 中添加了对联合队列的支持。本博客文章解释了它们的用途以及如何使用它们。