RocketMQ 升級到主從切換(DLedger、多副本)實戰

本文主要介紹如何將 RocketMQ 集羣從原先的主從同步升級到主從切換。服務器

首先先介紹與 DLedger 多副本即 RocketMQ 主從切換相關的核心配置屬性,而後嘗試搭建一個主從同步集羣,再從原先的 RocketMQ 集羣平滑升級到 DLedger 集羣的示例,並簡單測試一下主從切換功能。架構

@(本節目錄)併發

一、RocketMQ DLedger 多副本即主從切換核心配置參數詳解

其主要的配置參數以下所示:app

  • enableDLegerCommitLog
    是否啓用 DLedger,便是否啓用 RocketMQ 主從切換,默認值爲 false。若是須要開啓主從切換,則該值須要設置爲 true 。
  • dLegerGroup
    節點所屬的 raft 組,建議與 brokerName 保持一致,例如 broker-a。
  • dLegerPeers
    集羣節點信息,示例配置以下:n0-127.0.0.1:40911;n1-127.0.0.1:40912;n2-127.0.0.1:40913,多個節點用英文冒號隔開,單個條目遵循 legerSlefId-ip:端口,這裏的端口用做 dledger 內部通訊。
  • dLegerSelfId
    當前節點id。取自 legerPeers 中條目的開頭,即上述示例中的 n0,而且特別須要強調,只能第一個字符爲英文,其餘字符須要配置成數字。
  • storePathRootDir
    DLedger 日誌文件的存儲根目錄,爲了可以支持平滑升級,該值與 storePathCommitLog 設置爲不一樣的目錄。

二、搭建主從同步環境

首先先搭建一個傳統意義上的主從同步架構,往集羣中灌必定量的數據,而後升級到 DLedger 集羣。分佈式

在 Linux 服務器上搭建一個 rocketmq 主從同步集羣我想不是一件很難的事情,故本文就不會詳細介紹按照過程,只貼出相關配置。高併發

實驗環境的部署結構採起 一主一次,其部署圖以下:
在這裏插入圖片描述
下面我就重點貼一下 broker 的配置文件。
220 上的 broker 配置文件以下:源碼分析

brokerClusterName = DefaultCluster
brokerName = broker-a
brokerId = 0
deleteWhen = 04
fileReservedTime = 48
brokerRole = ASYNC_MASTER
flushDiskType = ASYNC_FLUSH
brokerIP1=192.168.0.220
brokerIP2=192.168.0.220
namesrvAddr=192.168.0.221:9876;192.168.0.220:9876
storePathRootDir=/opt/application/rocketmq-all-4.5.2-bin-release/store
storePathCommitLog=/opt/application/rocketmq-all-4.5.2-bin-release/store/commitlog
autoCreateTopicEnable=false
autoCreateSubscriptionGroup=false

221 上 broker 的配置文件以下:測試

brokerClusterName = DefaultCluster
brokerName = broker-a
brokerId = 1
deleteWhen = 04
fileReservedTime = 48
brokerRole = SLAVE
flushDiskType = ASYNC_FLUSH
brokerIP1=192.168.0.221
brokerIP2=192.168.0.221
namesrvAddr=192.168.0.221:9876;192.168.0.220:9876
storePathRootDir=/opt/application/rocketmq-all-4.5.2-bin-release/store
storePathCommitLog=/opt/application/rocketmq-all-4.5.2-bin-release/store/commitlog
autoCreateTopicEnable=false
autoCreateSubscriptionGroup=false

相關的啓動命令以下:.net

nohup bin/mqnamesrv  /dev/null  2>&1 &
nohup bin/mqbroker -c conf/broker.conf  /dev/null  2>&1 &

安裝後的集羣信息如圖所示:
在這裏插入圖片描述

三、主從同步集羣升級到DLedger

3.1 部署架構

DLedger 集羣至少須要3臺機器,故搭建 DLedger 還須要再引入一臺機器,其部署結構圖以下:
在這裏插入圖片描述
從主從同步集羣升級到 DLedger 集羣,用戶最關心的仍是升級後的集羣是否可以兼容原先的數據,即原先存儲在消息可否能被消息消費者消費端,甚至於可否查詢到。
爲了方便後續驗證,首先我使用下述程序向 mq 集羣中添加了一篇方便查詢的消息(設置消息的key)。

