1、背景
一、各業務系統持續迭代過程當中，JDK、SpringBoot、RocketMQ Client 等框架也進行了升級，高版本的 RocketMQ Client 發送的消息到低版本中，在控制檯中午沒法查看消息明細，導致業務平常排查問題等至關困難。java
二、原業務端發送消息與本地事務很難作到一致性，要保障不丟失數據和數據不一致開發成本很是高，RocketMQ V4.4 版本增長了事務消息，引入事務消息後可大大下降實現這一特性的難度。git
三、咱們對 MQ 的依賴愈來愈強，MQ 的重要性和穩定性都已經能夠和 DB 至關了，而 V4.x 版本增長了更多的新特性和監控手段，可使咱們更好的監控 MQ 的使用狀況。github
四、V4.x 版本由 Alibaba 維護移交到了 Apache 社區並有他進行維護，促使使用範圍更廣，也有更多的參與者參與進來，可靠性和及時響應性有了更高的保障。shell
五、新版本在吞吐率和對新的技術有了更好的支持，基於上述這些因素，咱們考慮將 MQ 進行版本升級與改造。apache
六、升級版本 V3_2_6 -＞ V4.6.0tomcat
2、流程
因業務特性需求，對當前RocketMQ 集羣進行不停機版本迭代升級，步驟以下。架構
請升級的架構師詳細查看文檔，進行查漏補缺以避免形成不可挽回的事故併發
下面是這次升級使用的基礎資料：框架
官方文檔異步
https://rocketmq.apache.org/docs/quick-start/
https://rocketmq.apache.org/dowloading/releases/
Dledger 快速搭建指南：
https://github.com/apache/rocketmq/blob/master/docs/cn/dledger/quick_start.md
Apache RocketMQ 開發者指南：
https://github.com/apache/rocketmq/tree/master/docs/cn
升級前必定要熟讀的兩個架構圖：
一、消息存儲
二、消息刷盤
3、前期準備
一、當前環境版本狀態
DEV: http://10.0.254.191:7080/ V3_5_8 2m
TEST: http://10.185.240.76:8081/ V3_5_8 2m
PRO：http://rocketmq.pro.siku.cn/ admin/secoo V3_2_6 2m
二、每一個版本組件支持的jre環境
| Version | Client | Broker | NameServer |
|---|---|---|---|
| 4.0.0-incubating | >=1.7 | >=1.8 | >=1.8 |
| 4.1.0-incubating >=1.6 >=1.8 >=1.8 | |||
| 4.2.0 | >=1.6 | >=1.8 | >=1.8 |
| 4.3.x | >=1.6 | >=1.8 | >=1.8 |
| 4.4.x | >=1.6 | >=1.8 | >=1.8 |
| 4.5.x | >=1.6 | >=1.8 | >=1.8 |
| 4.6.x | >=1.6 | >=1.8 | >=1.8 |
四、升級時使用到的命令集合
啓動 nohup sh bin/mqnamesrv & nohup sh bin/mqbroker -c conf/2m-noslave/broker-b.properties & broker的寫權限關閉 bin/mqadmin updateBrokerConfig -b 192.168.x.x:10911 -n 192.168.x.x:9876 -k brokerPermission -v 4 恢復該節點的寫權限 bin/mqadmin updateBrokerConfig -b 192.168.x.x:10911 -n 192.168.x.x:9876 -k brokerPermission -v 6 中止 bin/mqshutdown broker bin/mqshutdown namesrv 查看集羣信息，集羣、BrokerName、BrokerId、TPS等信息 ./bin/mqadmin clusterList -n localhost:9876 獲取所有topic ./bin/mqadmin topicList -n localhost:9876 -c DevCluster > topiclist 獲取topic 路由信息 ./bin/mqadmin topicRoute -t demo-cluster -n localhost:9876 獲取topic offset ./bin/mqadmin topicStatus -t demo-cluster -n localhost:9876 打印Topic訂閱關係、TPS、積累量、24h讀寫總量等信息 ./bin/mqadmin statsAll -n localhost:9876 修改broker 參數 ./bin/mqadmin updateBrokerConfig -n localhost:9876 -b 10.0.xxx.2:10911 -k waitTimeMillsInSendQueue -v 500 -c TestCluster 發送消息 ./bin/mqadmin sendMessage -n localhost:9876 -t lqtest -p "this is test" 消費 ./bin/mqadmin consumeMessage -n localhost:9876 -t lqtest
五、官方版本特性收集
這裏只標註了下重要的特性，有興趣的能夠查看 http://rocketmq.apache.org/release_notes/
4.0.0 (INCUBATING) 變爲Apache
4.4.0 支持消息軌跡 、支持ACL
4.5.0 引入Dledger 的多副本技術
六、新集羣4.6.0 集羣模型選擇
-
單Master模式
這種方式風險較大，一旦Broker重啓或者宕機時，會致使整個服務不可用。不建議線上環境使用,能夠用於本地測試。
-
多Master模式
一個集羣無Slave，全是Master，例如2個Master或者3個Master，這種模式的優缺點以下：
優勢：配置簡單，單個Master宕機或重啓維護對應用無影響，在磁盤配置爲RAID10時，即便機器宕機不可恢復狀況下，因爲RAID10磁盤很是可靠，消息也不會丟（異步刷盤丟失少許消息，同步刷盤一條不丟），性能最高；
缺點：單臺機器宕機期間，這臺機器上未被消費的消息在機器恢復以前不可訂閱，消息實時性會受到影響。
-
多Master多Slave模式-異步複製
每一個Master配置一個Slave，有多對Master-Slave，HA採用異步複製方式，主備有短暫消息延遲（毫秒級），這種模式的優缺點以下：
優勢：即便磁盤損壞，消息丟失的很是少，且消息實時性不會受影響，同時Master宕機後，消費者仍然能夠從Slave消費，並且此過程對應用透明，不須要人工干預，性能同多Master模式幾乎同樣；
缺點：Master宕機，磁盤損壞狀況下會丟失少許消息。
-
多Master多Slave模式-同步雙寫（參考當前業務與併發度，選擇此集羣模式）
每一個Master配置一個Slave，有多對Master-Slave，HA採用同步雙寫方式，即只有主備都寫成功，才嚮應用返回成功，這種模式的優缺點以下：
優勢：數據與服務都無單點故障，Master宕機狀況下，消息無延遲，服務可用性與數據可用性都很是高；
缺點：性能比異步複製模式略低（大約低10%左右），發送單個消息的RT會略高，且目前版本在主節點宕機後，備機不能自動切換爲主機
請結合本身的集羣特色和穩定性進行選擇升級，不必定最新的集羣模式就是最適合大家得。必定要把平滑升級放在首位。
七、TOPIC 整理
能夠寫個腳本整理現有topic 目錄，在升級完成後對topic 列表和分區進行整理校對。
由於topic在rocketmq的設計思想裏，是做爲同一個業務邏輯消息的組織形式，它僅僅是一個邏輯上的概念，而在一個topic下又包含若干個邏輯隊列，即消息隊列，消息內容實際是存放在隊列中，而隊列又存儲在broker中
必定要進行特殊業務場景梳理 1）順序消費 2）topic單broker配置
以避免出現一個Topic只有一個queue的狀況出現，致使消息丟失。隨便找了個圖，你們能夠看下
八、新集羣配置
brokerClusterName=MQCluster brokerName=broker-ali-76 brokerId=0 deleteWhen=04 fileReservedTime=360 brokerRole=ASYNC_MASTER flushDiskType=ASYNC_FLUSH storePathCommitLog=/data/rocketmq/store/commitlog storePathConsumerQueue=/data/rocketmq/store/consumequeue storePathRootDir=/data/rocketmq/store autoCreateSubscriptionGroup=true ## if msg tracing is open,the flag will be true traceTopicEnable=true listenPort=10911 namesrvAddr=10.48.xx.76:9876;10.48.xx.77:9876
4、升級步驟
當攻略作完之後，咱們就能夠開始搞起了。我選擇的最終架構模式：多Master多Slave模式-同步雙寫
流程概述：
-
修改2m-2s-sync 、runbroker、runserver 配置參數
-
停掉3.2.6 nameserver 原IP PORT 啓動4.6.0 nameserver，逐級替換完畢
-
停掉3.2.6 broker 啓動4.6.0 broker（查看是否有單機topic問題），逐級替換完畢
-
測試集羣穩定性，爲新集羣增長slave,升級完成
詳細步驟：
準備操做
一、下載最新4.6.0版本部署包
cd /data/xxx_tomcat wget http://mirrors.tuna.tsinghua.edu.cn/apache/rocketmq/4.6.0/rocketmq-all-4.6.0-bin-release.zip unzip rocketmq-all-4.6.0-bin-release
二、修改配置
cd /data/xxx_tomcat/rocketmq-4.6.0/conf/2m-2s-sync 修改5一、50 機器broker配置 修改配置 2m-2s-sync 修改 runbroker JVM配置，以避免使用了默認配置致使內存不夠
三、兩臺M配置以下：
兩臺差異只在brokerName brokerClusterName=MQCluster brokerName=broker-60-50 brokerId=0 deleteWhen=04 fileReservedTime=48 brokerRole=ASYNC_MASTER flushDiskType=ASYNC_FLUSH storePathCommitLog=/data/alibaba-rocketmq/store/commitlog storePathConsumerQueue=/data/rocketmq/store/consumequeue storePathRootDir=/data/alibaba-rocketmq/store autoCreateSubscriptionGroup=true ## if msg tracing is open,the flag will be true traceTopicEnable=true listenPort=10911 namesrvAddr=192.168.xxx.50:9876;192.168.xxx.51:9876
四、替換nameserver
jps -l sh bin/mqshutdown namesrv cd /data/xxx_tomcat/rocketmq-4.6.0 nohup sh bin/mqnamesrv & ./bin/mqadmin clusterList -n localhost:9876
五、替換broker
jps -l sh bin/mqshutdown broker cd /data/xxx_tomcat/rocketmq-4.6.0 ps -ef|grep mq //檢查使用的配置文件 nohup sh bin/mqbroker -c conf/2m-2s-sync/broker-b.properties & ./bin/mqadmin clusterList -n localhost:9876
最後咱們來發個消息測試下
./bin/mqadmin sendMessage -n localhost:9876 -t lqtest -p "this is test" ./bin/mqadmin consumeMessage -n localhost:9876 -t lqtest
恭喜你到此你的集羣就升級完畢了！！！
關注公衆號獲取更多視頻資料：
專一於分享技術乾貨文章的地方，內容涵蓋java基礎、中間件、分佈式、apm監控方案、異常問題定位等技術棧。多年基礎架構經驗，擅長基礎組件研發，分佈式監控系統，熱愛技術，熱愛分享