前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >RocketMQ集群平滑扩缩容【实战笔记】

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

作者头像
丁威
发布2020-05-08 14:43:37
2.1K0
发布2020-05-08 14:43:37
举报
文章被收录于专栏:中间件兴趣圈中间件兴趣圈
一、运维需求

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

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

代码语言:javascript
复制
集群信息: 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%时使用。

代码语言:javascript
复制
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表示读写权限。

代码语言:javascript
复制
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流量情况

代码语言:javascript
复制
bin/mqadmin clusterList -n x.x.x.x:9876

等待broker出入流量均归零

3.验证broker积压情况

代码语言:javascript
复制
bin/mqadmin brokerConsumeStats -b x.x.x.x:10911 -n x.x.x.x:9876

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

4.节点下线

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

代码语言:javascript
复制
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这种命名方式,就能平衡其流量,不至于连续出现大部分队列上无数据的情况,使消费者负载趋于均衡。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2020-05-04,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 中间件兴趣圈 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 一、运维需求
  • 二、平滑扩容
  • 四、问题答疑
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档