首页 > 软件编程 > java > RocketMQ 4.9.8 集群安装

RocketMQ 4.9.8 集群安装教程：两主两从同步复制异步刷盘(CentOS 7.9)

2026-07-28 09:06:11 作者：二宝哥

在CentOS 7.9上快速部署高可用RocketMQ 4.9.8集群,采用两主两从架构与同步复制模式,本教程将手把手指导您完成环境配置、NameServer部署及Broker启动,确保数据可靠性与写入性能兼备,立即点击,掌握集群验证技巧与调优建议,解决常见故障

1. 集群规划与环境准备

本教程将指导您在 CentOS 7.9（2009 版本）操作系统上，部署一个高可用的 RocketMQ 4.9.8 集群。我们采用经典的“两主两从”架构，并配置为同步复制（SYNC_MASTER）和异步刷盘（ASYNC_FLUSH），以在保证数据可靠性的同时，兼顾写入性能。

1.1 机器规划

假设我们拥有四台服务器，其角色与网络规划如下：

主机名/IP	角色	Broker Name	监听端口
192.168.1.101	NameSrv1，Master 1	broker-a	10911 (Broker), 10909 (HA)
192.168.1.102	NameSrv2，Slave 1 (Master 1 的从节点)	broker-a-s	11911 (Broker), 11909 (HA)
192.168.1.103	NameSrv3，Master 2	broker-b	10911 (Broker), 10909 (HA)
192.168.1.104	Slave 2 (Master 2 的从节点)	broker-b-s	11911 (Broker), 11909 (HA)

架构说明：

两主两从：两个主 Broker（broker-a, broker-b）分别处理不同 Topic 的读写请求，互为备份。每个主节点都有一个对应的从节点（broker-a-s, broker-b-s），在主节点故障时提供高可用。
同步复制 (SYNC_MASTER)：消息在主节点写入成功后，必须同步复制到从节点，从节点确认后才会向生产者返回成功。这保证了数据在主从间的一致性，是数据高可靠的关键。
异步刷盘 (ASYNC_FLUSH)：消息写入内存后即返回成功，由后台线程异步将内存数据持久化到磁盘。这牺牲了极小概率的极端故障数据丢失风险，换取了更高的写入吞吐量。

1.2 环境准备（所有节点）

在四台服务器上均执行以下操作：

系统更新与基础工具

# 更新系统
sudo yum update -y
# 安装必要工具
sudo yum install -y wget vim net-tools lsof java-1.8.0-openjdk-devel

配置 Java 环境

# 检查 Java 版本
java -version
# 应显示 openjdk version "1.8.0_xxx"
# 设置 JAVA_HOME (根据实际路径调整)
echo "export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk" >> ~/.bashrc
echo "export PATH=\$JAVA_HOME/bin:\$PATH" >> ~/.bashrc
source ~/.bashrc

下载 RocketMQ

# 创建安装目录
sudo mkdir -p /opt/rocketmq
cd /opt/rocketmq
# 下载 RocketMQ 4.9.8 二进制包
sudo wget https://archive.apache.org/dist/rocketmq/4.9.8/rocketmq-all-4.9.8-bin-release.zip
# 解压
sudo unzip rocketmq-all-4.9.8-bin-release.zip
sudo mv rocketmq-all-4.9.8-bin-release rocketmq-4.9.8
# 创建日志和数据存储目录
sudo mkdir -p /opt/rocketmq/logs /opt/rocketmq/store

配置系统参数

编辑 /etc/security/limits.conf，在文件末尾添加：

* soft nofile 655350
* hard nofile 655350
* soft nproc 4096
* hard nproc 4096

编辑 /etc/sysctl.conf，添加或修改以下参数：

vm.max_map_count=262144
vm.swappiness=10
fs.file-max=655350

使配置生效：

sudo sysctl -p

2. 配置 NameServer

NameServer 是 RocketMQ 的服务发现组件，所有 Broker 和客户端都需要连接它。我们可以在四台机器中的任意三台（例如 101 102 103）上启动 NameServer，以实现高可用。

启动 NameServer（在 101 102 103 上执行）

cd /opt/rocketmq/rocketmq-4.9.8/bin
# 后台启动 NameServer
nohup sh mqnamesrv &
# 检查日志，确认启动成功
tail -f ~/logs/rocketmqlogs/namesrv.log
# 看到 “The Name Server boot success.” 即表示成功

验证 NameServer 运行

# 查看进程
jps | grep NamesrvStartup
# 应显示进程 ID
# 查看监听端口 (9876)
netstat -tlnp | grep 9876

2.3 NameServer 集群规模选择建议

在规划 RocketMQ 集群时，NameServer 的部署数量是一个常见问题。本文示例部署了两台 NameServer，但实际生产环境中，部署 3 台或更多奇数台 NameServer 通常是更优的选择，原因如下：

