RocketMQ的集群部署

本文介绍RocketMQ集群的几种部署方式,包括2m-noslave、2m-2s-async和2m-2s-sync,并详细讲解了2m-noslave的配置过程。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

先理解一些重要概念及说明

Disk Flush(磁盘刷新/同步操作):就是将内存的数据落地,存储在磁盘中。RocketMQ提供了以下两种模式:

SYNC_FLUSH(同步刷盘):生产者发送的每一条消息都在保存到磁盘成功后才返回告诉生产者成功。这种方式不会存在消息丢失的问题,但是有很大的磁盘IO开销,性能有一定影响。
ASYNC_FLUSH(异步刷盘):生产者发送的每一条消息并不是立即保存到磁盘,而是暂时缓存起来,然后就返回生产者成功。随后再异步的将缓存数据保存到磁盘,有两种情况:1是定期将缓存中更新的数据进行刷盘,2是当缓存中更新的数据条数达到某一设定值后进行刷盘。这种方式会存在消息丢失(在还未来得及同步到磁盘的时候宕机),但是性能很好。默认是这种模式。

Broker Replication(Broker间数据同步/复制):集群环境下需要部署多个Broker,Broker分为两种角色:一种是master,即可以写也可以读,其brokerId=0,只能有一个;另外一种是slave,只允许读,其brokerId为非0。一个master与多个slave通过指定相同的brokerName被归为一个broker set(broker集)。通常生产环境中,我们至少需要2个broker set。Broker Replication只的就是slave获取或者是复制master的数据。

Sync Broker:生产者发送的每一条消息都至少同步复制到一个slave后才返回告诉生产者成功,即“同步双写”。
Async Broker:生产者发送的每一条消息只要写入master就返回告诉生产者成功。然后再“异步复制”到slave。

推荐的几种Broker集群方式:(官网提供了下面几种集群方式的配置文件供参考,在$ROCKETMQ_HOME/target/apache-rocketmq-all/conf目录下)

2m-2s-sync:两主两从同步双写(两个master,两个slave,数据同步双写到master和slave)
2m-2s-async:两主两从异步复制(两个master,两个slave,master数据通过异步复制到slave)
2m-noslave:两主(只有两个master,没有slave)
注意:
1、上述“2”只是说作为一个集群的最低配置数量,可以根据实际情况扩展。
2、所有的刷盘(Dish Flush)操作全部默认为:ASYNC_FLUSH(异步刷盘)。

Name Server集群: Name Server集群比较简单,只要部署多个实例就行了,多个实例间不需要进行数据共享,只要保证一个实例存活就可以正常运转。

三种Broker集群方式优缺点

上面三种集群方式的优缺点(主要区别在于主从复制方式):

多Master模式(2m-noslave)
一个集群无Slave,全是Master,例如2个Master或者3个Master
优点:配置简单,单个Master宕机或重启维护对应用无影响,在磁盘配置为RAID10时,即使机器宕机不可恢复情况下,由于RAID10磁盘非常可靠,消息也不会丢(异步刷盘丢失少量消息,同步刷盘一条不丢)。性能最高。
缺点:单台机器宕机期间,这台机器上未被消费的消息在机器恢复之前不可订阅,消息实时性会受到受到影响。

多Master多Slave模式,异步复制(2m-2s-async)
每个Master配置一个Slave,有多对Master-Slave,HA采用异步复制方式,主备有短暂消息延迟,毫秒级。
优点:即使磁盘损坏,消息丢失的非常少,且消息实时性不会受影响,因为Master宕机后,消费者仍然可以从Slave消费,此过程对应用透明。不需要人工干预。性能同多Master模式几乎一样。
缺点: Master宕机,磁盘损坏情况,会丢失少量消息。

