RabbitMQ v4.0.x 新特性解读 rabbitmq性能如何

最近，RabbitMQ 迎来了一个重要的版本更新。从 9 月 19 日发布的 v4.0.1，到 10 月 29 日发布的 v4.0.3，RabbitMQ 团队持续不断地进行优化和改进。经过这一个多月的迭代和 bug 修复，v4.0 版本已经逐渐趋于稳定。不少开发者和运维团队也开始着手准备升级测试工作。今天，让我们一起深入了解一下 RabbitMQ 4.0 带来的重要更新和新特性。
一、v4.0.x版本的主要改进如下。

• Khepri 是为取代 Mnesia 而开发的另一种schema数据存储，现已成熟并获得全面支持（之前只是实验性功能），截止到RabbitMQ v4.0.1，默认仍然是Mnesia，该功能还需要在管理控制台上手工启用 khepri_db.
• AMQP 1.0 现在是始终启用的核心协议。AMQP 1.0 插件现在已不再使用，其存在只是为了简化版本升级的过程。
• AMQP 1.0 的效率大大提高：在某些工作负载上，其峰值吞吐量是 3.13.x 的两倍多。
• 使用检查点在节点启动时进行高效的Quorum队列恢复
• Quorum 队列现在支持优先级（但与Classic队列的方式不完全相同），队列和消息都支持优先级。
• AMQP 1.0 客户端现在可以像 AMQP 0-9-1 客户端那样管理拓扑结构
• 用于与 AMQP 0-9-1 实体交互的 AMQP 1.0 约定（地址格式）现在更容易推理了
• 基于经典队列的镜像队列（Mirror）在废弃数年后已被正式移除。如果需要高可用队列，请使用Quorum、Stream队列代替Mirror队列
• 对于高可用复制队列，请使用Quorum队列/Stream队列。非复制classic队列仍然存在(只是不再支持高可用)，其发展仍在继续。
• 提高了Classic队列的存储效率，尤其是恢复时间和 MB 级别消息的存储效率
• 如果节点启用了多个插件并且磁盘上的数据量较少，这些节点的启动速度会提高 20-30%。
• 增加了一种新的exchange 类型： Local Random Exchange，它主要用于RPC的场景。

二、重大变更和兼容性说明:

1.Classic 队列现在是非复制队列类型（不再支持Mirror Queue）:

在被弃用三年后，classic queue mirroring 在本版本中被完全删除。Quorum 和Stream 队列是RabbitMQ 4.x提供的两种成熟的复制队列(高可用队列)。请注意，只是弃用了Mirror，Classic 队列将继续得到支持，并像以前一样工作，但它只有一个数据副本。对客户端库和应用程序没有任何重大变更，但它们现在是非复制队列类型。

2.Quorum队列对消息的重试，现在有了默认的retry限制。

Quorum队列的消息现在具有默认的retry限制，默认值为20次。重试20次或以上的消息将被标记为死信或丢弃（删除）。此限制对于保护RabbitMQ服务节点免于陷入无限的故障消息重排是很必要的。

3.对 AMQP 0.9.1 协议的 x-death header进行了调整

从 RabbitMQ 4.x 开始，当客户端重新发布消息时，RabbitMQ 不会再自动解释和更新 x-death header 中的内容。这一变更使得消息的重新发布更符合预期的“新消息”状态。

4.对Classic Queue 的存储层进行了改进，移除了CQv1（第一代经典队列存储层）的实现。

RabbitMQ v4.x 中移除了过时的CQv1存储实现，所有经典队列默认使用更稳定和高效的 CQv2。任何依赖 CQv1 的旧配置将导致节点无法启动，需更新配置文件以启用 CQv2。

5.下列参数被移除：

cluster_formation.randomized_startup_delay_range.min
cluster_formation.randomized_startup_delay_range.max

这些设置用于定义节点启动时的随机延迟时间，以减少集群启动时的负载峰值。例如，通过设置一个最小和最大延迟时间范围，不同节点会在该范围内随机选择一个延迟时间进行启动，这样可以避免所有节点同时启动带来的瞬时负载增加。从 v4.0 开始，这些设置被移除，不再支持。

6.移除了磁盘 I/O 的内部指标监控，建议用户在基础设施层或内核层对磁盘 I/O 进行监控，以更精确地管理 RabbitMQ 的性能。

7.默认的最大消息大小被从 128 MiB 降低到了 16 MiB。

用户仍然可以通过 rabbitmq.conf 文件的 max_message_size 参数来调整消息大小限制。

8.关于 AMQP 1.0 的变更:

• 在 RabbitMQ 3.13 及之前版本中，rabbitmq_amqp1_0.default_vhost 设置用于指定 AMQP 1.0 客户端的默认虚拟主机。在 RabbitMQ 4.0 中，该配置已被移除，改为使用通用的 default_vhost 设置。
• AMQP 1.0 客户端在发送消息时需确保注解键使用符合新规则的自定义键（例如以 x- 开头的键），否则 RabbitMQ 将拒绝该消息。请检查你的 AMQP 1.0 客户端代码，确保所有自定义注解键都以 'x-' 开头。

9.针对 MQTT 和 AMQP 1.0 的匿名登录设置方式有所更改：

RabbitMQ 4.0 移除了 MQTT 和 AMQP 1.0 的默认用户配置，改用 anonymous_login_user 和 anonymous_login_pass 设置匿名登录的默认凭据。对于生产环境，建议禁用匿名登录，以提升安全性。

10.随着 Erlang 26 的引入，默认启用了 TLS 客户端的证书链验证，以提高连接的安全性。

如果不需要 TLS 证书链验证，也可以在相关配置中禁用

11.Shovel 插件的功能和兼容性进行了更新

RabbitMQ 4.0 中，Shovel 插件可以通过 AMQP 1.0 协议连接到 v4.0 节点，但需要 Shovel 版本 >= 3.13.7。此外，启用 TLS 的 Shovel 插件在默认情况下会进行证书链验证，用户可以根据实际需求配置是否禁用此验证。

三、Erlang/OTP兼容性注意事项：

RabbitMQ 不能与Erlang/OTP 27.0 兼容

Erlang/OTP 27.0 于 2024 年 5 月 20 日发布。虽然它包含许多令人兴奋的功能和改进，但不幸的是 RabbitMQ 目前无法很好地与此版本配合使用。RabbitMQ研发团队发现 Erlang 27 的性能存在显著下降，在许多常见工作负载中消息吞吐量降低了 30％。目前请不要将 Erlang/OTP 27 与 RabbitMQ 一起使用。

(上面文章参考了RabbitMQ blog以及github的releases说明，转发请注明出处和作者)

Tags：rabbitmq配置