RabbitMQ 3.10 性能改进

RabbitMQ 3.10 已于 2022 年 5 月 3 日发布，具有许多新功能和改进。本文概述了该版本中的性能改进。简而言之，您可以期待更高的吞吐量、更低的延迟和更快的节点启动速度，尤其是在启动时导入大型定义文件的情况下。

概述

首先，请查看 3.10 版本发布概览博客文章，了解该版本新功能的总体情况。在此，我们将仅关注性能改进以及对性能有影响的功能。本文涵盖的部分改进已向后移植到 3.9.x 版本，因此为了展示差异，我们将以 3.9.0 作为参考点。

如果您暂时无法升级到 3.10，请确保至少运行最新的 3.9.x 补丁版本，以便利用这些优化。

RabbitMQ 3.9 与 3.10 的对比

让我们在几个不同的场景中比较 RabbitMQ 3.9 和 3.10。请记住，这些是特定的基准测试，可能无法反映您的工作负载的性质和性能。

您可以使用 RabbitMQ 负载测试工具 perf-test 和 stream-perf-test 自行运行这些测试或类似的测试。

环境

这些测试是在以下环境下执行的

• 一个带有 e2-standard-16 节点的 GKE 集群
• 使用我们的 Kubernetes Operator 部署的 RabbitMQ 集群，配置及资源如下

apiVersion: rabbitmq.com/v1beta1
kind: RabbitmqCluster
metadata:
  name: ...
spec:
  replicas: 1 # or 3
  image: rabbitmq:3.10.1-management # or rabbitmq:3.9.0-management
  resources:
    requests:
      cpu: 8
      memory: 16Gi
    limits:
      cpu: 8
      memory: 16Gi
  persistence:
    storageClassName: premium-rwo
    storage: "3000Gi"
  rabbitmq:
    advancedConfig: |
      [
      {rabbit, [
          {credit_flow_default_credit,{0,0}}
      ]}
      ].

关于环境的一些说明

1. 对于许多测试（甚至是生产工作负载），这些资源设置过高。然而，这是我们团队进行 RabbitMQ 负载测试的标准配置。
2. 使用更好的硬件（包括在 Google Cloud 中），您应该能够达到更高的数值。
3. 禁用了信用流控（credit flow），因为否则单个快速发布者会受到限制（以防止过载并给其他发布者公平的机会），这在生产环境中是正确的做法，但在服务器负载测试中则没有意义。

场景 1：一个队列，快速发布者和消费者

在第一个场景中，我们将仅使用 1 个队列，配备 2 个发布者和 2 个消费者。我们将测试 10、100、1000 和 5000 字节的消息大小。

我们使用 2 个发布者，因为在某些配置中，单个发布者无法完全利用队列，特别是在消息非常小的情况下。请注意，RabbitMQ 3.11（当前在 master 分支中）已经有了一些路由效率改进，因此未来的版本可能不会出现这种情况。

在此工作负载中使用了以下 perf-test 标志

# classic queues (with an exactly=3 mirroring policy where applicable)
perf-test --producers 2 --consumers 2 --confirm 3000 --multi-ack-every 3000 --qos 3000 \
          --variable-size 10:900 --variable-size 100:900 --variable-size 1000:900 --variable-size 5000:900 \
          --auto-delete false --flag persistent --queue cq

# quorum queues
perf-test --producers 2 --consumers 2 --confirm 3000 --multi-ack-every 3000 --qos 3000 \
          --variable-size 10:900 --variable-size 100:900 --variable-size 1000:900 --variable-size 5000:900 \
          --quorum-queue --queue qq

场景 1：1 个队列，2 个发布者和 2 个消费者；消息大小为 10、100、1000 和 5000 字节（每个阶段 15 分钟）

观察结果

• 仲裁队列（quorum queues）的吞吐量比传统的镜像队列（CMQs）高出几倍
• 在某些场景中，3.10 中的仲裁队列吞吐量甚至可以提高 50%
• 在某些场景中，经典队列 v2 已经比 v1 表现更好
• CMQ 不会有任何新的改进，并将在 RabbitMQ 4.0 中被移除；请在适当时迁移到仲裁队列、流（streams）或非镜像经典队列

场景 2：一个队列，10000 条消息/秒

在上一个场景中，RabbitMQ 中的一些代码路径始终处于或接近其最大速度。这次，我们将设定 10000 条消息/秒的固定目标吞吐量，并随着消息大小随时间增加，比较不同环境是否能够维持这种工作负载。

由于预期吞吐量已知，我们将重点测量延迟及其波动性。

在此场景中使用了以下 perf-test 标志

