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 升级思路

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