原创

分布式消息中间件(三)——RocketMQ生产部署

上一章,我们介绍了RocketMQ的基本架构,但是对于RocketMQ的很多底层原理还没有展开讨论,比如Rocket是如何做到高性能的?如何进行持久化?如何防止消息丢失等等。

本章,我们先来看下如果要在我们自己的生产环境部署RocketMQ,需要做哪些事情?如何进行部署?后续章节再去研究RocketMQ的底层原理。

一、业务量评估

首先,我们需要对业务量(日活用户数、日访问数、日新增数据量等运营指标)进行一个预估,可以参考已有的一些类似系统,具体的指标因业务而已。系统上线规划时,一般需要考虑三个时间段:一月、一年、三年。然后根据评估的业务量确定系统的逻辑架构图,要用多少台机器,每台机器什么配置等等。

我们这里不做详细论述,由于我们是使用RocketMQ,官方说明的单个Broker节点可以抗住10万QPS请求,所以我们初期部署RocketMQ的目标就是支撑10万QPS,那么就先用一台机器部署一个Master-Broker节点,考虑到可用性再加2个Slave节点,整个系统的逻辑架构图如下:



NameServer:3台机器,每台8核CPU + 16G内存 + 500G磁盘 + 千兆网卡
Broker:3台机器,每台24核CPU + 48G内存 + 1TB磁盘 + 千兆网卡
生产者:2台机器,每台4核CPU + 8G内存 + 500GB磁盘 + 千兆网卡
消费者:2台机器,每台4核CPU + 8G内存 + 500GB磁盘 + 千兆网卡

NameServer用作路由服务,主要承载以下请求:Broker心跳、生产者/消费者拉取路由信息,所以负载其实很低,不需要特别高的机器配置,8核16G足以,部署三台主要保证可用性。

Broker是核心组件,需要承载高并发写入和海量数据存储,所以对配置要求较高,一般至少要给16核32G的机器,考虑到官方说单台可以抗10万QPS,而我们的目标就是支撑10万QPS,所以我先不做数据分片,只用3台机器组成一个主从集群。

生产者和消费者机器都是临时用来做性能压测的,一般就是业务系统,用标准的4核8G机器部署就可以。

二、NameServer部署

RocketMQ依赖JDK,所以需要先机器上安装JDK,同时在环境变量中设置JAVE_HOME。

2.1 构建Dledger

RocketMQ 4.5版本以后,依赖Dledger进行主从切换,所以我们需要先构建Dledger。在三台NameServer的机器上分别执行以下命令,拉取Dledger并进行打包构建:

git clone https://github.com/openmessaging/openmessaging-storage-dledger.git
cd openmessaging-storage-dledger
mvn clean install -DskipTests

2.2 构建RocketMQ

接着,在三台NameServer的机器上分别执行以下命令构建RocketMQ:

git clone https://github.com/apache/rocketmq.git
cd rocketmq
git checkout -b store_with_dledger origin/store_with_dledger
mvn -Prelease-all -DskipTests clean install -U

然后进入目录distribution/target/apache-rocketmq,编辑RocketMQ的三个启动配置bin/runserver.shbin/runbroker.shbin/tools.sh,分别在里面找到如下三行:

[ ! -e "$JAVA_HOME/bin/java" ] && JAVA_HOME=$HOME/jdk/java
[ ! -e "$JAVA_HOME/bin/java" ] && JAVA_HOME=/usr/java
[ ! -e "$JAVA_HOME/bin/java" ] && error_exit "Please set the JAVA_HOME variable in your environment, We need java(x64)!"

删除上述的第2、3行,并将第1行的值改为自己机器上的JDK主目录。

Linux中可以用命令/usr/libexec/java_home -V,查看Java主目录。

2.3 启动NameServer

执行以下命令启动NameServer,NameServer默认监听9876端口:

nohup sh mqnamesrv &

三、Broker部署