多Master多Slave模式,同步双写(2m-noslave)
每个Master配置一个Slave,有多对Master-Slave,HA采用同步双写方式,主备都写成功,向应用返回成功。
优点:数据与服务都无单点,Master宕机情况下,消息无延迟,服务可用性与数据可用性都非常高
缺点:性能比异步复制模式略低,大约低10%左右,发送单个消息的RT会略高。目前主宕机后,备机不能自动切换为主机,后续会支持自动切换功能。

集群部署详解

由于所开虚拟机有限,所以我这边采用的是2m-noslave集群,其他集群只需要在此基础上修改写配置即可。后面会附带配置详解。

Master1 IP:192.168.51.145
Master2 IP:192.168.51.146

修改俩台master中的hosts文件:

# vim /etc/hosts

添加以下信息:

192.168.51.145 mqnameserver1
192.168.51.145 rocketmq-master1
192.168.51.146 mqnameserver2
192.168.51.146 rocketmq-master2

这里写图片描述

为避免服务器重名出现,建议进行以下操作:

(1)Master1服务器

# sed -i  '/HOSTNAME/d' /etc/sysconfig/network
# echo 'HOSTNAME=rocketmq-master1'  >> /etc/sysconfig/network
# hostname rocketmq-master1

(2)Master2服务器

# sed -i  '/HOSTNAME/d' /etc/sysconfig/network
# echo 'HOSTNAME=rocketmq-master2'  >> /etc/sysconfig/network
# hostname rocketmq-master2

执行结束后,重启服务器,发现主机名更改

安装RocketMQ方法与之前单机安装相同,直至启动步骤为止(不启动);参考http://blog.youkuaiyun.com/tam_king/article/details/78717001

修改RocketMQ配置

(1)、Master1服务器
进入/rocketmq/conf/2m-noslave目录下修改broker-a.properties文件

brokerClusterName=AdpMqCluster
brokerName=broker-a
brokerId=0  
namesrvAddr=mqnameserver1:9876;mqnameserver2:9876
defaultTopicQueueNums=4
autoCreateTopicEnable=true
autoCreateSubscriptionGroup=true
listenPort=10911
deleteWhen=04
fileReservedTime=120
mapedFileSizeCommitLog=1073741824
mapedFileSizeConsumeQueue=50000000
destroyMapedFileIntervalForcibly=120000
redeleteHangedFileInterval=120000
diskMaxUsedSpaceRatio=88
storePathRootDir=/data/rocketmq/store
storePathCommitLog=/data/rocketmq/store/commitlog
maxMessageSize=65536
flushCommitLogLeastPages=4
flushConsumeQueueLeastPages=2
flushCommitLogThoroughInterval=10000
flushConsumeQueueThoroughInterval=60000
brokerRole=ASYNC_MASTER
flushDiskType=ASYNC_FLUSH
checkTransactionMessageEnable=false
sendMessageThreadPoolNums=128
pullMessageThreadPoolNums=128

(2)、Master2服务器
进入/rocketmq/conf/2m-noslave目录下修改broker-b.properties文件

brokerClusterName=AdpMqCluster
brokerName=broker-b
brokerId=0
namesrvAddr=mqnameserver1:9876;mqnameserver2:9876
defaultTopicQueueNums=4
autoCreateTopicEnable=true
autoCreateSubscriptionGroup=true
listenPort=10911
deleteWhen=04
fileReservedTime=120
mapedFileSizeCommitLog=1073741824
mapedFileSizeConsumeQueue=50000000
destroyMapedFileIntervalForcibly=120000
redeleteHangedFileInterval=120000
diskMaxUsedSpaceRatio=88
storePathRootDir=/data/rocketmq/store
storePathCommitLog=/data/rocketmq/store/commitlog
maxMessageSize=65536
flushCommitLogLeastPages=4
flushConsumeQueueLeastPages=2
flushCommitLogThoroughInterval=10000
flushConsumeQueueThoroughInterval=60000
brokerRole=ASYNC_MASTER
flushDiskType=ASYNC_FLUSH
checkTransactionMessageEnable=false
sendMessageThreadPoolNums=128
pullMessageThreadPoolNums=128

