2024最全RocketMQ集群方案汇总

简介: 在研究RocketMQ集群方案时,发现网上存在诸多不一致之处,如组件包含NameServer、Broker、Proxy等。通过查阅官方文档,了解到v4.x和v5.x版本的差异。v4.x部署模式包括单主、多主、多主多从(异步复制、同步双写),而v5.x新增Local与Cluster模式,主要区别在于Broker和Proxy是否同进程部署。Local模式适合平滑升级,Cluster模式适合高可用需求。不同模式下,集群部署方案大致相同,涵盖单主、多主、多主多从等模式,以满足不同的高可用性和性能需求。

之前在网上看一些rocketmq集群方案时,看到有很多不一致的地方,比如:

  • rocketmq的组件包含NameServer、Broker、Proxy,多出来个Proxy?
  • Local模式是单机的不适合生产使用?
  • proxyMode设置为Local模式,也是可以部署多节点的?

.....

发现这些不一致,所以产生了一些疑问,然后去官方文档研究了一下。

以下是官方文档英文版v4.x与v5.x


添加图片注释,不超过 140 字(可选)


可以明显看到v4.x的部署方法包括:单主模式、多主模式、多主多从模式-异步复制、多主多从模型-同步双写。

并没有Local模式与Cluster模式之分。

当然v4.x不要看中文版的,中文版的目录有点乱,并且v4.x的中文版文档用的又是v5.x的版本,不知道是不是官方没有维护v4.x中文版


添加图片注释,不超过 140 字(可选)


从英文版,可以明显看到v4.x的部署方法包括:单主模式、多主模式、多主多从模式-异步复制、多主多从模型-同步双写。

添加图片注释,不超过 140 字(可选)

而5.x把部署分成Local Mode与Cluster Mode


添加图片注释,不超过 140 字(可选)


并说明了

在 5.0 版本中 Proxy 和 Broker 根据实际诉求可以分为 Local 模式和 Cluster 模式,一般情况下如果没有特殊需求,或者遵循从早期版本平滑升级的思路,可以选用Local模式。

  • 在 Local 模式下,Broker 和 Proxy 是同进程部署,只是在原有 Broker 的配置基础上新增 Proxy 的简易配置就可以运行。
  • 在 Cluster 模式下,Broker 和 Proxy 分别部署,即在原有的集群基础上,额外再部署 Proxy 即可。


也就是 Local 模式和 Cluster 模式区别在于Broker 和 Proxy 是否在一起。总的来说在这两种模式下的部署方案还是相同的:单组节点单副本模式、多组节点(集群)单副本模式、多节点(集群)多副本模式-异步复制、多节点(集群)多副本模式-同步双写。

添加图片注释,不超过 140 字(可选)


虽然v5.x在v4.x基础上增加了Local模式与Cluster模式,但集群的部署方案大致是相同的,下面就来具体看看集群部署方法

单主机模式

在单主模式下,RocketMQ的架构非常简单,只有一个主节点(Master),没有备用节点(Slave)。这种模式适用于对高可用性要求不高的小型系统,因为单主模式中主节点如果宕机,整个消息系统将不可用。

这种模式具有更高的风险,因为Broker的重启或失败将导致整个服务不可用。不建议在在线环境中使用,但可用于本地测试。


添加图片注释,不超过 140 字(可选)


多主模式

RocketMQ 的多主模式(Multi-Master Mode)是一种高可用的集群部署模式。在这种模式下,集群中有多个主节点(Master),每个主节点独立地接收和处理消息,彼此之间没有从属关系。多主模式提高了系统的可用性和容错能力,避免了单点故障的问题。

全是主设备而没有从设备的集群(例如2或3个主设备)的优点和缺点如下:

  • 优点:配置简单,单台主机重启或停机对应用无影响,当磁盘配置为RAID10时,即使机器停机无法恢复,由于RAID10磁盘的可靠性,消息也不会丢失(异步刷新丢失少量消息,同步刷新不丢失一条消息),性能最高;
  • 缺点:在单机停机期间,本机上未消费的消息在机器恢复前无法订阅,消息的实时性将受到影响。

添加图片注释,不超过 140 字(可选)


多主多从模式-异步复制

每个Master配置有一个Slave,从而产生多个Master-Slave对。在此高可用性(HA)设置中,由于异步复制,存在短暂的消息延迟(在毫秒范围内)。

  • 优点:在磁盘损坏的情况下,丢失的消息数量最小,消息的实时性不受影响。此外,即使主设备停机,消费者仍然可以从从设备进行消费,这个过程对应用程序是透明的,不需要手动干预,性能几乎与多主模式相同。
  • 缺点:在主机中断或磁盘损坏的情况下,可能会丢失少量消息。

添加图片注释,不超过 140 字(可选)

多主多从模式-同步双写

每个Master配置有一个Slave,从而产生多个Master-Slave对。在此高可用性(HA)设置中,使用同步双写入,这意味着只有在主设备和从设备都成功写入时,才向应用程序返回成功。该模式的优点和缺点如下:

  • 优点:数据或服务都没有单点故障,并且在主服务器中断的情况下,没有消息延迟,服务可用性和数据可用性都非常高。
  • 缺点:性能比异步复制模式略低(约低10%),发送单个消息的往返时间略高,并且在当前版本中,主节点宕机后备用节点不能自动切换到主节点。

添加图片注释,不超过 140 字(可选)

上述Broker和Slave的配对是通过指定相同的BrokerName参数完成的。Master的BrokerId必须为0,Slave的BrokerId必须为大于0的数字。 此外,一个Master下可以挂载多个Slave,同一Master下的多个Slave通过指定不同的BrokerId来区分。