高可用与容错：NameServer 采用 去中心化 设计，各节点之间无数据同步，仅存储路由信息（Broker 心跳上报）。客户端和 Broker 会连接所有配置的 NameServer。部署 3 台可以在其中 1 台故障时，集群仍能正常提供服务（剩余 2 台），而 2 台部署在 1 台故障后只剩单点，虽然仍能工作，但容错能力较弱。
避免“脑裂”感知：虽然 NameServer 本身无状态，但某些客户端 SDK 或管理工具在部分 NameServer 不可达时可能产生警告日志。3 台部署能提供更稳定的连接体验。
资源占用极低：NameServer 进程非常轻量（通常占用内存 < 100MB），增加一台的成本很低，但带来的可用性提升显著。

部署建议：

测试/开发环境：1 台即可（单点风险可接受）。
中小型生产环境：至少 2 台，推荐 3 台。本文的 2 台部署是经典最小高可用配置，3 台是更稳健的选择。
大型/金融级生产环境：3 台或更多（如 3-5 台），跨机架或跨可用区部署，进一步提升容灾能力。

配置方式：无论部署几台，只需在 Broker 和客户端的 namesrvAddr 配置中列出所有 NameServer 地址（用分号分隔），例如：

# Broker 配置示例（3台NameServer）
namesrvAddr=192.168.1.101:9876;192.168.1.103:9876;192.168.1.105:9876

3. 配置与启动 Broker 集群

这是核心步骤，需要为每个 Broker 节点创建独立的配置文件。

3.1 配置 Master 1 (192.168.1.101, broker-a)

进入配置目录并创建配置文件：

cd /opt/rocketmq/rocketmq-4.9.8/conf/2m-2s-sync
# 复制主节点模板
sudo cp broker-a.properties broker-a.properties.backup
# 编辑配置文件
sudo vim broker-a.properties

修改 broker-a.properties 关键内容如下：

# Broker 集群名称，同一集群内所有节点必须一致
brokerClusterName=DefaultCluster
# Broker 名称，主从配对使用相同的 brokerName
brokerName=broker-a
# 0 表示 Master，大于 0 表示 Slave
brokerId=0
# 删除文件时间点，默认凌晨 4 点
deleteWhen=04
# 文件保留时间，默认 48 小时
fileReservedTime=48
# Broker 角色：SYNC_MASTER 表示同步复制主节点
brokerRole=SYNC_MASTER
# 刷盘方式：ASYNC_FLUSH 表示异步刷盘
flushDiskType=ASYNC_FLUSH
# NameServer 地址列表，用分号分隔
namesrvAddr=192.168.1.101:9876;192.168.1.103:9876
# Broker 监听端口
listenPort=10911
# HA 监听端口（主从同步）
haListenPort=10909
# 存储路径
storePathRootDir=/opt/rocketmq/store
storePathCommitLog=/opt/rocketmq/store/commitlog
storePathConsumeQueue=/opt/rocketmq/store/consumequeue
storePathIndex=/opt/rocketmq/store/index
storeCheckpoint=/opt/rocketmq/store/checkpoint
abortFile=/opt/rocketmq/store/abort
# 自动创建 Topic，生产环境建议关闭
autoCreateTopicEnable=true

3.2 配置 Slave 1 (192.168.1.102, broker-a-s)

在 102 节点上，编辑配置文件 broker-a-s.properties：

brokerClusterName=DefaultCluster
brokerName=broker-a
# Slave 节点的 brokerId 必须大于 0
brokerId=1
brokerRole=SLAVE
flushDiskType=ASYNC_FLUSH
namesrvAddr=192.168.1.101:9876;192.168.1.103:9876
# 从节点使用不同的端口，避免冲突
listenPort=11911
haListenPort=11909
storePathRootDir=/opt/rocketmq/store
storePathCommitLog=/opt/rocketmq/store/commitlog
storePathConsumeQueue=/opt/rocketmq/store/consumequeue
storePathIndex=/opt/rocketmq/store/index
storeCheckpoint=/opt/rocketmq/store/checkpoint
abortFile=/opt/rocketmq/store/abort
autoCreateTopicEnable=true

3.3 配置 Master 2 (192.168.1.103, broker-b)

在 103 节点上，编辑配置文件 broker-b.properties：

brokerClusterName=DefaultCluster
brokerName=broker-b
brokerId=0
brokerRole=SYNC_MASTER
flushDiskType=ASYNC_FLUSH
namesrvAddr=192.168.1.101:9876;192.168.1.103:9876
listenPort=10911
haListenPort=10909
storePathRootDir=/opt/rocketmq/store
storePathCommitLog=/opt/rocketmq/store/commitlog
storePathConsumeQueue=/opt/rocketmq/store/consumequeue
storePathIndex=/opt/rocketmq/store/index
storeCheckpoint=/opt/rocketmq/store/checkpoint
abortFile=/opt/rocketmq/store/abort
autoCreateTopicEnable=true

3.4 配置 Slave 2 (192.168.1.104, broker-b-s)

在 104 节点上，编辑配置文件 broker-b-s.properties：

