Quorum 队列以及磁盘为何重要

2020年4月21日 ·13 分钟阅读

Jack Vanlightly

Quorum 队列对于 RabbitMQ 来说仍然相对较新，许多人仍然没有从经典镜像队列迁移过来。在您迁移到这种新型队列之前，您需要确保您的硬件能够支持您的工作负载，而一个重要因素是您使用的存储驱动器。

在这篇博文中，我们将更仔细地研究 Quorum 队列及其在不同存储配置上的性能特征。

HDD 还是 SSD？单驱动器还是多驱动器？

简而言之，我们强烈建议在使用 Quorum 队列时使用 SSD。原因是 Quorum 队列对 IO 延迟敏感，而 SSD 提供的 IO 延迟比 HDD 更低。较高的 IO 延迟会导致较低的吞吐量、较高的端到端延迟以及其他一些不良影响。

在本文的后面部分，我们将通过使用各种具有不同 SSD 和 HDD 配置的基准测试来演示我们为什么提出此建议。

为什么 Quorum 队列对 IO 延迟敏感？

让我们看一下单个 broker 上的写入路径，以了解为什么会这样。请记住，发布和消费都算作写入。发布涉及入队操作，消费涉及确认操作，两者都必须持久化和复制。请注意，如果您使用 Quorum 或镜像队列时没有发布者确认或消费者确认，您需要问问自己为什么要使用复制队列。

操作首先写入内存和一个预写日志 (WAL)。每个 broker 都有一个 WAL，它服务于该 broker 上的所有 Quorum 队列。从那里，操作然后由段写入器写入每个队列的段文件。

Fig 1. WAL and segment files — 图 1. WAL 和段文件

然而，有一种优化意味着入队操作（消息）可能永远不需要写入段文件。新到达的消息保存在内存中，消息可以在写入段文件之前传递给消费者并被确认。在这种情况下，这些消息不会写入磁盘，因为就 broker 而言，它们实际上已不复存在。

这意味着对于消费者保持同步的队列，消息通常根本不会写入段文件。当内存中的消息准备好刷新到段文件时，消费者已经确认了该消息。如果 IO 延迟很高，那么 WAL 最终会成为瓶颈。每个 broker 都有一个 WAL 和一个段写入器进程，这些进程充当 Quorum 队列 Raft 集群所依赖的共享基础设施。将操作 fsync 到活动 WAL 文件就像 Raft 集群跳动的心脏。如果 fsync 速度慢，则 Raft 集群的吞吐量就会慢。

段文件的 Fsync 也可能成为瓶颈。WAL 由一个或多个文件组成；一个文件正在被主动写入，零个或多个非活动文件由于达到最大 WAL 文件大小限制而被滚动。只有当所有消息都已写入段文件和/或被确认（参见上面的优化）后，这些非活动 WAL 文件才能安全地删除。如果段文件的写入速度很慢，那么 WAL 会变得越来越大，因为消息无法足够快地写入段文件。

HDD 在大型顺序写入方面非常出色，但在小型或随机 IO 方面则不然。如果您的写入必须访问多个文件，在文件系统之间跳转，那么 HDD 会产生比 SSD 高得多的 IO 延迟。WAL 和段文件的优点在于它们是仅追加文件。因此，HDD 有可能提供不错的性能，但前提是没有大量的随机 IO 争用。一旦 WAL 和段文件 IO 必须与其他磁盘 IO 竞争，性能就会开始下降。

好的，但是 HDD 的性能如何呢？

现在我们将使用 SSD 和 HDD 运行一些性能基准测试，并分析结果。

有四个主要参与者使用磁盘

Mnesia 和消息存储（数据）
日志（logs）
Quorum 队列段文件 (segment)
Quorum 队列 WAL (wal)

这些工作负载中的每一个都具有不同的 IO 模式，我们可以尝试隔离这些磁盘工作负载以提高性能。

我们有六个集群共享某些方面，例如 CPU 数量，但使用不同类型和数量的磁盘。

共享

3 节点集群
实例类型：c4.4xlarge
- 16 个 vCPU
- 15GB 内存
- 2Gbps EBS 实例吞吐量（VM 的磁盘 IO 吞吐量上限为 2Gbps/250MBs）
- 5Gbps 网络 (625MB/s)

所有磁盘均为 200GB SSD (io1) 或 1TB HDD (st1)。每个磁盘都具有比 c4.4xlarge EC2 实例可以使用的更大的吞吐量容量。

