博客 | RabbitMQ 消息队列
在这篇文章中,我将介绍可能是我收到的关于企业中 RabbitMQ 最常见的问题。
如何使 RabbitMQ 高度可用,以及推荐哪些架构/实践用于灾难恢复?
RabbitMQ 提供了支持高可用性和灾难恢复的功能,但在我们深入研究之前,我想先做一些准备工作。首先,我想回顾一下业务连续性计划,并用这些术语来构建我们的需求。从那里,我们需要对可能实现的目标设定一些期望。存在一些基本定律,例如光速和 CAP 定理,它们都对我们决定采用哪种 DR/HA 解决方案产生重大影响。
最后,我们将看看 RabbitMQ 为我们提供的功能及其优缺点。
团队最近被问及,鉴于 quorum 队列将在可能的情况下从本地队列副本(领导者或追随者)传递消息,它们是否以及如何提供与经典队列相同的消息排序保证。镜像队列始终从主节点(领导者)传递消息,因此从任何队列副本传递消息听起来可能会影响这些保证。
这就是这篇文章的主题。请注意,这篇文章是为好奇者和分布式系统爱好者准备的技术深入探讨。我们将了解 quorum 队列如何在不进行额外协调(Raft 之外的额外协调)的情况下从任何队列副本、领导者或追随者传递消息,同时保持消息排序保证。
在 上一篇文章 中,我们开始了使用 quorum 队列对我们的 工作负载 进行大小调整分析。我们专注于消费者保持同步的理想情况,这意味着没有队列积压,并且集群中的所有 broker 都正常运行。通过运行一系列基准测试,模拟不同强度的工作负载,我们确定了每 1000 msg/s 每月成本方面排名前 5 的集群大小和存储卷组合。
- 集群: 7 个节点,8 个 vCPU (c5.2xlarge),gp2 SDD。成本:$54
- 集群: 9 个节点,8 个 vCPU (c5.2xlarge),gp2 SDD。成本:$69
- 集群: 5 个节点,8 个 vCPU (c5.2xlarge),st1 HDD。 成本:$93
- 集群: 5 个节点,16 个 vCPU (c5.4xlarge),gp2 SDD。成本:$98
- 集群: 7 个节点,16 个 vCPU (c5.4xlarge),gp2 SDD。成本:$107
还有更多的测试要运行,以确保这些集群可以处理 broker 故障以及在中断或系统减速期间累积的大量积压等情况。
所有 quorum 队列都使用以下属性声明
- x-quorum-initial-group-size=3
- x-max-in-memory-length=0
x-max-in-memory-length 属性强制 quorum 队列在安全的情况下尽快从内存中删除消息体。您可以将其设置为更长的限制,这是最激进的 - 旨在避免大量内存增长,但代价是当消费者跟不上时需要进行更多磁盘读取。如果没有此属性,消息体将始终保留在内存中,这可能会导致内存增长到触发内存警报的程度,从而严重影响发布速率 - 这是我们希望在本工作负载案例研究中避免的情况。
在本大小调整系列 第一篇文章 中,我们介绍了工作负载、测试以及 AWS ec2 上的集群和存储卷配置。在本文中,我们将使用 quorum 队列运行大小调整分析。我们还对 镜像队列进行了大小调整分析。
在本文中,我们将运行强度递增测试,以衡量我们的候选集群大小在理想条件下以不同的发布速率下的性能。在下一篇文章中,我们将运行弹性测试,以衡量我们的集群是否可以在不利条件下处理我们的目标峰值负载。
所有 quorum 队列都使用以下属性声明
- x-quorum-initial-group-size=3 (复制因子)
- x-max-in-memory-length=0
x-max-in-memory-length 属性强制 quorum 队列在安全的情况下尽快从内存中删除消息体。您可以将其设置为更长的限制,这是最激进的 - 旨在避免大量内存增长,但代价是当消费者跟不上时需要进行更多磁盘读取。如果没有此属性,消息体将始终保留在内存中,这可能会导致内存增长到触发内存警报的程度,从而严重影响发布速率 - 这是我们希望在本工作负载案例研究中避免的情况。
在 上一篇文章 中,我们开始了使用镜像队列对我们的 工作负载 进行大小调整分析。我们专注于消费者保持同步的理想情况,这意味着没有队列积压,并且集群中的所有 broker 都正常运行。通过运行一系列基准测试,模拟不同强度的工作负载,我们确定了每 1000 msg/s 每月成本方面排名前 5 的集群大小和存储卷组合。
- 集群: 5 个节点,8 个 vCPU,gp2 SDD。成本:$58
- 集群: 7 个节点,8 个 vCPU,gp2 SDD。成本:$81
- 集群: 5 个节点,8 个 vCPU,st1 HDD。 成本:$93
- 集群: 5 个节点,16 个 vCPU,gp2 SDD。成本:$98
- 集群: 9 个节点,8 个 vCPU,gp2 SDD。成本:$104
还有更多的测试要运行,以确保这些集群可以处理 broker 故障以及在中断或系统减速期间累积的大量积压等情况。
在本大小调整系列 第一篇文章 中,我们介绍了 AWS ec2 上的工作负载、集群和存储卷配置。在本文中,我们将使用镜像队列运行大小调整分析。
我们的大小调整分析的第一阶段将评估我们的每个集群和存储卷可以轻松处理的强度以及哪些强度过大。
所有测试均使用以下策略
- ha-mode: exactly
- ha-params: 2
- ha-sync-mode: manual
这是一个简短系列的开始,我们将在此系列中查看 RabbitMQ 集群的大小调整。实际的大小调整完全取决于您的硬件和工作负载,因此我们不会告诉您应该配置多少 CPU 和多少 RAM,而是创建一些通用指南并使用案例研究来展示您应该考虑的事项。
进行基准测试的原因可能有很多
- 大小调整和容量规划
- 产品评估(RabbitMQ 能否处理我的负载?)
- 发现最适合您工作负载的配置
在这篇文章中,我们将了解运行 RabbitMQ 基准测试的各种选项。但在我们开始之前,您需要一种查看结果和查看系统指标的方法。
关于 Quorum 队列的网络研讨会
在我们开始介绍 RabbitMQ 项目和 4 月份的社区更新之前,我们有一个网络研讨会要宣布!RabbitMQ 核心团队成员 Jack Vanlightly 将于 2020 年 6 月 11 日在 消息传递中的高可用性和数据安全 上进行演讲。
在本次网络研讨会中,Jack Vanlightly 将解释 quorum 队列,这是 RabbitMQ 中一种新的复制队列类型。Quorum 队列在 RabbitMQ 3.8 中引入,重点是数据安全以及从节点故障中高效、可预测地恢复。Jack 将介绍并对比 quorum 队列和经典镜像队列的设计。
在本次网络研讨会之后,您将了解
- 为什么 quorum 队列比镜像队列提供更好的数据安全性
- 从镜像队列切换到 quorum 队列时,服务器资源使用情况如何以及为何发生变化
- 使用 quorum 队列时的一些最佳实践
© . This site is unofficial and not affiliated with VMware.