brokerClusterName=DefaultCluster
brokerName=broker-b
brokerId=1
brokerRole=SLAVE
flushDiskType=ASYNC_FLUSH
namesrvAddr=192.168.1.101:9876;192.168.1.103:9876
listenPort=11911
haListenPort=11909
storePathRootDir=/opt/rocketmq/store
storePathCommitLog=/opt/rocketmq/store/commitlog
storePathConsumeQueue=/opt/rocketmq/store/consumequeue
storePathIndex=/opt/rocketmq/store/index
storeCheckpoint=/opt/rocketmq/store/checkpoint
abortFile=/opt/rocketmq/store/abort
autoCreateTopicEnable=true

3.5 启动所有 Broker

分别在四台机器上启动对应的 Broker 服务：

# 在 101 (Master 1) 上执行
cd /opt/rocketmq/rocketmq-4.9.8/bin
nohup sh mqbroker -c /opt/rocketmq/rocketmq-4.9.8/conf/2m-2s-sync/broker-a.properties &
在 102 (Slave 1) 上执行
cd /opt/rocketmq/rocketmq-4.9.8/bin
nohup sh mqbroker -c /opt/rocketmq/rocketmq-4.9.8/conf/2m-2s-sync/broker-a-s.properties &
在 103 (Master 2) 上执行
cd /opt/rocketmq/rocketmq-4.9.8/bin
nohup sh mqbroker -c /opt/rocketmq/rocketmq-4.9.8/conf/2m-2s-sync/broker-b.properties &
在 104 (Slave 2) 上执行
cd /opt/rocketmq/rocketmq-4.9.8/bin
nohup sh mqbroker -c /opt/rocketmq/rocketmq-4.9.8/conf/2m-2s-sync/broker-b-s.properties &

启动后，查看日志确认：

tail -f ~/logs/rocketmqlogs/broker.log
# 看到 “The broker[broker-name, IP:port] boot success.” 即表示成功

4. 集群验证与管理

4.1 查看集群状态

使用 RocketMQ 自带的管理命令查看集群状态：

# 在任意一台已启动 NameServer 的机器上执行
cd /opt/rocketmq/rocketmq-4.9.8/bin
# 查看集群信息
sh mqadmin clusterList -n 192.168.1.101:9876

输出应显示四个 Broker，其中两个 BROKER_ID=0 的为 Master，两个 BROKER_ID=1 的为 Slave，并且主从配对正确。

4.2 生产与消费测试

设置环境变量（测试机）

export NAMESRV_ADDR="192.168.1.101:9876;192.168.1.103:9876"

发送测试消息

cd /opt/rocketmq/rocketmq-4.9.8/bin
# 启动一个生产者示例，发送 10 条消息到 Topic “TestClusterTopic”
sh tools.sh org.apache.rocketmq.example.quickstart.Producer

消费测试消息

# 启动一个消费者示例，消费 “TestClusterTopic” 的消息
sh tools.sh org.apache.rocketmq.example.quickstart.Consumer

4.3 控制台部署（可选）

RocketMQ Console 是一个可视化的管理控制台。

# 下载并解压 RocketMQ Console
cd /opt
wget https://github.com/apache/rocketmq-dashboard/archive/refs/tags/rocketmq-dashboard-1.0.0.zip
unzip rocketmq-dashboard-1.0.0.zip
cd rocketmq-dashboard-rocketmq-dashboard-1.0.0
# 修改配置文件 application.yml 中的 namesrvAddr
vim src/main/resources/application.yml
# 将 namesrvAddr 改为：192.168.1.101:9876;192.168.1.103:9876
# 打包并运行
mvn clean package -Dmaven.test.skip=true
java -jar target/rocketmq-dashboard-1.0.0.jar
# 访问 http://服务器IP:8080 即可查看集群状态

5. 关键配置解析与调优建议

同步复制 (SYNC_MASTER)：确保主从数据强一致，但会略微增加写入延迟。如果对延迟极度敏感且可容忍主节点故障时少量数据丢失，可考虑 ASYNC_MASTER。
异步刷盘 (ASYNC_FLUSH)：性能好，是默认推荐。若对数据可靠性要求极高（如金融交易），可改为 SYNC_FLUSH，但性能会下降。
内存与文件映射：根据服务器内存调整 broker.conf 中的 mapedFileSizeCommitLog（CommitLog 文件大小，默认 1G）和 mapedFileSizeConsumeQueue（消费队列文件大小，默认 600W * 20 字节）。
主从切换：当主节点宕机时，从节点不会自动升级为主节点。需要借助 RocketMQ 的 DLeger 组件或外部监控脚本实现自动故障转移。

6. 常见问题排查

启动失败： 检查 Java 环境、端口占用、防火墙（需开放 9876, 10911, 10909, 11在CentOS 7.9上快速部署高可用RocketMQ 4.9.8集群,采用两主两从架构与同步复制模式,本教程将手把手指导您完成环境配置、NameServer部署及Broker启动,确保数据可靠性与写入性能兼备,立即点击,掌握集群验证技巧与调优建议,解决常见故障

到此这篇关于RocketMQ 4.9.8 集群安装教程：两主两从同步复制异步刷盘(CentOS 7.9)的文章就介绍到这了,更多相关RocketMQ 4.9.8 集群安装内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！