独特

将所有数据存储在单个驱动器中
- 集群 rabbitmq1, SSD1=data/logs/segment/wal
- 集群 rabbitmq10, HDD1=data/logs/segment/wal
将 WAL 存储在单独的驱动器上，但将段文件存储在与经典队列数据相同的驱动器上
- 集群 rabbitmq4, SSD1=data/logs/segment SSD2=wal
- 集群 rabbitmq13, HDD1=data/logs/segment HDD2=wal
为经典队列数据、段文件和 WAL 文件分别分配其自己的专用驱动器
- 集群 rabbitmq7, SSD1=data/logs SSD2=segment SSD3=wal
- 集群 rabbitmq16, HDD1=data/logs HDD2=segment HDD3=wal

纯 Quorum 队列工作负载

首先，我们将测试仅由 Quorum 队列组成的工作负载。

吞吐量基准测试 #1 - 一个 Quorum 队列

一个发布者，一个队列，一个消费者，1kb 消息，无速率限制。

Fig 1. Pure quorum queue workload - 1 queue — 图 1. 纯 Quorum 队列工作负载 - 1 个队列

我们看到 SSD 集群 rabbitmq1、rabbitmq4 和 rabbitmq7 都达到了大约 19k msg/s。HDD 集群的吞吐量较低，其中 rabbitmq13（2 个磁盘）和 rabbitmq16（3 个磁盘）仅略微落后，约为 17k msg/s。单 HDD 集群明显落后，约为 13k msg/s。

结论

对于单个队列工作负载，将 WAL 从段文件工作负载分离到单独的磁盘上，使我们获得了接近 SSD 的性能。

吞吐量基准测试 #2 - 四个 Quorum 队列

4 个发布者，4 个队列，4 个消费者，1kb 消息，无速率限制。

Fig 2. Pure quorum queue workload - 4 queues — 图 2. 纯 Quorum 队列工作负载 - 4 个队列

对于 4 个 Quorum 队列，我们看到了不同的情况。HDD 的性能优于其 SSD 同类产品约 2k msg/s。我们必须记住，当消费者可以跟上时，操作通常只写入 WAL 文件。WAL 在四个队列之间共享，因此我们正在通过它推送更多字节。WAL 文件是顺序写入的，我们的 st1 HDD 可以管理 500MB/s 的吞吐量（尽管 VM 本身限制为 250MB/s）。

结论

在只有顺序写入的世界中，HDD 有可能产生与 SSD 相似甚至更好的结果。只有 Quorum 队列的工作负载，在消费者保持同步的情况下，应该看到绝大多数写入只进入单个仅追加 WAL 文件。

延迟基准测试 #1 - 40 个 Quorum 队列

40 个发布者，40 个队列，40 个消费者，1kb 消息，每个发布者 10 msg/s（总共 400 msg/s）。

SSD

Fig 3. Pure quorum queue workload - Latency Test 1 - SSD — 图 3. 纯 Quorum 队列工作负载 - 延迟测试 1 - SSD

HDD

Fig 4. Pure quorum queue workload - Latency Test 1 - HDD — 图 4. 纯 Quorum 队列工作负载 - 延迟测试 1 - HDD

在每秒仅 400 个 1kb 消息的总速率下，我们看到 SSD 和 HDD 具有相当的端到端延迟。

延迟基准测试 #2 - 40 个 Quorum 队列

40 个发布者，40 个队列，40 个消费者，1kb 消息，每个发布者 50 msg/s（总共 2000 msg/s）。

Fig 5. Pure quorum queue workload - Latency Test 2 - SSD — 图 5. 纯 Quorum 队列工作负载 - 延迟测试 2 - SSD

HDD

Fig 6. Pure quorum queue workload - Latency Test 2 - HDD — 图 6. 纯 Quorum 队列工作负载 - 延迟测试 2 - HDD

这次我们看到 HDD 的延迟明显更高

第 75 百分位数 ~4ms vs ~15ms
第 99.9 百分位数 ~20ms vs ~110ms

我们还看到双磁盘和三磁盘 HDD 配置的延迟低于单 HDD。双磁盘和三磁盘配置之间没有太大差异，因为我们没有 mnesia 或消息存储数据与 Quorum 段数据竞争。

结论

在更高的吞吐量下，我们看到 SSD 产生的延迟比 HDD 低得多。