# classic queues (with an exactly=3 mirroring policy where applicable)
perf-test --rate 10000 --confirm 3000 --multi-ack-every 3000 --qos 3000 \
          --variable-size 10:900 --variable-size 100:900 --variable-size 1000:900 --variable-size 5000:900 \
          --auto-delete false --flag persistent --queue cq

# quorum queues
perf-test --rate 10000 --confirm 3000 --multi-ack-every 3000 --qos 3000 \
          --variable-size 10:900 --variable-size 100:900 --variable-size 1000:900 --variable-size 5000:900 \
          --quorum-queue --queue qq

再次证明，仲裁队列以绝对优势胜过传统的镜像队列（CMQs）

场景 2：1 个队列，1 个发布者和 1 个消费者；消息大小为 10、100、1000 和 5000 字节（每个阶段 15 分钟）

让我们放大查看非镜像经典队列，以比较 v1 和 v2 的消息存储和队列索引实现。我们可以看到 CQv2 提供了更低且更一致的延迟

场景 2：1 个队列，1 个发布者和 1 个消费者；消息大小为 10、100、1000 和 5000 字节（每个阶段 15 分钟）

单节点仲裁队列 3.9 和 3.10 在此测试中的表现非常相似（见第一个图表的图例）。让我们重点关注 3 节点集群

场景 2：1 个队列，1 个发布者和 1 个消费者；消息大小为 10、100、1000 和 5000 字节（每个阶段 15 分钟）

如您所见，3.10 版本的仲裁队列提供了显著更低且更一致的延迟。由于某些仲裁队列操作的批处理或周期性特性，仍然存在尖峰。这是未来版本需要改进的一个领域。

场景 3：500 个队列，总计 5000 条消息/秒

在此场景中，我们将拥有 500 个队列，每个队列有 1 个发布者以每秒 10 条消息的速度发布，并有一个消费者消费这些消息。因此，总预期吞吐量为每秒 5000 条消息。我们再次运行此场景一小时，每 15 分钟更改一次消息大小（10、100、1000 和 5000 字节）。

# classic queues (with an exactly=3 mirroring policy where applicable)
perf-test --producers 500 --consumers 500 --publishing-interval 0.1 --confirm 10 --multi-ack-every 100 --qos 100 \
          --variable-size 10:900 --variable-size 100:900 --variable-size 1000:900 --variable-size 5000:900 \
          --queue-pattern cq-%d --queue-pattern-from 1 --queue-pattern-to 500 \
          --auto-delete false --flag persistent

# quorum queues
perf-test --producers 500 --consumers 500 --publishing-interval 0.1 --confirm 10 --multi-ack-every 100 --qos 100 \
          --variable-size 10:900 --variable-size 100:900 --variable-size 1000:900 --variable-size 5000:900 \
          --quorum-queue --queue-pattern qq-%d --queue-pattern-from 1 --queue-pattern-to 500

场景 3：500 个队列，1 个发布者，1 个消费者，每个队列 10 条消息；消息大小为 10、100、1000 和 5000 字节（每个阶段 15 分钟）

观察结果

1. 只有 CMQ 难以维持预期的 5000 条消息/秒的吞吐量
2. 经典队列 v2 在整个测试中具有最低且最一致的延迟
3. 3.9.0 CMQ 环境的发布延迟极高；我没有调查原因，建议直接使用仲裁队列或流！

由于经典队列，特别是镜像的 3.9.0 环境，在图表中占主导地位，这里是同一图表，但重点放在经典队列 v2 和 3.10 仲裁队列上

场景 3：仅 3.10 环境

如上所述，仲裁队列的延迟不如我们希望的那样一致，但大多数时候它们保持在 25ms 以内。这还是在 500 个队列、总计 5000 条消息/秒的情况下，使用 10/100/1000 字节消息，使用 5000 字节消息时也不会高出太多。

对于 3 节点仲裁队列，这是一个退化的（边界情况）集群，所有队列领导者和所有连接都在单个节点上。这是刻意为之，以便使测试结果在不同运行之间以及单节点和 3 节点集群之间更具可比性。

场景 4：长仲裁队列

在 3.10 之前，仲裁队列在较长时表现不佳——为消费者检索最早的消息是一项昂贵的操作。在此场景中，我们将首先使用 2 个发布者发布 1000 万条消息，然后使用两个消费者消耗掉所有消息。

# publish 10 milion messages
perf-test --producers 2 --consumers 0 --confirm 3000 --pmessages 5000000 \
          --queue-args x-max-in-memory-length=0 --quorum-queue --queue qq