Broker参数说明

这里写图片描述

服务启动

# mkdir -p /data/rocketmq/store/commitlog/data/logs
在conf目录下执行
# sed -i  's#${user.home}#/data#g' *.xml 【替换.xml文件中的主机名】

启动NameServer
bin目录下执行

# nohup sh mqnamesrv &

启动Broker
Master1服务器bin目录下执行

# nohup sh mqbroker -c ../conf/2m-noslave/broker-a.properties  >/dev/null 2>&1 & 【指定文件开启】

Master2服务器bin目录下执行

# nohup sh mqbroker -c ../conf/2m-noslave/broker-b.properties  >/dev/null 2>&1 & 【指定文件开启】

最后用jps指令检查是否开启程序

下期将部署可视化管理控制台。谢谢大家!

### 关于 RocketMQ 集群部署的最佳实践 #### 1. 环境准备 在开始部署之前,需确认满足以下系统要求: - 使用64位操作系统,推荐 Linux 平台。 - JDK 版本应为 1.8 或更高版本。 - 如果需要通过源码编译安装,则还需要 Maven 3.2.x 及以上版本。 下载 RocketMQ 的二进制包可以通过官方地址完成。例如,在理想汽车的大规模集群部署实践中提到的下载链接为 `https://dlcdn.apache.org/rocketmq/4.9.3/rocketmq-all-4.9.3-bin-release.zip`[^1]。此步骤确保获取到稳定版本的软件包。 --- #### 2. 名称服务器 (Nameserver) 和代理节点 (Broker) 的分离部署 为了提高系统的可靠性和稳定性,名称服务器与代理节点应当分别部署在不同的物理机上以实现资源隔离。这种设计可以有效防止因单点故障引发的服务中断问题[^3]。具体来说: - **Nameserver**: 负责存储元数据信息以及协调整个集群的工作状态。由于其职责较为轻量级,通常可以在较小规格的硬件设备上运行。 - **Broker**: 承担实际的消息存储功能,因此对其性能需求较高,建议分配高性能计算资源给它使用。 此外,还应注意调整 Nameserver 连接策略。当检测到网络延迟或者通信失败时,及时断开不健康的连接并重新选举新的 NameServer 实例作为目标对象进行交互操作[^5]。 --- #### 3. 参数优化与调优 针对某些特定场景下的应用特性,可能需要对默认配置文件做出适当修改以便更好地适配业务逻辑需求。以下是几个重要的方面考虑因素: - 设置合理的超时时长参数(如 clientCloseSocketIfTimeout),从而减少不必要的等待时间消耗;虽然目前该选项默认关闭状态(false),但在高并发环境下开启此项可能会带来显著收益效果。 ```bash # 修改 conf/client.properties 文件中的相关内容 clientCloseSocketIfTimeout=true ``` - 对日志路径加以定义指定位置(${user.home})之外的地方,比如统一放置至 /var/log/rocketmq 目录下便于后续集中管理维护工作开展[^1]。 --- #### 4. 故障排查机制完善 即使采用了分布式架构模式构建起来的消息队列系统仍然无法完全规避各类潜在风险事件的发生概率。为此,在日常运维过程中必须建立健全完善的监控报警体系结构用来快速定位解决问题所在之处[^4]: - 定期检查各组件间的心跳信号交换情况是否正常; - 记录详细的错误日志供事后分析研究之用; - 制定应急预案手册指导相关人员按照既定流程妥善处理突发状况。 --- ### 总结 综上所述,成功实施一套高效稳定的 RocketMQ 集群解决方案不仅依赖于前期精心规划好的软硬件基础设施建设基础之上,同时也离不开后期持续不断地跟踪观察改进措施落实到位程度如何影响整体表现水平高低与否的关键环节控制要点掌握熟练度至关重要!
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值