团队最近被问到，鉴于一致性队列会在可能的情况下从本地队列副本（领导者或跟随者）投递消息，它们是否以及如何提供与经典队列相同的保证。镜像队列始终从主节点（领导者）投递，因此从任何队列副本投递似乎会影响这些保证。

这就是本文的主题。请注意，本文是对好奇者和分布式系统爱好者的技术深度探讨。我们将探讨一致性队列如何能够从任何队列副本（领导者或跟随者）投递消息，而无需额外的协调（Raft 之外），同时保持消息排序保证。

在上一篇文章中，我们开始了对使用一致性队列的工作负载的规模分析。我们专注于消费者能够跟上的理想场景，这意味着没有队列积压，并且集群中的所有代理都正常运行。通过运行一系列模拟不同强度工作负载的基准测试，我们确定了按每月每 1000 条消息/秒的成本计算的前 5 个集群规模和存储容量组合。

1. 集群：7 个节点，8 个 vCPU（c5.2xlarge），gp2 SSD。成本：54 美元
2. 集群：9 个节点，8 个 vCPU（c5.2xlarge），gp2 SSD。成本：69 美元
3. 集群：5 个节点，8 个 vCPU（c5.2xlarge），st1 HDD。成本：93 美元
4. 集群：5 个节点，16 个 vCPU（c5.4xlarge），gp2 SSD。成本：98 美元
5. 集群：7 个节点，16 个 vCPU（c5.4xlarge），gp2 SSD。成本：107 美元

需要运行更多测试以确保这些集群能够处理诸如代理故障和在停机或系统速度下降期间积累的大量积压等情况。

所有一致性队列都使用以下属性声明

• x-quorum-initial-group-size=3
• x-max-in-memory-length=0

x-max-in-memory-length 属性强制一致性队列在安全的情况下立即从内存中删除消息体。您可以将其设置为更长的限制，这是最激进的设置 - 旨在避免内存的大量增长，但代价是在消费者无法跟上的情况下进行更多磁盘读取。如果没有此属性，消息体将始终保存在内存中，这可能会导致内存增长到触发内存警报的程度，从而严重影响发布率 - 在此工作负载案例研究中我们希望避免这种情况。

在本规模系列的第一篇文章中，我们介绍了工作负载、测试以及 AWS ec2 上的集群和存储容量配置。在本篇文章中，我们将使用一致性队列运行规模分析。我们还对镜像队列进行了规模分析。

在本篇文章中，我们将运行强度递增的测试，这些测试将在理想条件下测量我们候选集群规模在不同发布速率下的性能。在下一篇文章中，我们将运行弹性测试，以衡量我们的集群在不利条件下是否能够处理我们的目标峰值负载。

所有一致性队列都使用以下属性声明

• x-quorum-initial-group-size=3（复制因子）
• x-max-in-memory-length=0

x-max-in-memory-length 属性强制一致性队列在安全的情况下立即从内存中删除消息体。您可以将其设置为更长的限制，这是最激进的设置 - 旨在避免内存的大量增长，但代价是在消费者无法跟上的情况下进行更多磁盘读取。如果没有此属性，消息体将始终保存在内存中，这可能会导致内存增长到触发内存警报的程度，从而严重影响发布率 - 在此工作负载案例研究中我们希望避免这种情况。

在上一篇文章中，我们开始了对使用镜像队列的工作负载的规模分析。我们专注于消费者能够跟上的理想场景，这意味着没有队列积压，并且集群中的所有代理都正常运行。通过运行一系列模拟不同强度工作负载的基准测试，我们确定了按每月每 1000 条消息/秒的成本计算的前 5 个集群规模和存储容量组合。

1. 集群：5 个节点，8 个 vCPU，gp2 SSD。成本：58 美元
2. 集群：7 个节点，8 个 vCPU，gp2 SSD。成本：81 美元
3. 集群：5 个节点，8 个 vCPU，st1 HDD。成本：93 美元
4. 集群：5 个节点，16 个 vCPU，gp2 SSD。成本：98 美元
5. 集群：9 个节点，8 个 vCPU，gp2 SSD。成本：104 美元

