在上一篇文章中，我们开始了对我们的工作负载使用镜像队列进行规模分析。我们专注于消费者能够跟上速度的理想情况，这意味着没有队列积压，并且集群中的所有代理都正常运行。通过运行一系列模拟我们工作负载在不同强度下的基准测试，我们确定了每月每 1000 条消息/秒成本最低的前 5 个集群规模和存储卷组合。
需要进行更多测试以确保这些集群能够处理诸如代理故障和在停机或系统速度变慢期间积压大量消息等情况。
在本系列文章的第一篇文章中，我们介绍了工作负载、集群和 AWS ec2 上的存储卷配置。在这篇文章中，我们将运行一个使用镜像队列进行规模分析。
规模分析的第一阶段将评估我们的每个集群和存储卷能够轻松处理的强度，以及哪些强度过高。
所有测试都使用以下策略
这是我们探讨如何对 RabbitMQ 集群进行规模调整的简短系列的开始。实际规模完全取决于您的硬件和工作负载，因此我们不会告诉您应该配置多少个 CPU 和多少 RAM，而是会创建一些一般准则，并使用一个案例研究来展示您应该考虑的事项。
进行基准测试可能有许多原因
在这篇文章中，我们将探讨运行 RabbitMQ 基准测试的各种选项。但在我们开始之前，您需要一种方法来查看结果并查看系统指标。
在上一篇文章中，我们在单个队列上运行了一些简单的基准测试，以查看管道发布确认和消费者确认对流量控制的影响。
具体来说，我们查看了
不出所料，我们发现，当我们将发布者和代理限制为一次只有少量待处理消息时，吞吐量很低。当我们增加该限制时，吞吐量增加了，但仅增加到一定程度，之后我们没有看到更多吞吐量增加，而是出现了延迟增加。我们还发现，允许消费者使用多个标志对吞吐量有利。
在这篇文章中，我们将研究相同的三个设置，但使用多个客户端、多个队列和不同数量的负载，包括压力测试。我们将看到，发布者确认和消费者确认在流量控制中发挥作用，以帮助防止代理过载。
在上一篇文章中，我们介绍了什么是流量控制，既作为一般概念，也作为 RabbitMQ 中可用的各种流量控制机制。我们发现，发布者确认和消费者确认不仅是数据安全措施，而且在流量控制中也发挥作用。
在这篇文章中，我们将研究应用程序开发人员如何在单个队列的上下文中使用发布者确认和消费者确认来实现安全性和高性能之间的平衡。
当代理过载时，流量控制变得尤为重要。单个队列不太可能使您的代理过载。如果您发送大型消息，那么当然，您可以使网络饱和，或者如果您只有一个 CPU 内核，那么一个队列可能会将其最大化。但我们大多数人都在 8、16 或 30 多个内核的机器上。但有趣的是，要分解确认和确认对单个队列的影响。从那里，我们可以获取我们的经验教训，看看它们是否适用于更大的部署（下一篇文章）。
作为我们仲裁队列系列的一部分，我们将探讨流量控制，它是如何保护 RabbitMQ 免受过载的，以及这与仲裁队列的关系。
流量控制是一个概念，它在计算机网络和网络软件中已经存在了几十年。从本质上讲，它是一种机制，可以对发送者施加反向压力，以避免接收者过载。接收者通常会缓冲传入的数据包/消息，作为处理发送速率超过其处理速率的一种方法。但接收者缓冲区不能无限增长，因此发送速率应该只短暂地超过接收者处理能力（突发流量），或者发送者必须放慢速度（反向压力）。
流量控制是向发送者施加这种反向压力的方式，使其放慢速度，以便接收者的缓冲区不会溢出，延迟不会变得太大。在一个发送者/接收者链中，这种反向压力可以向上游传播到流量的来源。在更复杂的连接组件图中，流量控制可以在快速和慢速发送者之间平衡传入流量，避免过载，但允许系统达到完全利用率，尽管发送者数量不同、速率不同以及负载模式不同（稳定或突发）。
仲裁队列对于 RabbitMQ 来说仍然是相对较新的，许多人还没有从经典的镜像队列中迁移过来。在您迁移到这种新的队列类型之前，您需要确保您的硬件能够支持您的工作负载，而其中一个重要因素是您使用的存储驱动器。
在这篇博文中，我们将更深入地了解仲裁队列及其在不同存储配置下的性能特征。
简而言之，我们强烈建议在使用仲裁队列时使用 SSD。原因是仲裁队列对 IO 延迟很敏感，而 SSD 比 HDD 提供更低的延迟 IO。对于更高的 IO 延迟，您将看到更低的吞吐量、更高的端到端延迟以及其他一些不良影响。
在这篇文章的后面，我们将使用具有不同 SSD 和 HDD 配置的各种基准测试来演示我们为什么推荐这样做。
在这篇文章中，我们将介绍 RabbitMQ Java 客户端库如何收集运行时指标并将它们发送到 JMX 和 Datadog 等监控系统。
RabbitMQ 团队很高兴宣布发布HOP 2.0 版本，这是 RabbitMQ HTTP API 的 Java 和其他 JVM 语言客户端。这个新版本引入了基于Spring Framework 5.0 WebFlux 的新响应式客户端。