线上环境大规模RocketMQ集群不停机优雅升级实践(架构方案)
接安全部门的行政要求,生产环境上百台RocketMQ机器必须在半个月内升级,必须支持ACL,规避安全风险。
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写权限,让应用将流量平滑迁移到其他节点,这样可以有效避免在对该机器进行重启时对业务造成的影响。
sh ./mqadmin updateBrokerConfig -b 192.168.x.x:10911 -n 192.168.xx.xx:9876 -k brokerPermission -v 4
2、带Broker写入、消费tps接近0时,关闭broker
ps -ef | grep java kill pid
3、使用新版本启动Broker
注意,此过程使用的配置文件为老版本的配置,故此时并没有开启写权限,启动并不会对客户端消息写入造成影响。
4、开启写权限
待新版本启动成功后,既可以开启写权限
sh ./mqadmin updateBrokerConfig -b 192.168.xx.xx:10911 -n 192.168.xx.xx:9876 -k brokerPermission -v 6
观察流量。
重复上述步骤即可完成Broker的升级。
关于Nameserver的升级就更加容易了,采用滚动升级,kill掉老版本的nameserver,在原机器上启动新版本的nameserver即可。
3、花絮
最后和大家再分享一个小小的插曲。尽管上面的方案非常详细,并且经过反复的测试,但MQ在我们公司的重要性实在太重要,运维小伙伴在操作时不敢下手,在操作时他要我在身边看着,这个时候,作为架构师的我们要敢于承担责任,明确告知,只要你操作正确,出力故障由我来承担,这也是我个人觉得作为架构师一个非常重要的软技能:对你负责的技术具有掌控力,并且敢于担当。
好了,本文就介绍到这里了,您的一键三连是对我最大的鼓励,当然可以加笔者微信:dingwpmz,备注CSDN,共同交流探讨。
最后分享笔者一个硬核的RocketMQ电子书,您将获得千亿级消息流转的运维经验。 获取方式:微信搜索【中间件兴趣圈】,回复RMQPDF即可获取。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Microsoft 宣布将停止支持多个 .NET Framework 版本
Microsoft 宣布,使用传统的、不安全的安全哈希算法1(SHA-1)签名的多个 .NET 框架版本将在明年停止支持。 据 .NET 首席工程经理 Jamshed Damkewala 表示,.NET 框架 4.5.2、4.6 和 4.6.1 将在 2022 年 4 月 26 日后停止支持,届时不再为这些版本提供包括安全修复或技术支持在内的更新。唯一的例外是 Windows 10 Enterprise LTSC 2015 内置的 .NET Framework 4.6 版本,它的支持将延长到 2025 年 10 月,即该操作系统达到其终点时。 此外,文中还建议 .NET 开发人员在 2022 年 4 月 26 日之前将其应用程序至少迁移到 .NET 框架 4.6.2 或更高版本,以继续接受安全更新和技术支持。4.6.2 和 4.8 都是稳定的版本,并具有良好的兼容性,如果应用程序是使用 .NET 框架 4-4.6.1 构建的,在大多数情况下,它都可以继续在 4.6.2 及之后的版本上运行,而不需要重新编译或重新定位。 此举的原因是这些版本都是用使用传统的 SHA-1 加密散列算法的证书...
- 下一篇
回溯问题中组合、子集和排列问题的去重
回溯法,⼀般可以解决如下⼏种问题: 组合问题:N个数⾥⾯按⼀定规则找出k个数的集合 切割问题:⼀个字符串按⼀定规则有⼏种切割⽅式 ⼦集问题:⼀个N个数的集合⾥有多少符合条件的⼦集 排列问题:N个数按⼀定规则全排列,有⼏种排列⽅式 棋盘问题:N皇后,解数独等等 本文主要讲解这几种问题在去重问题上的不同做法,其实就一个核心点,<font color=red>对有序数组进行去重,去重方式包括传递used引用去重和每层定义set去重</font>。 需知:组合问题、切割问题和子集问题无序,排列问题有序 对于组合问题,因为组合无序,所以需要排序+used/set去重,组合问题其实是子集问题的一种; 对于切割问题,本质就是组合问题,使用startIdx当作切割下标即可; 对于子集问题,包括两种题型: 子集II:和组合问题去重一样,排序+used/set去重 递增子序列:等价于从有序数组中选取所有子集,相当于有序数组的前提已经实现,所以需要使用set进行去重,不能使用used是因为不能进行candidates[i] == candidates[i-1] && ...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS7,CentOS8安装Elasticsearch6.8.6
- Red5直播服务器,属于Java语言的直播服务器
- CentOS关闭SELinux安全模块
- SpringBoot2更换Tomcat为Jetty,小型站点的福音
- CentOS7安装Docker,走上虚拟化容器引擎之路
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- CentOS8编译安装MySQL8.0.19