需要运行更多测试以确保这些集群能够处理诸如代理故障和在停机或系统速度下降期间积累的大量积压等情况。

在本规模系列的第一篇文章中，我们介绍了工作负载、AWS ec2 上的集群和存储容量配置。在本篇文章中，我们将使用镜像队列运行规模分析。

规模分析的第一阶段将评估我们的每个集群和存储容量能够轻松处理哪些强度，以及哪些强度过大。

所有测试都使用以下策略

• ha-mode: exactly
• ha-params: 2
• ha-sync-mode: manual

这是我们系列文章的开始，我们将探讨如何调整 RabbitMQ 集群的规模。实际的规模完全取决于您的硬件和工作负载，因此，与其告诉您应该配置多少个 CPU 和多少 RAM，不如创建一些通用准则并使用案例研究来展示您应该考虑的事项。

进行基准测试可能有许多原因

• 规模和容量规划
• 产品评估（RabbitMQ 能否处理我的负载？）
• 发现适合您工作负载的最佳配置

在本篇文章中，我们将了解运行 RabbitMQ 基准测试的各种选项。但在我们开始之前，您需要一种查看结果并查看系统指标的方法。

关于一致性队列的网络研讨会​

在我们开始介绍 RabbitMQ 项目和 4 月份的社区更新之前，我们有一个网络研讨会要宣布！RabbitMQ 核心团队成员 Jack Vanlightly 将于 2020 年 6 月 11 日在消息传递中的高可用性和数据安全中进行介绍。

在此网络研讨会中，Jack Vanlightly 将解释一致性队列，这是 RabbitMQ 中一种新的复制队列类型。一致性队列在 RabbitMQ 3.8 中引入，重点关注数据安全以及从节点故障中高效、可预测地恢复。Jack 将介绍并对比一致性队列和经典镜像队列的设计。

参加完此网络研讨会后，您将了解

• 为什么一致性队列提供比镜像队列更好的数据安全
• 从镜像队列切换到一致性队列时，服务器资源使用情况如何以及为什么发生变化
• 使用一致性队列的一些最佳实践

在上一篇文章中，我们对单个队列进行了一些简单的基准测试，以了解管道发布者确认和消费者确认对流量控制有何影响。

具体来说，我们研究了

• 发布者：限制未完成消息的数量（已发送但正在等待确认的消息）。
• 消费者：预取（代理在通道上允许的未完成消息的数量）
• 消费者：确认间隔（多标志使用）

不出所料，我们看到当我们将发布者和代理限制为一次少量未完成消息时，吞吐量很低。当我们增加此限制时，吞吐量增加了，但仅增加到一定程度，之后我们没有看到更多吞吐量增长，而是看到了延迟增加。我们还看到，允许消费者使用多标志有利于吞吐量。

在本篇文章中，我们将研究这三个相同设置，但使用许多客户端、许多队列和不同数量的负载，包括压力测试。我们将看到发布者确认和消费者确认在流量控制中发挥作用，以帮助防止代理过载。

在上一篇文章中，我们介绍了什么是流量控制，既包括作为一般概念的流量控制，也包括 RabbitMQ 中可用的各种流量控制机制。我们看到发布者确认和消费者确认不仅仅是数据安全措施，而且在流量控制中也发挥着作用。

在本篇文章中，我们将研究应用程序开发人员如何在单个队列的上下文中使用发布者确认和消费者确认来平衡安全性和高性能。

当代理过载时，流量控制变得尤为重要。单个队列不太可能使您的代理过载。如果您发送大型消息，那么当然，您可以饱和您的网络，或者如果您只有一个 CPU 内核，那么一个队列可能会将其最大化。但我们大多数人都在使用 8 个、16 个或 30 多个内核的机器。但分解确认和确认对单个队列的影响很有趣。从那里，我们可以吸取教训，看看它们是否适用于更大的部署（下一篇文章）。