百萬級消息的RocketMQ 如何線上平滑擴容升級？

1、背景

一、各業務系統持續迭代過程當中，JDK、SpringBoot、RocketMQ Client 等框架也進行了升級，高版本的 RocketMQ Client 發送的消息到低版本中，在控制檯中午沒法查看消息明細，導致業務平常排查問題等至關困難。

二、原業務端發送消息與本地事務很難作到一致性，要保障不丟失數據和數據不一致開發成本很是高，RocketMQ V4.4 版本增長了事務消息，引入事務消息後可大大下降實現這一特性的難度。

三、咱們對 MQ 的依賴愈來愈強，MQ 的重要性和穩定性都已經能夠和 DB 至關了，而 V4.x 版本增長了更多的新特性和監控手段，可使咱們更好的監控 MQ 的使用狀況。

四、V4.x 版本由 Alibaba 維護移交到了 Apache 社區並有他進行維護，促使使用範圍更廣，也有更多的參與者參與進來，可靠性和及時響應性有了更高的保障。

五、新版本在吞吐率和對新的技術有了更好的支持，基於上述這些因素，咱們考慮將 MQ 進行版本升級與改造。

六、升級版本 V3_2_6 -＞ V4.6.0

2、流程

因業務特性需求，對當前RocketMQ 集羣進行不停機版本迭代升級，步驟以下。

請升級的架構師詳細查看文檔，進行查漏補缺以避免形成不可挽回的事故

下面是這次升級使用的基礎資料：

官方文檔

https://rocketmq.apache.org/d...

https://rocketmq.apache.org/d...

Dledger 快速搭建指南：

https://github.com/apache/roc...

Apache RocketMQ 開發者指南：

https://github.com/apache/roc...

升級前必定要熟讀的兩個架構圖：

一、消息存儲

二、消息刷盤

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/re...

4.0.0 (INCUBATING) 變爲Apache

4.4.0 支持消息軌跡 、支持ACL

4.5.0 引入Dledger 的多副本技術

六、新集羣4.6.0 集羣模型選擇

1. 單Master模式

   這種方式風險較大，一旦Broker重啓或者宕機時，會致使整個服務不可用。不建議線上環境使用,能夠用於本地測試。

2. 多Master模式

   一個集羣無Slave，全是Master，例如2個Master或者3個Master，這種模式的優缺點以下：

   優勢：配置簡單，單個Master宕機或重啓維護對應用無影響，在磁盤配置爲RAID10時，即便機器宕機不可恢復狀況下，因爲RAID10磁盤很是可靠，消息也不會丟（異步刷盤丟失少許消息，同步刷盤一條不丟），性能最高；

   缺點：單臺機器宕機期間，這臺機器上未被消費的消息在機器恢復以前不可訂閱，消息實時性會受到影響。

1. 多Master多Slave模式-異步複製

   每一個Master配置一個Slave，有多對Master-Slave，HA採用異步複製方式，主備有短暫消息延遲（毫秒級），這種模式的優缺點以下：

   優勢：即便磁盤損壞，消息丟失的很是少，且消息實時性不會受影響，同時Master宕機後，消費者仍然能夠從Slave消費，並且此過程對應用透明，不須要人工干預，性能同多Master模式幾乎同樣；

   缺點：Master宕機，磁盤損壞狀況下會丟失少許消息。

1. 多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模式-同步雙寫

流程概述：

1. 修改2m-2s-sync 、runbroker、runserver 配置參數
2. 停掉3.2.6 nameserver 原IP PORT 啓動4.6.0 nameserver，逐級替換完畢
3. 停掉3.2.6 broker 啓動4.6.0 broker（查看是否有單機topic問題），逐級替換完畢
4. 測試集羣穩定性，爲新集羣增長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

恭喜你到此你的集羣就升級完畢了！！！

---

專一於分享技術乾貨文章的地方，可關注我獲取更多神祕資料、視頻資料，wx搜索:架構技術專欄