在本系列的第一篇帖子中，我们介绍了工作负载、测试以及 AWS ec2 上的集群和存储卷配置。在这篇文章中，我们将使用 Quorum 队列运行大小调整分析。我们还对镜像队列进行了大小调整分析。
在这篇文章中，我们将运行增加强度测试，以在理想条件下测量不同发布速率下的候选集群大小。在下一篇文章中，我们将运行弹性测试，以衡量我们的集群是否可以在不利条件下处理我们的目标峰值负载。
所有 Quorum 队列都使用以下属性声明
x-max-in-memory-length 属性强制 Quorum 队列在安全时立即从内存中删除消息体。您可以将其设置为更长的限制，这是最激进的 - 旨在避免内存大量增长，但代价是当消费者跟不上时需要进行更多磁盘读取。如果没有此属性，消息体将始终保存在内存中，这会导致内存增长到触发内存警报的程度，从而严重影响发布速率 - 这是我们希望在本工作负载案例研究中避免的情况。
在上一篇文章中，我们开始了使用镜像队列对我们的工作负载进行大小调整分析。我们专注于消费者跟得上的理想情况，这意味着没有队列积压，并且集群中的所有代理都正常运行。通过运行一系列模拟不同强度工作负载的基准测试，我们确定了每 1000 msg/s 每月成本方面排名前 5 的集群大小和存储卷组合。
还需要进行更多测试，以确保这些集群可以处理诸如代理故障和在中断或系统减速期间累积大量积压等情况。
在本系列的第一篇帖子中，我们介绍了 AWS ec2 上的工作负载、集群和存储卷配置。在这篇文章中，我们将使用镜像队列运行大小调整分析。
我们大小调整分析的第一阶段将是评估我们的每个集群和存储卷可以轻松处理哪些强度，以及哪些强度过高。
所有测试都使用以下策略
我们开始一个简短的系列，其中我们将研究 RabbitMQ 集群的大小调整。实际大小调整完全取决于您的硬件和工作负载，因此与其告诉您应该配置多少 CPU 和多少 RAM，不如我们创建一些通用指南并使用案例研究来展示您应该考虑哪些事项。
进行基准测试的原因有很多
在这篇文章中，我们将了解运行 RabbitMQ 基准测试的各种选项。但在我们这样做之前，您需要一种查看结果和查看系统指标的方法。
在上一篇文章中，我们对单个队列运行了一些简单的基准测试，以了解流水线发布者确认和消费者确认对流控制的影响。
具体来说，我们研究了
不出所料，我们看到当我们限制发布者和代理一次处理少量飞行中消息时，吞吐量很低。当我们增加该限制时，吞吐量增加，但仅增加到一定程度，之后我们没有看到更多的吞吐量增加，而是延迟增加。我们还看到，允许多个消费者使用标志对吞吐量有利。
在这篇文章中，我们将研究相同的三个设置，但使用许多客户端、许多队列和不同负载量，包括压力测试。我们将看到发布者确认和消费者确认在流控制中发挥作用，以帮助防止代理过载。
在上一篇文章中，我们介绍了什么是流控制，无论是作为一般概念还是 RabbitMQ 中可用的各种流控制机制。我们看到发布者确认和消费者确认不仅是数据安全措施，而且在流控制中也发挥作用。
在这篇文章中，我们将研究应用程序开发人员可以使用发布者确认和消费者确认来在单个队列的上下文中获得安全性和高性能的平衡。
当代理过载时，流控制变得尤为重要。单个队列不太可能使您的代理过载。如果您发送大型消息，那么当然，您可以饱和您的网络，或者如果您只有一个 CPU 核心，那么一个队列可能会将其最大化。但是我们大多数人都在使用 8、16 或 30+ 核机器。但是，分解确认和确认对单个队列的影响是很有趣的。从那里，我们可以吸取经验教训，看看它们是否适用于更大的部署（下一篇文章）。
作为我们 Quorum 队列系列的一部分，我们将了解流控制，它如何保护 RabbitMQ 免于过载，以及这与 Quorum 队列有何关系。
流控制是一个在计算机网络和网络软件中存在了几十年的概念。本质上，它是一种对发送者施加反压以避免接收者过载的机制。接收者通常缓冲传入的数据包/消息，以此来处理超过其处理速率的发送速率。但是，接收者缓冲区不能永远增长，因此发送速率应仅暂时超过接收者处理能力（突发流量），或者必须减慢发送者速度（反压）。
流控制是一种对发送者施加此反压的方式，减慢它们的速度，以便接收者的缓冲区不会溢出，并且延迟不会变得太大。在发送者/接收者链中，此反压可以沿链向上传播到流量的来源。在连接组件的复杂图中，流控制可以在快速和慢速发送者之间平衡传入流量，避免过载，但允许系统在不同数量的发送者、不同速率和不同负载模式（稳定或突发）的情况下实现充分利用。
Quorum 队列对于 RabbitMQ 来说仍然相对较新，许多人仍然没有从经典镜像队列过渡过来。迁移到这种新的队列类型，您需要确保您的硬件可以支持您的工作负载，而一个重要因素是您使用的存储驱动器。
在这篇博文中，我们将仔细研究 Quorum 队列及其在不同存储配置上的性能特征。
TL;DR 是，当使用 Quorum 队列时，我们强烈建议使用 SSD。原因是 Quorum 队列对 IO 延迟敏感，并且 SSD 提供比 HDD 更低的延迟 IO。较高的 IO 延迟，您将看到较低的吞吐量、较高的端到端延迟以及其他一些不良影响。
在本文的后面部分，我们将演示为什么我们推荐这样做，使用各种具有不同 SSD 和 HDD 配置的基准测试。
在这篇文章中，我们将介绍 RabbitMQ Java 客户端库如何收集运行时指标并将它们发送到 JMX 和 Datadog 等监控系统。