5 篇关于“容量规划”的文章

在上一篇文章中，我们开始了对使用法定人数队列的工作负载的规模分析。我们专注于消费者能够跟上速度的理想场景，这意味着没有队列积压，并且集群中的所有代理都正常运行。通过运行一系列模拟不同强度工作负载的基准测试，我们确定了按每月每 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，我们不如提供一些一般准则，并使用案例研究来展示您应该考虑的事项。