背景
我們在很早之前大約在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部署未嘗不是一件可選方案
在這里記錄希望對大家有參考意義
