线上环境大规模RocketMQ集群不停机优雅升级实践

开发 架构
RocketMQ集群的升级方案、落地实施就自然而然的落到了我的头上,本文不仅要介绍一下笔者是如何升级的,更想展示作为一名架构师,处理这些问题的方法论,展示大厂架构师的工作日常。

[[393955]]

本文转载自微信公众号「 中间件兴趣圈」,作者丁威 。转载本文请联系 中间件兴趣圈公众号。

RocketMQ集群的升级方案、落地实施就自然而然的落到了我的头上,本文不仅要介绍一下笔者是如何升级的,更想展示作为一名架构师,处理这些问题的方法论,展示大厂架构师的工作日常。

温馨提示:关于ACL相关的内容,后续文章会单独分享从4.1.0版本升级到4.8并开启ACL的曲折经历。

1、版本升级的迫切性

说来惭愧,作为RocketMQ社区优秀布道师,笔者所在公司的RocketMQ服务端版本竟然还是4.1.0,RocketMQ在4.4.0版本之前是不支持ACL(访问控制),对应生产环境中任意一台机器都可以订阅任意topic,在任意一台生产应用服务器都可以安装一个rocketmq-console,从而控制整个集群,拥有删除主题、删除消费组的权限,想想是不是后背发凉.

2、升级方案

2.1 确定升级到的版本

翻开RocketMQ升级日志,RocketMQ在4.4.0版本正式引入了ACL机制,故版本至少要升级到4.4.0,在业界使用开源版本有一个不成文的规则:通常不要使用最新的版本,不要充当小白鼠。

但RocketMQ可以算是一个特殊。

通过仔细浏览RocketMQ的版本变更记录,我们不难发现RocketMQ Client 相关的变更非常少,即与用户关系紧密的消息发送、消息消费这块的代码非常的稳定,理论上基本不存在兼容性问题。并且每一个版本都修复了一些重大的BUG,性能提升也比较明显,故笔者这次决定“冒天下之大不韪”,决定将帮升级到最新版本4.8.0。

在这里在啰嗦一些,简单介绍一下RocketMQ几个具有里程杯意义的版本。

  • RocketMQ4.3.0正式引入了事务消息,如果大家希望使用事务消息,其版本最低建议为 4.6.1。
  • RocketMQ4.4.0引入了ACL、消息轨迹,如果需要使用这些功能,其版本最低建议为 4.7.0。
  • RocketMQ4.5.0引入了多副本(主从切换),其版本建议使用4.7.0。
  • RocketMQ4.6.0引入了请求-响应模型。

2.2 升级思路

版本升级的基本要求:业务不能停机,即要做到对业务无感知的升级。

如果机器足够的备用机器,最佳的版本迁移方案应该是先扩容再缩容,其示例图如下:

其主要的思路是先对Broker进行扩容,加入两台高版本的Broker服务器,加入到集群中,然后关闭低版本Broker的写权限,待消息过期后,将低版本移除,最后升级NameServer,完成不停机的在线迁移。

由于此次升级需要在半个月左右的时间内将RocketMQ集群所有的节点全部升级,无法提供这么多冷备节点,故先扩容、再缩容无法满足本次需求,本次只能基于已有的机器进行升级。

能否直接升级Broker端代码,但高版本的Broker直接使用低版本的Broker存储目录,即直接升级软件,其示例图如下:

核心思想是先停止老版本的Broker,然后使用新版本启动Broker,但使用旧的配置文件。

有了思路,接下来就是要验证方案的可行性。

2.3 方案验证

理论归理论,在生产环境做任何变更之前,必须有充分的测试验证,版本升级重点需要验证兼容性问题。

2.2.1 服务端版本兼容性验证

搭建一个上述MQ集群,其核心要点:

  • 高版本的Broker是否能向低版本的NameServer注册路由
  • 低版本的Broker是否能向高版本的NameServer注册路由

通过rocketmq-console,去创建多个个topic,看看其路由信息是否正确,经验证,符合预期。

2.2.2 客户端与服务端兼容性验证

RocketMQ的客户端API其实比较单一,无非就是消息发送、批量发送,消息消费,由于4.1版本不支持事务消息,这次升级甚至都无需验证事务消息,验证的要点:

  • 低版本的客户端是否能正常向高版本Broker发送消息,消费消息
  • 高版本的客户端是否能向低版本的Broker发送消息,消费消息

测试案例来自哪,其实都不需要我们自己写,直接用官方的Demo即可,其代码截图如下:

