搭建 RocketMQ 集群

简介: 纯粹是为了记录搭建的过程。忘了就翻来看看

纯粹是为了记录搭建的过程。忘了就翻来看看。


RocketMQ部署类型



单个Master


单机模式, 即只有一个Broker, 如果Broker宕机了, 会导致RocketMQ服务不可用, 不推荐使用.


多Master模式


组成一个集群, 集群每个节点都是Master节点, 配置简单, 性能也是最高, 某节点宕机重启不会影响RocketMQ服务, 缺点就是如果某个节点宕机了, 会导致该节点未被消费的消息在在节点恢复前不可订阅.


多Master多Slave模式,异步复制


每个Master配置一个Slave, 多对Master-Slave, Master与Slave消息采用异步复制方式, 主从消息一致会有毫秒级的延迟. 优点是弥补了多Master模式下节点宕机后在恢复前不可订阅的问题, 在Master宕机后, 消费者还可以从Slave节点进行消费, 缺点就是如果Master宕机, 磁盘损坏的情况下, 如果没有即使将消息复制到Slave, 会导致有少量消息丢失.


多Master多Slave模式,同步双写


每个Master配置一个Slave,有多对Master-Slave,HA采用同步双写方式,主备都写成功,向应用返回成功。数据与服务都无单点,Master宕机情况下,消息无延迟,服务可用性与数据可用性都非常高。缺点就是性能比异步复制模式略低,大约低10%左右,发送单个消息的RT会略高。


集群的一些概念



640.png

  • Name Server: 是一个几乎无状态节点, 可集群部署, 节点之间间无任何信息同步.
  • Broker:  Broker分为Master与Slave, 一个Master可以对应多个Slave, 但是一个Slave只能对应一个Master, Master与Slave的对应关系通过指定相同的BrokerName, 不同的BrokerId来定义, BrokerId为0表示Master, 非0表示Slave. Master也可以部署多个. 每个Broker与Name Server集群中的所有节点建立长连接, 定时注册Topic信息到所有Name Server.
  • Producer: producer与Name Server集群中的其中一个节点(随机选择)建立长连接, 定期从Name Server取Topic路由信息, 并向提供Topic服务的Master建立长连接, 且定时向Master发送心跳. Producer完全无状态, 可集群部署.
  • Comsumer: Consumer与Name Server集群中的其中一个节点(随机选择)建立长连接, 定期从Name Server 取Topic路由信息, 并向提供Topic服务的Master、Slave建立长连接, 且定时向Master、Slave发送心跳. Consumer既可以从Master订阅消息, 也可以从Slave订阅消息, 订阅规则由Broker配置决定.


以上概念来源于RocketMQ开发手册


搭建多 Master多Slave 异步复制模式



  • 下载:
$ wget http://mirrors.tuna.tsinghua.edu.cn/apache/rocketmq/4.3.2/rocketmq-all-4.3.2-source-release.zip


  • 解压:
$ unzip rocketmq-all-4.3.2-source-release.zip
$ mv rocketmq-all-4.3.2 rocketmq


  • Maven编译:
$ mvn -Prelease-all -DskipTests clean install -U


  • 修改broker配置文件:

Master1

$ vim ${rocketmq_home}/conf/2m-2s-sync/broker-a.properties
brokerClusterName=test_hk_hk3_hd_mq_rocket_1
brokerName=broker-a
# 主服务器必须为0
brokerId=0
deleteWhen=04
fileReservedTime=48
brokerRole=ASYNC_MASTER
flushDiskType=ASYNC_FLUSH
#nameServer地址,分号分割
namesrvAddr=172.17.4.60:9876;172.17.4.61:9876


Slave1

$ vim ${rocketmq_home}/conf/2m-2s-sync/broker-a-s.properties
brokerClusterName=test_hk_hk3_hd_mq_rocket_1
brokerName=broker-a
# 从服务器必须大于0
brokerId=1
deleteWhen=04
fileReservedTime=48
brokerRole=SLAVE
flushDiskType=ASYNC_FLUSH
#nameServer地址,分号分割
namesrvAddr=172.17.4.60:9876;172.17.4.61:9876


其余另一对Master-Slave与此类推.

