本文主要是介绍Rocket-集群搭建,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
搭建RocketMQ可视化管理服务
RocketMQ的社区就提供了一个图形化的管理控制台Dashboard,可以用可视化的方式直接观测并管理RocketMQ的运行过程。
Dashboard服务并不在RocketMQ的运行包中,需要到RocketMQ的官网下载页面单独下载。
这里只提供了源码,并没有提供直接运行的jar包。将源码下载下来后,需要解压并进入对应的目录,使用maven进行编译。
mvn clean package -Dmaven.test.skip=true
注意:上面的打包命令要在Linux环境下运行,在windows环境下打包报错
编译完成后,在源码的target目录下会生成可运行的jar包rocketmq-dashboard-1.0.0.jar
接下来将这个jar包移动到/app/rocketmq/rocketmq-dashboard
目录下
在jar包所在的目录下创建一个application.properties
配置文件,在配置文件中做如下配置:
rocketmq.config.namesrvAddr=你的公网IP:9876
这个配置文件中更多的配置选项,可以参考dashboard源码当中的application.properties
配置文件
应用启动完成后,会在服务器上搭建起一个web服务,我们就可以通过访问http://你的公网IP:8080
查看到管理页面,云服务要在安全组开放8080端口
升级分布式集群
RocketMQ的分布式集群基于主从架构搭建。在多个服务器组成的集群中,指定一部分节点作为Master节点,负责响应客户端的请求。指令另一部分节点作为Slave节点,负责备份Master节点上的数据,这样,当Master节点出现故障时,在Slave节点上可以保留有数据备份,至少保证数据不会丢失。
防止单点故障问题,增加从节点备份数据,注意这里的从节点还不能选举为主节点
整个集群方案:
接下来准备三台相同的Linux服务器,搭建RocketMQ的分布式集群。为了更清晰的描述这三台服务器上的操作,给每个服务器指定一个机器名。
cat /etc/hosts
192.168.232.128 worker1
192.168.232.129 worker2
192.168.232.130 worker3
搭建一个2主2从的RocketMQ集群,并将主节点和节点都分别部署在不同的服务器上。预备的集群规划情况如下:(同一组主从节点放在不同机器上,防止机器宕机导致数据丢失,生产上也是这样做的)
机器名 | nameServer服务部署 | broker服务部署 |
---|---|---|
worker1 | nameServer | |
worker2 | nameServer | broker-a,broker-b-s |
worker3 | nameServer | broker-a-s,broker-b |
第一步:部署nameServer服务。
在三台服务器上都分别部署nameServer服务即可,启动命令简单
nameServer可以修改端口号(默认9876),在conf下面添加配置文件namesrv.properties
# namesrv.properties文件内容
listenPort=9896# 启动命令加上 -c 指向当前配置文件生效
mqnamesrv -c ../namesrv.properties# linux启动命令:
nohup bin/mqnamesrv &
# windows启动命令,进入bin目录执行
start mqnamesrv.cmd
第二步:对Broker服务进行集群配置。
这里需要修改RocketMQ的配置文件,对broker服务做一些集群相关的参数部署。在RocketMQ运行包的conf目录下,提供了多种集群的部署配置文件模板。
-
2m-noslave: 2主无从的集群参考配置。这种集群存在单点故障。
-
2m-2s-async和2m-2s-sync: 2主2从的集群参考配置。其中async和sync表示主节点与从节点之间是同步同步还是异步同步。
-
dledger: 具备主从切换功能的高可用集群。集群中的节点会基于Raft协议随机选举出一个Leader,其作用类似于Master节点。其他的节点都是follower,其作用类似于Slave节点。
我们这次采用2m-2s-async的方式搭建集群,需要在worker2和worker3上修改这个文件夹下的配置文件。
1、配置第一组broker-a服务
在worker2机器上配置broker-a的MASTER服务,修改conf/2m-2s-async/broker-a.properties。示例配置:
#所属集群名字,名字一样的节点就在同一个集群内
brokerClusterName=rocketmq-cluster
#broker名字,名字一样的节点就是一组主从节点。
brokerName=broker-a
#brokerid,0就表示是Master,>0的都是表示 Slave
brokerId=0
#nameServer地址,分号分割
namesrvAddr=worker1:9876;worker2:9876;worker3:9876
#是否允许 Broker 自动创建Topic,建议线下开启,线上关闭
autoCreateTopicEnable=true
#凌晨4点开始删除文件
deleteWhen=04
#日志时间过多久删除
fileReservedTime=120
#存储路径
storePathRootDir=/app/rocketmq/store
storePathCommitLog=/app/rocketmq/store/commitlog
storePathConsumeQueue=/app/rocketmq/store/consumequeue
storePathIndex=/app/rocketmq/store/index
storeCheckpoint=/app/rocketmq/store/checkpoint
abortFile=/app/rocketmq/store/abort
#Broker 的角色
brokerRole=ASYNC_MASTER
#异步刷盘,消息到达broker后是否立刻写入磁盘
flushDiskType=ASYNC_FLUSH
#Broker 对外服务的监听端口
listenPort=10911
重点关注的属性介绍:
-
brokerClusterName: 集群名。RocketMQ会将同一个局域网下所有brokerClusterName相同的服务自动组成一个集群,这个集群可以作为一个整体对外提供服务
-
brokerName: Broker服务名。同一个RocketMQ集群当中,brokerName相同的多个服务会有一套相同的数据副本。同一个RocketMQ集群中,是可以将消息分散存储到多个不同的brokerName服务上的。
-
brokerId: RocketMQ中对每个服务的唯一标识。RocketMQ对brokerId定义了一套简单的规则,master节点需要固定配置为0,负责响应客户端的请求。slave节点配置成其他任意数字,负责备份master上的消息。
-
brokerRole: 服务的角色。这个属性有三个可选项:ASYNC_MASTER,SYNC_MASTER和SLAVE。其中,ASYNC_MASTER和SYNC_MASTER表示当前节点是master节点,目前暂时不用关心他们的区别。SLAVE则表示从节点。
-
namesrvAddr: nameserver服务的地址。nameserver服务默认占用9876端口。多个nameserver地址用;隔开。
接下来在worekr3上配置broker-a的SLAVE服务。修改conf/2m-2s-async/broker-a-s.properties。示例配置:
#所属集群名字,名字一样的节点就在同一个集群内
brokerClusterName=rocketmq-cluster
#broker名字,名字一样的节点就是一组主从节点。
brokerName=broker-a
#brokerid,0就表示是Master,>0的都是表示 Slave
brokerId=1
#nameServer地址,分号分割
namesrvAddr=worker1:9876;worker2:9876;worker3:9876
#是否允许 Broker 自动创建Topic,建议线下开启,线上关闭
autoCreateTopicEnable=true
deleteWhen=04
fileReservedTime=120
#存储路径
storePathRootDir=/app/rocketmq/storeSlave
storePathCommitLog=/app/rocketmq/storeSlave/commitlog
storePathConsumeQueue=/app/rocketmq/storeSlave/consumequeue
storePathIndex=/app/rocketmq/storeSlave/index
storeCheckpoint=/app/rocketmq/storeSlave/checkpoint
abortFile=/app/rocketmq/storeSlave/abort
#Broker 的角色
brokerRole=SLAVE
flushDiskType=ASYNC_FLUSH
#Broker 对外服务的监听端口
listenPort=11011
注意brokerClusterName和brokerName两个参数需要与worker2上对应的broker-a.properties配置匹配。brokerId配置0以外的数字。然后brokerRole配置为SLAVE。
2、配置第二组borker-b服务
与第一组broker-a服务的配置方式类似,在worker3上配置broker-b的MASTER服务。修改conf/2m-2s-async/broker-b.properties文件,配置示例:
#所属集群名字,名字一样的节点就在同一个集群内
brokerClusterName=rocketmq-cluster
#broker名字,名字一样的节点就是一组主从节点。
brokerName=broker-b
#brokerid,0就表示是Master,>0的都是表示 Slave
brokerId=0
#nameServer地址,分号分割
namesrvAddr=worker1:9876;worker2:9876;worker3:9876
#是否允许 Broker 自动创建Topic,建议线下开启,线上关闭
autoCreateTopicEnable=true
deleteWhen=04
fileReservedTime=120
#存储路径
storePathRootDir=/app/rocketmq/store
storePathCommitLog=/app/rocketmq/store/commitlog
storePathConsumeQueue=/app/rocketmq/store/consumequeue
storePathIndex=/app/rocketmq/store/index
storeCheckpoint=/app/rocketmq/store/checkpoint
abortFile=/app/rocketmq/store/abort
#Broker 的角色
brokerRole=ASYNC_MASTER
flushDiskType=ASYNC_FLUSH
#Broker 对外服务的监听端口
listenPort=10911
在worker2上配置broker-b的SLAVE服务。修改conf/2m-2s-async/broker-b-s.properties文件,配置示例:
#所属集群名字,名字一样的节点就在同一个集群内
brokerClusterName=rocketmq-cluster
#broker名字,名字一样的节点就是一组主从节点。
brokerName=broker-b
#brokerid,0就表示是Master,>0的都是表示 Slave
brokerId=1
#nameServer地址,分号分割
namesrvAddr=worker1:9876;worker2:9876;worker3:9876
#是否允许 Broker 自动创建Topic,建议线下开启,线上关闭
autoCreateTopicEnable=true
deleteWhen=04
fileReservedTime=120
#存储路径
storePathRootDir=/app/rocketmq/storeSlave
storePathCommitLog=/app/rocketmq/storeSlave/commitlog
storePathConsumeQueue=/app/rocketmq/storeSlave/consumequeue
storePathIndex=/app/rocketmq/storeSlave/index
storeCheckpoint=/app/rocketmq/storeSlave/checkpoint
abortFile=/app/rocketmq/storeSlave/abort
#Broker 的角色
brokerRole=SLAVE
flushDiskType=ASYNC_FLUSH
#Broker 对外服务的监听端口
listenPort=11011
配置过程需要注意的配置项:
-
store开头的一系列配置:表示RocketMQ的存盘文件地址。在同一个机器上需要部署多个Broker服务时,不同服务的存储目录不能相同。
-
listenPort:表示Broker对外提供服务的端口。这个端口默认是10911。在同一个机器上部署多个Broker服务时,不同服务占用的端口也不能相同。
-
如果你使用的是多网卡的服务器,比如阿里云上的云服务器,那么就需要在配置文件中增加配置一个brokerIP1属性,指向所在机器的外网网卡地址。
3、启动Broker服务
集群配置完成后,启动Broker服务。注意启动时需要增加-c参数,指向修改的配置文件。
在worker2上启动broker-a的master服务和broker-b的slave服务:
cd /app/rocketmq/rocketmq-all-4.9.5-bin-release
nohup bin/mqbroker -c ./conf/2m-2s-async/broker-a.properties &
nohup bin/mqbroker -c ./conf/2m-2s-async/broker-b-s.properties &
在worker3上启动broker-b的master服务和broker-a的slave服务:
cd /app/rocketmq/rocketmq-all-4.9.5-bin-release
nohup bin/mqbroker -c ./conf/2m-2s-async/broker-b.properties &
nohup bin/mqbroker -c ./conf/2m-2s-async/broker-a-s.properties &
4、检查集群服务状态
服务的启动状态,可以用jps指令以及nohup.out日志文件进行跟踪。另外在RocketMQ的bin目录下,提供了mqadmin指令,可以通过命令行的方式管理RocketMQ集群。
# 查看集群broker状态
mqadmin clusterList
注意:执行这个指令需要在机器上配置了NAMESRV环境变量
直接使用mqadmin指令会给出所有管理命令,可以通过mqadmin help + 具体指令查看使用方法
Dashboard也是查看集群服务状态的工具。只需要在之前搭建Dashboard时创建的配置文件中增加指定nameserver地址即可。(具体配置参见源码中的配置文件)
rocketmq: config: namesrvAddrs: - worker1:9876 - worker2:9876- worker3:9876
在RocketMQ的这种主从架构的集群下,客户端发送的消息会分散保存到broker-a和broker-b两个服务上,然后每个服务都配有slave服务,可以备份对应master服务上的消息,这样就可以防止单点故障造成的消息丢失问题
为什么要设计这种主从备份,但是不具备主从切换的集群?
参考kafka的设计,主从切换期间可能导致数据丢失,解决办法简单暴力,不切换就好了
升级高可用集群
主从架构的RocketMQ集群,由于给每个broker添加Slave备份,有效防止单点故障问题防止数据丢失。但是这种主从架构仍然存在问题。
当RocketMQ集群中的broker宕机后,整个集群会自动进行broker状态感知。后续客户端的各种请求,依然可以转发到其他正常的broker上。只不过,原本保存在当前broker上的消息,就无法正常读取了,需要等到当前broker服务重启后,才能重新被消息消费者读取。
当一个broker上的服务宕机后,我们可以从对应的slave服务上找到broker上所有的消息。但是很可惜,主从架构中各个服务的角色都是固定了的,slave服务虽然拥有全部的数据,但是它没办法升级成为master服务去响应客户端的请求,依然只是傻傻等待master服务重启后,继续做它的数据备份工作。
RocketMQ提供的Dledger集群,就是具备角色自动转换功能的高可用集群。
整个集群结构如下图所示:
参考文章:Windows部署RocketMQ(超详细)-CSDN博客
这篇关于Rocket-集群搭建的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!