背景 　　我们在很早之前大约在2015年8月份左右我们开始使用Rocketmq作为公司消息中间件，那个时候RocketMQ还没有捐赠给Acaphe。 　　RocketMQ版本还是3.2.6，中间升级了一次版本，目前版本是3.5.8。 　　但是随着RocketMQ版本不断更新并且功能与稳定性也不断提高，所以打算升级为4.3.X版本 　　上一次升级停机了10分钟不到还是很快的，这次的目标是不停机升级版本。（题外话，上次因为升级还燃起了一波“干架”） 架构深入了解 　　先简单附上一张RocketMQ的整体架构图，通过架构图我们可以从中分析出几种不停机版本升级方案 　　 　　简单解释一下这个方案就是2主2从 多个nameserver，本公司架构一样，只是节点多了点而已，3主3从 2个nameserver 　　通过这个架构图我们设想了几个错略方案 新加两台（一主一从）服务器Broker节点升级4.3.2，然后注册到Name Server（如果目前服务器可以承受压力可以不用新加），然后逐台切换最后在切换NameServer节点。 先替换一台NameServer节点，然后倒入相关topic等信息，然后切换Broker节点。 如果方案1 2 都不能实现不停机，那就只能申请同样资源服务器再架设一套，最后切换IP或host（RocketMQ可以依赖hostname或IP地址所以比较麻烦，同时之前数据不好做同步）。 最后的防线停机维护了，违背了不停机维护的初衷。 方案实践测试 　　从方案1开始进行测试， 　　我们将4.3.2版本的broker注册到NameServer3.5.8的版本上出现了如下错误： 　 　　然后去看了源码 　　 　　报错了很明显这是两个版本不兼容有意为之，所以方案1被否定 　　 　　接下来我们尝试方案2 　　让Broker3.5.8版本的节点注册到NameServer4.3.2版本的节点，我们开始 　　现根据官方文档启动NameServer（v4.3.2）服务 　　sh bin/mqnamesrv 　　 　　NameServer成功启动 　　接下来我们启动broker（v3.5.8）服务 　　sh bin/mqbroker -n IP:9876 -c conf/2m-2s-async/broker-a.properties 　　 　　启动成功，查看日志是否有异常 　　 　　没有抛出异常，注册成功，同时使用程序进行测试发送消息成功，这里程序代码就不贴上来了。 　　控制台也显示正常 　　 　　从上面测简单测试来看方案2是基本可行的，接下来切换broker节点为4.3.2，看看是否文件兼容 　　 　　主从版本复制没有问题，同步OK，看看消息如何，如下图消息解析也没有问题 　　 　　接下来我们测试方案2的业务连续性 　　通过上面的简单测试发现方案2可行 方案二如下 　　 　　接下来开始方案二的具体实施RocketMQ各节点平滑过渡切换步骤 　　1、首先备份各种配置文件以防出现问题不能回滚，其中主要备份的有rocketmq程序包，store文件夹中的除commitlog文件夹外的文件（commitlog文件夹内容太多备份困难，并且从节点也有相同的一份，就没有备份） 　　 　　2、修改相关配置文件，主要针对4.3.2版本进行修改（有些不一定要改根据实际机器环境如jdk） 　　　　　包括如下runserver.sh runbroker.sh 修改堆栈内存大小适应宿主机，还有相应的jdk环境，如果没有设置JAVA_HOME的话 　　　　　设置相关文件的可执行权限一般有 os.sh runbroker.sh runserver.sh 　　　　　　命令 chmod u+x os.sh runbroker.sh runserver.sh 　　　　　　设置各个节点配置文件，2m-2s-async文件夹下的配置保持与上一个版本保持一致（尤其是存储路径store） 　　　　 　　3、开始切换namesrv节点 　　　　首先打开namesrv节点宿主机（老版本正在运行的）执行如下命令停止namesrv 　　　　sh mqshutdown namesrv 　　　　 　　　　停止成功 　　　　启动4.3.2版本namesrv命令如下 　　　　nohup sh bin/mqnamesrv & 　　　　依次启动多个namesrv节点，并查看日志注意是否有异常 　　4、开始切换broker节点 　　　　步骤与切换namesrv类似不过broker节点有主从的概念 　　　　首先找到集群中的一台master几点进行切换，执行如下命令关停主节点 　　　　sh mqshutdown broker 　　　　 　　　　启动4.3.2版本broker命令如下 　　　　nohup sh bin/mqbroker -c conf/2m-2s-async/broker-b.properties & 　　　　启动之后日志如下 　　　　 　　　　 　　　　接下来进行从节点启动切换 　　　　步骤与主节点相同 　　　　其他节点进行依次重启切换 　　　　最后贴一张全部切换完成的图 　　　　 总结 　　通过上面的步骤已经接近完美的进行版本平滑升级，生产和消费几乎感觉不到，其实在过程当中是有卡顿现象出现的 　　其中尤其要注意的是备份和新版本的各个配置文件要做好，否则会很恼火 　　同时要留意主从之间数据差距不要太大 　　还好我们生产环境只有6台服务器（3m-3s）加入有十几二十节点我手动改就要疯了，所以使用docker部署未尝不是一件可选方案 　　在这里记录希望对大家有参考意义https://www.cnblogs.com/zhyg/p/10132598.html