另外再列出具体的配置信息与注释:


#所属集群名字
brokerClusterName=rocketmq-cluster
#broker名字,注意此处不同的配置文件填写的不一样
brokerName=broker-a|broker-b
#0 表示 Master,>0 表示 Slave
brokerId=0
#nameServer地址,分号分割
namesrvAddr=rocketmq-nameserver1:9876;rocketmq-nameserver2:9876
#在发送消息时,自动创建服务器不存在的topic,默认创建的队列数
defaultTopicQueueNums=4
#是否允许 Broker 自动创建Topic,建议线下开启,线上关闭
autoCreateTopicEnable=true
#是否允许 Broker 自动创建订阅组,建议线下开启,线上关闭
autoCreateSubscriptionGroup=true
#Broker 对外服务的监听端口,10911为默认值
listenPort=10911
#表示Master监听Slave请求的端口,默认为服务端口+1
haListenPort=10912
#删除文件时间点,默认凌晨 4点
deleteWhen=04
#文件保留时间,默认 48 小时
fileReservedTime=120
#commitLog每个文件的大小默认1G
mapedFileSizeCommitLog=1073741824
#ConsumeQueue每个文件默认存30W条,根据业务情况调整
mapedFileSizeConsumeQueue=300000
#destroyMapedFileIntervalForcibly=120000
#redeleteHangedFileInterval=120000
#检测物理文件磁盘空间
diskMaxUsedSpaceRatio=88
#存储路径
storePathRootDir=/usr/local/rocketmq/store
#commitLog 存储路径
storePathCommitLog=/usr/local/rocketmq/store/commitlog
#消费队列存储路径存储路径
storePathConsumeQueue=/usr/local/rocketmq/store/consumequeue
#消息索引存储路径
storePathIndex=/usr/local/rocketmq/store/index
#checkpoint 文件存储路径
storeCheckpoint=/usr/local/rocketmq/store/checkpoint
#abort 文件存储路径
abortFile=/usr/local/rocketmq/store/abort
#限制的消息大小
maxMessageSize=65536
#flushCommitLogLeastPages=4
#flushConsumeQueueLeastPages=2
#flushCommitLogThoroughInterval=10000
#flushConsumeQueueThoroughInterval=60000
#Broker 的角色
#- ASYNC_MASTER  异步复制Master
#- SYNC_MASTER  同步双写Master
#- SLAVE
brokerRole=ASYNC_MASTER
#刷盘方式
#- ASYNC_FLUSH  异步刷盘
#- SYNC_FLUSH  同步刷盘
flushDiskType=ASYNC_FLUSH
#checkTransactionMessageEnable=false
#发消息线程池数量
#sendMessageThreadPoolNums=128
#拉消息线程池数量
#pullMessageThreadPoolNums=128


  • 启动: 进入rocketMQ解压目录下的bin文件夹 启动nameServer:
$ nohup sh bin/mqnamesrv &


启动broker:

$ nohup sh mqbroker -c broker-a.properties >/dev/null 2>&1 &
$ nohup sh mqbroker -c broker-a-s.properties >/dev/null 2>&1 &
$ nohup sh mqbroker -c broker-b.properties >/dev/null 2>&1 &
$ nohup sh mqbroker -c broker-b-s.properties >/dev/null 2>&1 &


如果运行出现如下错误: "The broker[broker-a, 172.17.4.60:10911] boot success. serializeType=JSON and name server is 172.17.4.60:9876" "INFO: os::commit_memory(0x00000006c0000000, 2147483648, 0) failed; error='Cannot allocate memory' (errno=12)"


那么修改一下runserver.sh和runbroker.sh的合适的jvm参数就可以了


  • 搭建控制台 本地下载源码:
$ git clone https://github.com/apache/rocketmq-externals


配置好配置文件后, 打包:

$ mvn clean package


将打好的jar包上传到服务器

服务器运行:

$ nohup java -jar rocketmq-console-ng-1.0.0.jar 2>&1 &
$ tail -f nohup.out