客户端验证在真正实施过程中,其实比服务端之间的验证要复杂的多,由于各个项目组使用的客户端版本不一,甚至有些项目组会使用c++、Python等其他非Java客户端,如何精确找到该集群中所有客户端的连接信息(客户端版本、语言类型)至关重要。

官方提供的版本,对消费组的连接信息还是支持的比较友好,我们可以通过写脚本,先查询系统中所有的消费组,然后遍历每一个消费组,可以查询这些消费组的IP地址、客户端版本、使用的语言等信息,但开源版本对生产者支持的不友好,没有一个可获取所有发送者相关的接口。

获取消费组消费端的连接方式如下图所示:

故我们采取的方式,主要是基于消费组失败客户端类型,本次升级过程中,我也对RocketMQ做了一些定制化开发,可方便获取所有发送方的链接信息,后续会已提交PR的方式贡献给官方。

2.2.3 Broker端存储格式验证

由于没有空闲资源,本次要使用的升级方式是直接升级软件,但新老版本共用存储目录,基于RocketMQ的消息存储协议,从4.0.0版本之后就一直没有变化,其验证的关键点如下:

  • 4.8.0版本是否可以直接使用4.1.0生成的存储文件(commitlog等文件)
  • 4.1.0版本是否可以直接使用4.8.0生成的存储文件

为什么需要验证4.1.0版本能兼容4.8.0呢?因为如果升级失败,需要回滚,如果4.1.0版本不能兼容4.8.0的话,会让你没有退路,这在架构设计中是绝对不允许的。

经过验证发现,存储文件是相互兼容的。

2.2.4 测试环境验证

经过上面三步的验证,已经可以进行升级了,但升级之前,还要在测试环境稳定运行一天,可以将测试环境升级成如下架构:

即不同版本的混搭模式,接受测试环境所有应用服务器的验证,如果测试环境运行没有问题,即可在生产环境进行升级。

2.4 实施方案

有了上面升级方案,并且已经做了充分的验证,是可以在生产环境执行了,在执行之前,需要对理论设计输出可执行可落地的实施方案,实施方案必须要包括回滚操作,并且这个回滚操作一定要比较容易执行,否则你的方案一定是不那么可靠的。

接下来重点阐述一下实施过程中一些关键步骤,整个升级步骤才有滚动升级,即逐台升级。

1、关闭一个Broker的写权限

关闭Broker写权限,让应用将流量平滑迁移到其他节点,这样可以有效避免在对该机器进行重启时对业务造成的影响。

  1. sh ./mqadmin updateBrokerConfig -b 192.168.x.x:10911 -n 192.168.xx.xx:9876 -k brokerPermission -v 4 

2、带Broker写入、消费tps接近0时,关闭broker

  1. ps -ef | grep java 
  2. kill pid 

3、使用新版本启动Broker

注意,此过程使用的配置文件为老版本的配置,故此时并没有开启写权限,启动并不会对客户端消息写入造成影响。

4、开启写权限

待新版本启动成功后,既可以开启写权限

  1. sh ./mqadmin updateBrokerConfig -b 192.168.xx.xx:10911 -n 192.168.xx.xx:9876 -k brokerPermission -v 6 

观察流量。

重复上述步骤即可完成Broker的升级。

关于Nameserver的升级就更加容易了,采用滚动升级,kill掉老版本的nameserver,在原机器上启动新版本的nameserver即可。

 

责任编辑:武晓燕 来源: 中间件兴趣圈
相关推荐

2021-05-08 08:33:00

Rocketmq日志数据源

2020-08-25 10:34:22

微服务微服务架构生产环境

2022-06-08 08:06:05

LinuxJVM内存

2021-05-12 09:15:48

Facebook 开发技术

2022-07-24 09:46:48

优雅停机代码

2022-06-09 13:45:18

vivoK8S集群Kubernetes

2020-04-09 11:56:10

Elasticsear集群硬件

2021-04-22 13:38:21

前端开发技术

2022-10-08 09:33:00

平台中间件

2020-08-06 14:36:24

Elasticsear集群运维

2016-11-01 13:06:58

大数据数据中心

2013-03-14 10:19:51

数据中心升级停机数据中心

2019-05-17 17:17:37

大数据实践指南

2009-09-04 03:43:03

IBMsystemdirector

2023-03-06 08:41:32

CPU使用率排查

2019-04-18 11:37:49

NameNodeHDFS架构

2022-05-12 09:39:01

HDFSvivo集群

2023-06-28 08:23:41

搜索语义模型

2022-07-07 11:00:09

美团模型实践
点赞
收藏

51CTO技术栈公众号