RabbitMQ 4.0 弃用公告

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

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

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

我们之所以宣布弃用这些功能，是因为（或者）：

• 在某些条件下，它们的运行效率不佳
• 它们的使用频率较低

鉴于每个功能都有更新、更安全的替代方案来实现相同的结果，我们认为不应再使用这些函数。

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

这些变更何时生效？

我们计划在发布 RabbitMQ 4.0 时实施这些变更。目前尚未确定此版本的发布时间表。

在实施变更之前，我们将审阅通过调查问卷提供的反馈意见。

我该如何提供反馈？

如果您想针对此声明提供反馈，请填写此调查问卷。

公告内容

禁止通过管理 API / UI 交付指标

我们为何做出此决定？

管理 API 一直承担着两种功能：控制平面和指标交付系统。这种双重用途意味着在极少数情况下（例如极端负载下），指标交付会出现延迟。

有哪些替代方案？

自 2019 年 10 月 3.8 版本发布以来，Prometheus 插件已可提供指标，即使在高负载下也能正常运行。它还有一个额外好处，即提供比管理 API 更丰富的指标。有关 Prometheus 和 Grafana 仪表板的文档请见此处。

移除全局 QoS

我们为何做出此决定？

全局 QoS（即整个通道共享一个预取值）并非推荐的做法。

有哪些替代方案？

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

移除内存节点 (RAM nodes)

我们为何做出此决定？

内存节点将其所有内部元数据（包括用户、策略、队列和 RabbitMQ 集群成员信息）保存在内存中。当代理节点重启时，所有这些数据都会丢失，因此在高可用集群中使用内存节点是不被推荐的，因为这可能导致数据丢失。

有哪些替代方案？

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

移除经典队列镜像

我们为何做出此决定？

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

有哪些替代方案？

客户应使用仲裁队列来进行副本同步和数据保护。经典镜像队列的生存时间 (TTL) 可以由流 (Streams) 取代。

移除瞬态、非独占队列

我们为何做出此决定？

瞬态队列是指其生命周期与声明该队列的节点运行时间相关的队列。在单节点集群中，当节点重启时它们会被删除。在集群环境中，当承载它们的节点重启时，它们会被删除。

正确使用瞬态队列要求应用程序开发人员了解节点正常运行时间的相关信息。此外，重启节点并非删除未使用队列的良好方式。

有一种瞬态队列不在此次弃用范围内，即独占队列。独占队列与声明它们的连接生命周期相关联，这是应用程序开发人员可以考虑并加以利用的特性。

通过弃用瞬态队列，我们移除了一个容易造成混淆的队列选项。同时，由于瞬态队列目前会在启动时被删除，此举也减轻了启动过程的压力。

有哪些替代方案？

应使用队列 TTL 来自动删除闲置一段时间后的未使用队列。

独占队列：当所有连接到该队列的连接断开后，这些队列会被删除。

不再对经典队列的生产者确认使用 fsync

我们为何做出此决定？

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

有哪些替代方案？

客户应使用仲裁队列来进行副本同步和数据保护。

谢谢

感谢您的阅读。如果您对以上内容有任何想法，请填写我们的调查问卷，让我们了解您对这些提议变更的看法！