Broker的部署方式和NameServer几乎完全相同,先在三台Broker的机器上设置好JAVA_HOME,然后构建Dledger和RocketMQ,修改启动配置,只不过最后用Broker的启动命令来启动:

nohup sh bin/mqbroker -c conf/dledger/broker-n0.conf &

这里注意下broker-n0.conf这个配置文件,它是我们自己新建的,表示Broker的一些配置信息。每台机器上的Broker配置的序号不一样,比如我们有3台机器,那么第一台的Broker配置文件是broker-n0.conf,第二台的broker配置文件可以是broker-n1.conf,第三台可以是broker-n2.conf

3.1 Broker配置

我们第一台机器的broker-n0.conf为例,看下配置文件是怎么样的:

#Broker集群名称,自定义
brokerClusterName = RaftCluster

#Broker分组名称,比如你有一个Master和两个Slave,那么他们的Broker名称必须是一样的,因为他们三个是一个分组;如果你有另外一组Master和两个Slave,你可以给他们起个别的名字,比如说RaftNode01
brokerName=RaftNode00

#当前Broker节点监听的端口号
listenPort=30911

#NameServer地址,如果有多个NameServer构成集群的话,写入多个NameServer的地址(分号分隔)
namesrvAddr=IP:9876

#下面两个目录是Broker存放数据的地方,自定义
storePathRootDir=/tmp/rmqstore/node00
storePathCommitLog=/tmp/rmqstore/node00/commitlog

#是否启用DLeger技术
enableDLegerCommitLog=true

#dLeger分组名字,和brokerName保持一致即可
dLegerGroup=RaftNode00

#dLeger所管理的组内Broker节点,比如有三台机器部署了Broker作为一个组(1Master2Slave),那么在这里就写入他们三个的ip地址和监听端口号,注意配置项的组成格式为dLegerSelfId-地址:端口
dLegerPeers=n0-127.0.0.1:30911;n1-IP:30911;n2-IP:30911

#当前Broker节点在dLeger组内的id,组内唯一,与dLegerPeers中的n0、n1、n2相匹配
dLegerSelfId=n0

#发送消息的线程数量,一般建议配置成机器的CPU核数,比如我们的机器是24核,那这里就改成24核
sendMessageThreadPoolNums=24

3.2 启动Broker

将上述broker-n0.conf的内容复制到另外两台机器上,文件名分别重命名为broker-n1.confbroker-n2.conf中,然后修改dLegerSelfId分别为n1和n2,dLegerPeers中的IP也注意相应修改,最后分别执行启动命令(nX自行替换):

nohup sh bin/mqbroker -c conf/dledger/broker-nX.conf &

3.3 检查集群状态

我们已经启动了NameServer集群和Broker集群,可以通过以下命令(127.0.0.1替换成NameServer的IP)来检查下集群状态:

sh bin/mqadmin clusterList -n 127.0.0.1:9876

你会看到三行记录,其中会出现BID是0、1、2,也有可能是0、1、3,这说明RocketMQ集群启动成功了,BID为0的是Master,BID>0的都是Slave(这里也可以叫做Leader和Follower)

接着就可以尝试一下Broker集群是否会进行故障自动转移了,我们可以先通过命令lsof -i:端口找到Master-Broker的进程PID,然后用kill -9干掉它,接着等待个10s,再次执行命令查看集群状态,此时就会发现BID为0的节点变成另外一个Broker了。

四、总结

本章,我们通过一个示例讲解了RocketMQ如何进行部署,主要分为NameServer部署和Broker部署,复杂点主要在于Broker部署时的配置。

当我们部署完RocketMQ,是否就可以直接迁到生产环境使用了呢?显然不是的,我们需要调整Broker的OS内核参数、JVM参数进行优化,然后进行性能压测,确认在当前物理架构下,RabbitMQ的极限负载,然后再确定是否以当前物理架构上生产。

正文到此结束
本文目录