RabbitMQ 4.0 弃用公告

在 RabbitMQ 4.0 中，我们计划移除一些 RabbitMQ 功能，以：

• 提高核心代理的弹性
• 减少可用的次优配置数量
• 从团队中移除技术覆盖范围（维护旧代码）
• 减轻支持负担

我们不断创新，以满足并超越用户的期望。移除不再符合这些期望或为用户服务的旧功能，意味着我们可以专注于为用户提供稳定、高性能和灵活的消息传递系统的使命。

我们宣布弃用的功能选择的原因是（两者之一）：

• 在某些条件下，它们的表现不佳
• 它们使用频率较低

鉴于每项功能都有更新、更安全的选择来实现相同的结果，我们认为没有人应该继续使用这些功能。

本文档旨在解释这些变更并提供反馈机会。

何时进行这些更改？

我们计划在 RabbitMQ 4.0 发布时进行这些更改。目前尚未为该版本设定时间表。

在进行更改之前，我们将审查通过调查收集的反馈。

如何提供反馈？

如果您想就此公告提供反馈，请完成此调查。

公告

禁用通过管理 API / UI 发送指标

我们为什么做出这个决定？

管理 API 一直承担着两个功能：控制平面和指标传递系统。这种双重目的意味着在罕见的情况下（即极端负载下）指标会延迟。

存在哪些替代方案？

自 3.8 版本（于 2019 年 10 月发布）起提供的 Prometheus 插件，即使在高负载下也能提供指标。它还具有提供比管理 API 更广泛指标的好处。有关 Prometheus 和 Grafana 的仪表板的文档在此。

移除全局 QoS

我们为什么做出这个决定？

全局 QoS，即为整个通道使用单个共享预取，不被推荐。

存在哪些替代方案？

应改为设置每个消费者的 QoS（非全局）。

移除 RAM 节点

我们为什么做出这个决定？

RAM 节点将其所有内部元数据（包括用户、策略、队列和 RabbitMQ 集群成员资格）保存在内存中。当代理节点重启时，所有这些都会丢失，这意味着不建议在高可用集群中使用 RAM 节点，因为它可能导致数据丢失。

存在哪些替代方案？

应使用具有快速存储的磁盘节点。

移除经典队列镜像

我们为什么做出这个决定？

与经典镜像队列相比，仲裁队列（Quorum Queues）提供更高的数据安全性。

存在哪些替代方案？

客户应使用仲裁队列进行复制和数据安全。经典镜像队列的 TTL 可以由流（streams）替代。

移除临时、非独占队列

我们为什么做出这个决定？

临时队列是其生命周期与声明它们所在节点的正常运行时间相关联的队列。在单节点集群中，当节点重启时它们会被移除。在集群环境中，当它们所在的节点重启时它们会被移除。

正确使用临时队列需要应用程序开发人员了解节点正常运行时间。此外，节点重启并不是移除未使用队列的好方法。

有一种临时队列不包含在此弃用范围内；即独占队列。独占队列与其声明连接的生命周期相关联，这是应用程序开发人员可以考虑并利用的一个方面。

通过弃用临时队列，我们消除了一个可能令人困惑的队列选项。我们还减少了启动过程的压力，因为临时队列目前是在启动时移除的。

存在哪些替代方案？

队列 TTL 应用于在一段时间不活动后自动删除未使用的、空闲的队列。

独占队列：一旦到队列的所有连接被移除，这些队列就会被删除。

不再对经典队列的发布者确认使用 fsync

我们为什么做出这个决定？

与不使用 fsync 的非镜像经典队列相比，仲裁队列提供更高的安全性。手动调用 fsync 会导致性能损失，不如让内核决定何时刷新到磁盘。

存在哪些替代方案？

客户应使用仲裁队列进行复制和数据安全。

谢谢

感谢您的阅读。如果您对以上内容有任何想法，请填写我们的调查，让我们知道您对拟议变更的看法！