相关实践学习
消息队列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
相关文章
|
7月前
|
消息中间件 负载均衡 监控
【面试问题】RabbitMQ 的集群
【1月更文挑战第27天】【面试问题】RabbitMQ 的集群
|
2天前
|
消息中间件 存储 运维
2024最全RabbitMQ集群方案汇总
本文梳理了RabbitMQ集群的几种方案,主要包括普通集群、镜像集群(高可用)、Quorum队列(仲裁队列)、Streams集群模式(高可用+负载均衡)和插件方式。重点介绍了每种方案的特点、优缺点及适用场景。搭建步骤包括安装Erlang和RabbitMQ、配置集群节点、修改hosts文件、配置Erlang Cookie、启动独立节点并创建集群,以及配置镜像队列以提高可用性和容错性。推荐使用Quorum队列与Streams模式,其中Quorum队列适合高可用集群,Streams模式则同时支持高可用和负载均衡。此外,还有Shovel和Federation插件可用于特定场景下的集群搭建。
12 2
|
2天前
|
消息中间件 RocketMQ
2024最全RocketMQ集群方案汇总
在研究RocketMQ集群方案时,发现网上存在诸多不一致之处,如组件包含NameServer、Broker、Proxy等。通过查阅官方文档,了解到v4.x和v5.x版本的差异。v4.x部署模式包括单主、多主、多主多从(异步复制、同步双写),而v5.x新增Local与Cluster模式,主要区别在于Broker和Proxy是否同进程部署。Local模式适合平滑升级,Cluster模式适合高可用需求。不同模式下,集群部署方案大致相同,涵盖单主、多主、多主多从等模式,以满足不同的高可用性和性能需求。
8 0
|
4月前
|
消息中间件 存储 负载均衡
|
4月前
|
消息中间件 存储 负载均衡
"RabbitMQ集群大揭秘!让你的消息传递系统秒变超级英雄,轻松应对亿级并发挑战!"
【8月更文挑战第24天】RabbitMQ是一款基于AMQP的开源消息中间件,以其高可靠性、扩展性和易用性闻名。面对高并发和大数据挑战时,可通过构建集群提升性能。本文深入探讨RabbitMQ集群配置、工作原理,并提供示例代码。集群由多个通过网络连接的节点组成,共享消息队列,确保高可用性和负载均衡。搭建集群需准备多台服务器,安装Erlang和RabbitMQ,并确保节点间通信顺畅。核心步骤包括配置.erlang.cookie文件、使用rabbitmqctl命令加入集群。消息发布至任一节点时,通过集群机制同步至其他节点;消费者可从任一节点获取消息。
55 2
|
4月前
|
存储 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应用的可扩展性和可用性,还降低了基础设施成本。
95 0
|
5月前
|
消息中间件 Prometheus 监控
消息队列 MQ使用问题之如何将旧集群的store目录迁移到新集群
消息队列(MQ)是一种用于异步通信和解耦的应用程序间消息传递的服务,广泛应用于分布式系统中。针对不同的MQ产品,如阿里云的RocketMQ、RabbitMQ等,它们在实现上述场景时可能会有不同的特性和优势,比如RocketMQ强调高吞吐量、低延迟和高可用性,适合大规模分布式系统;而RabbitMQ则以其灵活的路由规则和丰富的协议支持受到青睐。下面是一些常见的消息队列MQ产品的使用场景合集,这些场景涵盖了多种行业和业务需求。
|
5月前
|
消息中间件 RocketMQ
MetaQ/RocketMQ 原理问题之当消费集群规模较大时,处理分配不到队列的Consumer的问题如何解决
MetaQ/RocketMQ 原理问题之当消费集群规模较大时,处理分配不到队列的Consumer的问题如何解决
|
4月前
|
消息中间件 API 数据安全/隐私保护
就软件研发问题之RocketMQ ACL 2.0加强集群组件间访问控制的问题如何解决
就软件研发问题之RocketMQ ACL 2.0加强集群组件间访问控制的问题如何解决
|
5月前
|
消息中间件 负载均衡 算法
【RocketMQ系列十二】RocketMQ集群核心概念之主从复制&生产者负载均衡策略&消费者负载均衡策略
【RocketMQ系列十二】RocketMQ集群核心概念之主从复制&生产者负载均衡策略&消费者负载均衡策略
151 2
下一篇
DataWorks