相关实践学习
消息队列RocketMQ版:基础消息收发功能体验
本实验场景介绍消息队列RocketMQ版的基础消息收发功能,涵盖实例创建、Topic、Group资源创建以及消息收发体验等基础功能模块。
消息队列 MNS 入门课程
1、消息队列MNS简介 本节课介绍消息队列的MNS的基础概念 2、消息队列MNS特性 本节课介绍消息队列的MNS的主要特性 3、MNS的最佳实践及场景应用 本节课介绍消息队列的MNS的最佳实践及场景应用案例 4、手把手系列:消息队列MNS实操讲 本节课介绍消息队列的MNS的实际操作演示 5、动手实验:基于MNS,0基础轻松构建 Web Client 本节课带您一起基于MNS,0基础轻松构建 Web Client
目录
相关文章
|
16天前
|
消息中间件 存储 运维
2024最全RabbitMQ集群方案汇总
本文梳理了RabbitMQ集群的几种方案,主要包括普通集群、镜像集群(高可用)、Quorum队列(仲裁队列)、Streams集群模式(高可用+负载均衡)和插件方式。重点介绍了每种方案的特点、优缺点及适用场景。搭建步骤包括安装Erlang和RabbitMQ、配置集群节点、修改hosts文件、配置Erlang Cookie、启动独立节点并创建集群,以及配置镜像队列以提高可用性和容错性。推荐使用Quorum队列与Streams模式,其中Quorum队列适合高可用集群,Streams模式则同时支持高可用和负载均衡。此外,还有Shovel和Federation插件可用于特定场景下的集群搭建。
117 2
|
3月前
|
消息中间件 存储 弹性计算
云消息队列 RabbitMQ 版方案评测
本文评估了阿里云《高弹性,低成本,云消息队列 RabbitMQ 实践》方案,从实践原理理解、部署体验、方案优势展现及业务场景匹配四个方面进行了深入分析。文中指出,该方案在解决消息积压、提高系统稳定性、支持弹性伸缩等方面表现优异,但也提出了在组件功能解释、实战案例提供等方面的改进建议,以期帮助用户更好地理解和应用该技术解决方案。
161 0
|
5月前
|
消息中间件 存储 负载均衡
|
5月前
|
消息中间件 存储 负载均衡
"RabbitMQ集群大揭秘!让你的消息传递系统秒变超级英雄,轻松应对亿级并发挑战!"
【8月更文挑战第24天】RabbitMQ是一款基于AMQP的开源消息中间件,以其高可靠性、扩展性和易用性闻名。面对高并发和大数据挑战时,可通过构建集群提升性能。本文深入探讨RabbitMQ集群配置、工作原理,并提供示例代码。集群由多个通过网络连接的节点组成,共享消息队列,确保高可用性和负载均衡。搭建集群需准备多台服务器,安装Erlang和RabbitMQ,并确保节点间通信顺畅。核心步骤包括配置.erlang.cookie文件、使用rabbitmqctl命令加入集群。消息发布至任一节点时,通过集群机制同步至其他节点;消费者可从任一节点获取消息。
57 2
|
5月前
|
存储 C# 关系型数据库
“云端融合:WPF应用无缝对接Azure与AWS——从Blob存储到RDS数据库,全面解析跨平台云服务集成的最佳实践”
【8月更文挑战第31天】本文探讨了如何将Windows Presentation Foundation(WPF)应用与Microsoft Azure和Amazon Web Services(AWS)两大主流云平台无缝集成。通过具体示例代码展示了如何利用Azure Blob Storage存储非结构化数据、Azure Cosmos DB进行分布式数据库操作;同时介绍了如何借助Amazon S3实现大规模数据存储及通过Amazon RDS简化数据库管理。这不仅提升了WPF应用的可扩展性和可用性,还降低了基础设施成本。
101 0
|
6月前
|
消息中间件 Prometheus 监控
消息队列 MQ使用问题之如何将旧集群的store目录迁移到新集群
消息队列(MQ)是一种用于异步通信和解耦的应用程序间消息传递的服务,广泛应用于分布式系统中。针对不同的MQ产品,如阿里云的RocketMQ、RabbitMQ等,它们在实现上述场景时可能会有不同的特性和优势,比如RocketMQ强调高吞吐量、低延迟和高可用性,适合大规模分布式系统;而RabbitMQ则以其灵活的路由规则和丰富的协议支持受到青睐。下面是一些常见的消息队列MQ产品的使用场景合集,这些场景涵盖了多种行业和业务需求。
|
6月前
|
消息中间件 RocketMQ
MetaQ/RocketMQ 原理问题之当消费集群规模较大时,处理分配不到队列的Consumer的问题如何解决
MetaQ/RocketMQ 原理问题之当消费集群规模较大时,处理分配不到队列的Consumer的问题如何解决
|
5月前
|
消息中间件 API 数据安全/隐私保护
就软件研发问题之RocketMQ ACL 2.0加强集群组件间访问控制的问题如何解决
就软件研发问题之RocketMQ ACL 2.0加强集群组件间访问控制的问题如何解决
|
5月前
|
消息中间件 固态存储 RocketMQ
RocketMQ消息堆积常见场景与处理方案
文章分析了在使用RocketMQ时消息堆积的常见场景,如消费者注册失败或消费速度慢于生产速度,并提供了相应的处理方案,包括提高消费并行度、批量消费、跳过非重要消息以及优化消费代码业务逻辑等。
|
6月前
|
消息中间件 负载均衡 算法
【RocketMQ系列十二】RocketMQ集群核心概念之主从复制&生产者负载均衡策略&消费者负载均衡策略
【RocketMQ系列十二】RocketMQ集群核心概念之主从复制&生产者负载均衡策略&消费者负载均衡策略
172 2