RocketMQ集群平滑扩缩容【实战笔记】

梁勇 2020-05-21 10:54:31

​作者介绍

老梁,哈啰出行高级技术专家,负责服务框架&消息平台。参与了《RocketMQ技术内幕》审稿工作。专注后端中间件方向,在公众号【瓜农老梁】已陆续发表RocketMQ系列、Kafka系列、gRPC系列、Sentinel系列、Java NIO系列。其中RocketMQ系列已发表40余篇。源码、实战、原理、调优期待与你一起学习。

 

一、运维需求

 

在 RocketMQ 集群的实践中,对集群扩容、缩容、节点下线等运维做到平滑、业务无感知、数据无丢失,这个对于集群运维的同学来说非常重要。

 

比如前些日子出现的问题,由于线上集群频繁出现 CPU 毛刺甚至直接挂掉并伴随着集群抖动,对内核参数的调整只能减缓毛刺却不能消除抖动。集群抖动业务使用会伴随着发送延迟告警,始终是个必须处理的隐患。最终决定更换操作系统即更换内核。

 

 

集群信息: RocketMQ版本4.5.2

主从信息:4主4从 broker-a, broker-b, broker-c, broker-d,

broker-a(slave), broker-b(slave), broker-c(slave), broker-d(slave)

 

集群的部署如下下图所示:

 

其需要简单概括如下,就是要将上述集群的操作系统内核从 Centos6 升级到 Centos7,但业务不能停。

 

二、平滑扩容

 

1、下线从节点
 

 

从节点正常关闭 rocketmq,从节点下线对业务不会造成影响,如果配置,slaveReadEnable = true,从节点的通常在消息回溯延迟超过内存消息的40%时使用。

 

 

sh bin/mqshutdown broker

or

kill pid

 

从节点下线之后,集群的部署情况如下图所示:

 

直接停掉从节点,并不影响当前业务的使用,因为写,读都可以通过主节点,对业务无影响。

 

2、重组主从模式
 

 

新申请4台机器与原从节点重新组合成主从关系。

 

具体操作为将新申请的4台机器的内核全部升级为Centos7内核,并部署为 broker-a1,broker-b1,broker-c1,broker-d1,这里如果使用 broker-e,f,f,h 命名,会造成流量切斜,导致消费不均衡,原因在文末会给出,大家不妨思考一下。

 

然后将上一步下掉的从节点,其内核全部升级为 centos7的内核。并将这些节点设置为新增4个主节点的从,其部署结构如下图所示:

 

此时集群中变成8主,其中新增集群有从节点,即装有centor7内核的新机器构成了4主4从,接下来就只需要将内核为centos6的主节点的数据消费完成,并下线即可。

 

三、平滑缩容

 

接下来主要是将装有centos6内核的旧机器从集群中移除,具体操作如下。

 

1、关闭broker写权限
 

 

逐台关闭 broker-a, broker-b, broker-c, broker-d 的写入权限,其中4表示只读权限,6表示读写权限。

 

 

bin/mqadmin updateBrokerConfig -b x.x.x.x:10911 -n x.x.x.x:9876 -k brokerPermission -v 4

Java HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize=128m; support was removed in 8.0

Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=128m; support was removed in 8.0

update broker config success, x.x.x.x:10911

 
2、验证broker流量情况
 

 

 

bin/mqadmin clusterList -n x.x.x.x:9876

 

等待broker出入流量均归零

 

3、验证broker积压情况
 

 

 

bin/mqadmin brokerConsumeStats -b x.x.x.x:10911 -n x.x.x.x:9876

 

观察最后一行 Diff Total 等于 0 时表示该节点已经没有积压,即全部消费完毕。

 

4、节点下线
 

 

当节点流量和积压都为0时,节点可以下线了。如果broker一直有流量或者积压一直存在呢?通常线上集群的存储时间为2~3天;可以在过了存储时间后再安排下线。

 

 

sh bin/mqshutdown broker

or

kill pid

 

四、问题答疑

 

上文中有提到过扩容新增节点时命名时不要使用 broker-e, broker-f, broker-g, broker-h;而采用broker-a1, broker-b1, broker-c1, broker-d1。

 

按照默认平均分配消费算法,如果采用第一种命名,当关闭broker-a, broker-b, broker-c, broker-d的写入权限时,数据会全部集中在broker-e, broker-f, broker-g, broker-h节点,假如线上部署了四台消费机器,会有两台机器分到broker-a, broker-b, broker-c, broker-d的分区,而另外两台机器分到broker-e, broker-f, broker-g, broker-h的分区。

 

而broker-a, broker-b, broker-c, broker-d节点的写权限被关闭后,会造成其中两台节点无数据,数据全部分配到另外的消费机器上。

 

因为只是关闭了broker-a,b,c,d的写权限,读权限未关闭,但如果使用broker-a,a1,b,b1这种命名方式,就能平衡其流量,不至于连续出现大部分队列上无数据的情况,使消费者负载趋于均衡。

 
作者丨梁勇
来源丨瓜农老梁(ID:gh_01130ae30a83)
dbaplus社群欢迎广大技术人员投稿,投稿邮箱:editor@dbaplus.cn
 

 

难道救火注定是运维绕不开的宿命吗?突破运维转型困局,9月11日在北京,让Gdevops全球敏捷运维峰会给你新思路:

 

  • 《浙江移动AIOps实践》浙江移动云计算中心NOC及AIOps负责人 潘宇虹

  • 《数据智能时代:构建能力开放的运营商大数据DataOps体系》中国联通大数据基础平台负责人/资深架构师 尹正军

  • 《银行日志监控系统优化手记》中国银行DevOps负责人 付大亮 & 中国银行高级软件工程师 李晓宁

  • 《民生银行智能运维平台实践之路》民生银行智能运维平台负责人/应用运维专家 张舒伟

  • 《建设敏捷型消费金融中台及云原生下的DevOps实践》中邮消费金融总经理助理 李远鑫

 

 

 

活动预告