public class Producer {
    public static void main(String[] args) throws MQClientException, InterruptedException {
        DefaultMQProducer producer = new DefaultMQProducer("producer_dw_test");
        producer.setNamesrvAddr("192.168.0.220:9876;192.168.0.221:9876");
        producer.start();
        for(int i =600000; i < 600100; i ++) {
            try {
                Message msg = new Message("topic_dw_test_by_order_01",null , "m" + i,("Hello RocketMQ" + i ).getBytes(RemotingHelper.DEFAULT_CHARSET));
                SendResult sendResult = producer.send(msg);
               //System.out.printf("%s%n", sendResult);
            } catch (Exception e) {
                e.printStackTrace();
                Thread.sleep(1000);
            }
        }
        producer.shutdown();
        System.out.println("end");
    }
}

消息的查詢結果示例以下:
在這裏插入圖片描述

3.2 升級步驟

Step1:將 192.168.0.220 的 rocketmq 拷貝到 192.168.0.222,可使用以下命令進行操做。在 192.168.0.220 上敲以下命令:

scp -r rocketmq-all-4.5.2-bin-release/ root@192.168.0.222:/opt/application/rocketmq-all-4.5.2-bin-release

舒適提示:示例中因爲版本是同樣,實際過程當中,版本須要升級,故需先下載最新的版本,而後將老集羣中的 store 目錄完整的拷貝到新集羣的 store 目錄。

Step2:依次在三臺服務器的 broker.conf 配置文件中添加與 dledger 相關的配置屬性。

192.168.0.220 broker配置文件以下:

brokerClusterName = DefaultCluster
brokerId = 0
deleteWhen = 04
fileReservedTime = 48
brokerRole = ASYNC_MASTER
flushDiskType = ASYNC_FLUSH
brokerIP1=192.168.0.220
brokerIP2=192.168.0.220
namesrvAddr=192.168.0.221:9876;192.168.0.220:9876
storePathRootDir=/opt/application/rocketmq-all-4.5.2-bin-release/store
storePathCommitLog=/opt/application/rocketmq-all-4.5.2-bin-release/store/commitlog
autoCreateTopicEnable=false
autoCreateSubscriptionGroup=false
# 與 dledger 相關的屬性
enableDLegerCommitLog=true
storePathRootDir=/opt/application/rocketmq-all-4.5.2-bin-release/store/dledger_store
dLegerGroup=broker-a
dLegerPeers=n0-192.168.0.220:40911;n1-192.168.0.221:40911;n2-192.168.0.222:40911
dLegerSelfId=n0

192.168.0.221 broker配置文件以下:

brokerClusterName = DefaultCluster
brokerName = broker-a
brokerId = 1
deleteWhen = 04
fileReservedTime = 48
brokerRole = SLAVE
flushDiskType = ASYNC_FLUSH
brokerIP1=192.168.0.221
brokerIP2=192.168.0.221
namesrvAddr=192.168.0.221:9876;192.168.0.220:9876
storePathRootDir=/opt/application/rocketmq-all-4.5.2-bin-release/store
storePathCommitLog=/opt/application/rocketmq-all-4.5.2-bin-release/store/commitlog
autoCreateTopicEnable=false
autoCreateSubscriptionGroup=false
# 與dledger 相關的配置屬性
enableDLegerCommitLog=true
storePathRootDir=/opt/application/rocketmq-all-4.5.2-bin-release/store/dledger_store
dLegerGroup=broker-a
dLegerPeers=n0-192.168.0.220:40911;n1-192.168.0.221:40911;n2-192.168.0.222:40911
dLegerSelfId=n1

192.168.0.222 broker配置文件以下:

brokerClusterName = DefaultCluster
brokerName = broker-a
brokerId = 0
deleteWhen = 04
fileReservedTime = 48
brokerRole = ASYNC_MASTER
flushDiskType = ASYNC_FLUSH
brokerIP1=192.168.0.222
brokerIP2=192.168.0.222
namesrvAddr=192.168.0.221:9876;192.168.0.220:9876
storePathRootDir=/opt/application/rocketmq-all-4.5.2-bin-release/store
storePathCommitLog=/opt/application/rocketmq-all-4.5.2-bin-release/store/commitlog
autoCreateTopicEnable=false
autoCreateSubscriptionGroup=false
# 與 dledger 相關的配置
enableDLegerCommitLog=true
storePathRootDir=/opt/application/rocketmq-all-4.5.2-bin-release/store/dledger_store
dLegerGroup=broker-a
dLegerPeers=n0-192.168.0.220:40911;n1-192.168.0.221:40911;n2-192.168.0.222:40911
dLegerSelfId=n2