# consume 10 milion messages
perf-test --producers 0 --consumers 2 --multi-ack-every 3000 --qos 3000 --exit-when empty \
          --queue-args x-max-in-memory-length=0 --quorum-queue --queue qq

请注意，从 3.10 开始，仲裁队列忽略 x-max-in-memory-length 属性。它仍然可以通过策略进行配置，但不会产生任何效果——队列的行为将表现得如同将其设置为 0 一样。

场景 4：发布并消耗 1000 万条消息

观察结果

1. 在 3.10.1 中，发布和消耗消息的时间大致相同（每个过程约 3 分钟）
2. 3.9.0 需要两倍的时间来发布消息（约 6 分钟）
3. 单节点 3.9.1 需要近 15 分钟来清空队列，而 3 节点集群则需要额外 2 分钟
4. 两个 3.9 实例开始时的消费速度约为 10000 条消息/秒，并随时间缓慢提高。3 节点 3.9.0 集群的消费率在最后阶段（当队列较短时）显著增加

值得注意的是 3.9 发布者图表（橙色线）中的两次下降。集群触发了内存报警，因此发布者被暂时阻塞。这在 3.10 环境中没有发生，尽管 3.10 当时执行的工作更多（发布和消费速度更快）。

3.10 中的仲裁队列平均比经典队列使用更多的内存，因为它们在内存中保留了有关消息的元数据，但它们比 3.9 中使用的内存要少。

以下是执行大部分工作（托管所有队列领导者和所有连接）的两个节点之间的直接比较

场景 4：发布并消耗 1000 万条消息，内存使用情况

更快的导入和声明

对于那些在启动时导入定义的用户，升级到 3.10 后节点启动所需的时间应该会减少。导致这种情况有多种变更和功能，预期的行为取决于您的定义，以及您使用和将要使用/配置的功能。摘要如下

1. 如果您使用 load_definitions 配置选项，并且 JSON 文件中有许多定义，那么无需任何操作，节点应该能够更快地启动。对于拥有数千个队列的用户，这可以在每次节点启动时节省数分钟。这里的主要区别在于，在 3.10 中，重新声明已存在的实体应该会快得多。集群中的节点通常共享相同的配置文件，因此每个节点都会尝试相同的导入，但除第一个节点之外的所有节点实际上都会重新导入现有实体。在节点重启时，假设您没有删除这些实体，所有节点都可以更快地引导。

2. 如果您设置了一个新属性 definitions.skip_if_unchanged = true，如果定义文件的校验和与之前导入时相同，RabbitMQ 将完全跳过导入。对于拥有大型定义文件的集群，这可以为每个节点节省数分钟。这与上一点类似，除了您需要选择加入（设置属性），而且加速效果甚至更高，因为不尝试导入显然比检查实体是否已经存在更快。

其他改进

Erlang 25

此版本支持 Erlang 25，它引入了许多编译器和运行时效率改进。这在 64 位 ARM CPU 上最为明显，因为 Erlang 25 中的 JIT 现在支持该架构。

引导时定义导入

在节点引导时导入定义的集群中，实际上集群中的每个节点都会导入相同的定义，因为所有节点使用相同或几乎相同的配置文件。

根据事件的确切时间，这通常会导致以下两个问题之一

• 如果节点逐个启动，所有队列通常最终会位于单个节点上，因为在导入时集群中只有一个节点
• 如果节点并行启动，则存在大量竞争，多个节点尝试声明相同的定义

在 RabbitMQ 3.10 中，许多重新导入优化通常有助于解决第二个问题。

此外，cluster_formation.target_cluster_size_hint 是一个新设置，现在可以设置它来告诉 RabbitMQ 集群完全形成后预计会有多少个节点。

有了这些额外信息，只有最后一个加入集群的节点才会导入定义。主要的好处是仲裁队列应该在节点之间很好地平衡（取决于领导者放置设置）。过去，如果导入在第一个节点启动时就立即进行，其他节点实际上会空启动，因为所有队列在它们启动时就已经在运行了。

结论

RabbitMQ 3.10 中发布了许多改进，其中一些也已向后移植到最近发布的 3.9 补丁版本中。

我们一直在寻找让事情变得更快的方法。然而，RabbitMQ 可以以多种不同的方式配置和使用，许多改进是针对特定工作负载的。我们非常感谢您的帮助——如果您希望 RabbitMQ 在某种场景下更快，请联系并告诉我们您的工作负载。理想情况下，如果您能用 perf-test 重现问题，我们将很高兴看看我们能做些什么来提高吞吐量、降低延迟或减少内存使用。