RocketMQ升级分布式集群

臻的很好
62 阅读9分钟

之前我们⽤⼀台Linux服务器，快速搭建起了⼀整套RocketMQ的服务。但是很明显，这样搭建的服务是⽆法 放到⽣产环境上去⽤的。⼀旦nameserver服务或者broker服务出现了问题，整个RocketMQ就⽆法正常⼯作。 ⽽且更严重的是，如果服务器出现了问题，⽐如磁盘坏了，那么存储在磁盘上的数据就会丢失。这时 RocketMQ暂存到磁盘上的消息也会跟着丢失，这个问题就非常严重了。因此，我们需要搭建⼀个分布式的 RocketMQ服务集群，来防⽌单点故障问题。

RocketMQ的分布式集群基于主从架构搭建。在多个服务器组成的集群中，指定⼀部分节点作为Master节点， 负责响应客户端的请求。指令另⼀部分节点作为Slave节点，负责备份Master节点上的数据，这样，当Master 节点出现故障时，在Slave节点上可以保留有数据备份，⾄少保证数据不会丢失。 整个集群⽅案如下图所示：

图片.png

接下来我们准备三台相同的Linux服务器，搭建⼀下RocketMQ的分布式集群。为了更清晰的描述这三台服务 器上的操作，我们给每个服务器指定⼀个机器名。

cat /etc/hosts 
192.168.65.112 worker1 
192.168.65.170 worker2 
192.168.65.193 worker3

为了便于观察，我们这次搭建⼀个2主2从的RocketMQ集群，并将主节点和节点都分别部署在不同的服务器 上。预备的集群规划情况如下：

图片.png

第⼀步：部署nameServer服务。 nameServer服务不需要做特别的配置，按照之前的步骤，在三台服务器上都分别部署nameServer服务即可。

第⼆步：对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
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

这⾥对⼏个需要重点关注的属性，做下简单介绍：

  • 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
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。

这样，第⼀组broker服务就配置好了。

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
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
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

这样就完成了2主2从集群的配置。配置过程汇总有⼏个需要注意的配置项：

  • store开头的⼀系列配置：表示RocketMQ的存盘⽂件地址。在同⼀个机器上需要部署多个Broker服务时， 不同服务的存储⽬录不能相同。
  • listenPort：表示Broker对外提供服务的端⼝。这个端⼝默认是10911。在同⼀个机器上部署多个Broker服 务时，不同服务占⽤的端⼝也不能相同。
  • 如果你使用的是多⽹卡的服务器，⽐如阿⾥云上的云服务器，那么就需要在配置⽂件中增加配置⼀个 brokerIP1属性，指向所在机器的外⽹⽹卡地址。

第三步：启动Broker服务

集群配置完成后，需要启动Broker服务。与之前启动broker服务稍有不同，启动时需要增加-c参数，指向我们 修改的配置⽂件。

在worker2上启动broker-a的master服务和broker-b的slave服务：

cd /app/rocketmq/rocketmq-all-5.3.0-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-5.3.0-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 &

第四步：检查集群服务状态 对于服务的启动状态，我们依然可以⽤之前介绍的jps指令以及nohup.out⽇志⽂件进⾏跟踪。不过，在 RocketMQ的bin⽬录下，也提供了mqadmin指令，可以通过命令⾏的⽅式管理RocketMQ集群。

例如下⾯的指令可以查看集群broker集群状态。通过这个指令可以及时了解集群的运⾏状态。

[root@192-168-65-112 app]# cd rocketmq/rocketmq-all-5.3.0-bin-release/
[root@192-168-65-112 rocketmq-all-5.3.0-bin-release]# bin/mqadmin clusterList
#Cluster Name #Broker Name #BID #Addr #Version
#InTPS(LOAD) #OutTPS(LOAD) #Timer(Progress) #PCWait(ms) #Hour #SPACE
#ACTIVATED
rocketmq-cluster broker-a 0 192.168.65.170:10911 V5_3_0
0.00(0,0ms) 0.00(0,0ms) 0-0(0.0w, 0.0, 0.0) 0 479168.95 0.1100 true
rocketmq-cluster broker-a 1 192.168.65.193:11011 V5_3_0
0.00(0,0ms) 0.00(0,0ms) 3-0(0.0w, 0.0, 0.0) 0 479168.95 0.1100 false
rocketmq-cluster broker-b 0 192.168.65.193:10911 V5_3_0
0.00(0,0ms) 0.00(0,0ms) 0-0(0.0w, 0.0, 0.0) 0 479168.95 0.1100 truemqadmin指令还提供了⾮常丰富的管理功能。你可以尝试直接使⽤mqadmin指令，就会列出mqadmin⽀持的 所有管理指令。如果对某⼀个指令不会使⽤，还可以使⽤mqadmin help 指令查看帮助
rocketmq-cluster broker-b 1 192.168.65.170:11011 V5_3_0
0.00(0,0ms) 0.00(0,0ms) 2-0(0.0w, 0.0, 0.0) 0 479168.95 0.1100 
false

mqadmin指令还提供了⾮常丰富的管理功能。你可以尝试直接使⽤mqadmin指令，就会列出mqadmin⽀持的 所有管理指令。如果对某⼀个指令不会使⽤，还可以使⽤mqadmin help 指令查看帮助

另外，之前搭建的dashboard也是集群服务状态的很好的⼯具。只需要在之前搭建Dashboard时创建的配置⽂ 件中增加指定nameserver地址即可。

rocketmq:
    config:
        namesrvAddrs:
            - worker1:9876
            - worker2:9876
            - worker3:9876

启动完成后，在集群菜单⻚就可以看到集群的运⾏情况

图片.png

在RocketMQ的这种主从架构的集群下，客户端发送的消息会分散保存到broker-a和broker-b两个服务上，然 后每个服务都配有slave服务，可以备份对应master服务上的消息，这样就可以防⽌单点故障造成的消息丢失 问题。

avatar
文章
阅读
粉丝