舒適提示:legerSelfId 分別爲 n0、n一、n2。在真實的生產環境中,broker配置文件中的 storePathRootDir、storePathCommitLog 儘可能使用單獨的根目錄,這樣判斷其磁盤使用率時纔不會相互影響。

Step3:將 store/config 下的 全部文件拷貝到 dledger store 的 congfig 目錄下。

cd /opt/application/rocketmq-all-4.5.2-bin-release/store/
cp config/* dledger_store/config/

舒適提示:該步驟按照各自按照時配置的目錄進行復制便可。

Step4:依次啓動三臺 broker。

nohup bin/mqbroker -c conf/broker.conf  /dev/null  2>&1 &

若是啓動成功,則在 rocketmq-console 中看到的集羣信息以下:
在這裏插入圖片描述

3.3 驗證消息發送與消息查找

首先咱們先驗證升級以前的消息是否能查詢到,那咱們仍是查找key 爲 m600000 的消息,查找結果如圖所示:
在這裏插入圖片描述

而後咱們來測試一下消息發送。測試代碼以下:

public class Producer {
    public static void main(String[] args) throws MQClientException, InterruptedException {
        DefaultMQProducer producer = new DefaultMQProducer("producer_dw_test");
        producer.setNamesrvAddr("192.168.0.220:9876;192.168.0.221:9876");
        producer.start();
        for(int i =600200; i < 600300; i ++) {
            try {
                Message msg = new Message("topic_dw_test_by_order_01",null , "m" + i,("Hello RocketMQ" + i ).getBytes(RemotingHelper.DEFAULT_CHARSET));
                SendResult sendResult = producer.send(msg);
                System.out.printf("%s%n", sendResult);
            } catch (Exception e) {
                e.printStackTrace();
                Thread.sleep(1000);
            }
        }
        producer.shutdown();
        System.out.println("end");
    }
}

執行結果以下:
在這裏插入圖片描述
再去控制檯查詢一下消息,其結果也代表新的消息也能查詢到。
在這裏插入圖片描述
最後咱們再來驗證一下主節點宕機,消息發送是否會受影響。

在消息發送的過程當中,去關閉主節點,其截圖以下:
在這裏插入圖片描述在這裏插入圖片描述在這裏插入圖片描述再來看一下集羣的狀態:
在這裏插入圖片描述

等待該複製組從新完成主服務器選舉後,便可繼續處理消息發送。

舒適提示:因爲本示例是一主一從,故在選舉期間,消息不可用,但在真實的生產環境上,其部署架構是多主主從,即一個複製組在 leader 選舉期間,其餘複製組能夠接替該複製組完成消息的發送,實現消息服務的高可用。

與 DLedger 相關的日誌,默認存儲在 broker_default.log 文件中。

本文就介紹到這裏了,若是以爲文章對您有幫助的話,還但願幫忙點個贊,謝謝。


推薦閱讀:源碼分析 RocketMQ DLedger 多副本即主從切換系列文章:
一、RocketMQ 多副本前置篇:初探raft協議
二、源碼分析 RocketMQ DLedger 多副本之 Leader 選主
三、源碼分析 RocketMQ DLedger 多副本存儲實現
四、源碼分析 RocketMQ DLedger(多副本) 之日誌追加流程
五、源碼分析 RocketMQ DLedger(多副本) 之日誌複製(傳播)
六、基於 raft 協議的 RocketMQ DLedger 多副本日誌複製設計原理
七、RocketMQ 整合 DLedger(多副本)即主從切換實現平滑升級的設計技巧
八、源碼分析 RocketMQ DLedger 多副本即主從切換實現原理


做者介紹:丁威,《RocketMQ技術內幕》做者,RocketMQ 社區佈道師,公衆號:中間件興趣圈 維護者,目前已陸續發表源碼分析Java集合、Java 併發包(JUC)、Netty、Mycat、Dubbo、RocketMQ、Mybatis等源碼專欄。能夠點擊連接加入中間件知識星球 ,一塊兒探討高併發、分佈式服務架構,交流源碼。

在這裏插入圖片描述

相關文章
相關標籤/搜索