本月，Jack Vanlightly 继续了他关于 RabbitMQ 仲裁队列 的博客系列。此外，请务必观看他 相关的网络研讨会 回放。

最后，《TGI RabbitMQ》第五集上线——Gerhard Lazu 将带我们了解 如何在 Kubernetes 上运行 RabbitMQ。不容错过！

团队最近被问到，鉴于仲裁队列在可能的情况下会从本地队列副本（leader 或 follower）交付消息，它们是否以及如何提供与经典队列相同的消息排序保证。镜像队列始终从主节点（leader）交付，因此从任何队列副本交付听起来都可能影响这些保证。

这正是本帖的主题。请注意，本帖是一篇面向好奇者和分布式系统爱好者的技术深度分析。我们将探讨仲裁队列如何在不增加額外协调（Raft 之外）的情况下，从任何队列副本（leader 或 follower）交付消息，同时保持消息排序保证。

在 上一篇文章 中，我们开始使用仲裁队列对我们的 工作负载 进行容量分析。我们专注于消费者能够跟上、队列没有积压且集群中所有代理程序都正常运行的理想情况。通过运行一系列基准测试，模拟不同强度的我们的工作负载，我们确定了每 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 基准测试的各种选项。但在我们开始之前，您需要一种查看结果和查看系统指标的方法。

关于仲裁队列的网络研讨会​

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

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

在此网络研讨会之后，您将了解

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

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

具体来说，我们研究了

• 发布者：限制正在进行的消息数量（已发送但等待确认的消息）。
• 消费者：预取（代理程序允许在通道上传输的消息数量）
• 消费者：确认间隔（多标志用法）

不出所料，我们发现当我们将发布者和代理程序限制为一次少量正在进行的消息时，吞吐量较低。当我们增加这个限制时，吞吐量有所提高，但仅限于某个点，之后我们没有看到吞吐量进一步提升，反而只是延迟增加。我们还发现允许消费者使用多标志对吞吐量有利。

在本文中，我们将针对许多客户端、许多队列以及不同量的负载（包括压力测试）来查看这三个相同的设置。我们将看到发布者确认和消费者确认在流量控制中起作用，以帮助防止代理程序过载。