一張圖進階 RocketMQ – NameServer

前言

「三此君看了好幾本書，看了很多遍源碼整理的 一張圖進階 RocketMQ 圖片鏈接，關於 RocketMQ 你只需要記住這張圖！覺得不錯的話，記得點贊關注哦。」

一張圖進階 RocketMQ 圖片鏈接一張圖進階 RocketMQ 圖片鏈接

【重要】影片在 B 站同步更新，歡迎圍觀，輕輕鬆鬆漲姿勢。一張圖進階 RocketMQ-NameServer（影片版）

本文是《一張圖進階 RocketMQ》系列的第 2 篇，今天主要聊一聊 RocketMQ 集群元數據管理。因為 Producer、Consumer 和 Broker 都需要和 NameServer 交互，負責的三此君不得不先和大家嘮一嘮 NameServer 是何方神聖。

《RocketMQ 整體架構》中有說道 NameServer 是集群的元數據管理中心，那它到底管理了哪些元數據？我們來看看 NameServer 裡面都穿了什麼，看完了記得關注、轉發、點贊、收藏哦。

imgimg

集群元數據

簡單來說，NameServer 負責集群元數據的增刪改查。先不管這個增刪改查是怎麼實現的，我們甚至可以理解就是資料庫的增刪改查，但是我們一定要知道這些元數據都長什麼樣子。才能知道 Producer、Consumer 及 Broker 是如何根據這些數據進行消息收發的。

集群元數據集群元數據

如圖所示，二主二從的 Broker 集群相關的元數據資訊，包括 topicQueueTable、BrokerAddrTable、ClusterAddrTable、brokerLiveInfo、FilterServer (暫時不用關注，圖中未畫出)。

  • HashMap<String topic, List<QueueData>> topicQueueTable：Key 是 Topic 的名稱，它存儲了所有 Topic 的屬性資訊。Value 是個 QueueData 列表，長度等於這個 Topic 數據存儲的 Master Broker 的個數，QueueData 里存儲著 Broker 的名稱、讀寫 queue 的數量、同步標識等。
  • HashMap<String BrokerName, BrokerData> brokerAddrTable：這個結構存儲著一個 BrokerName 對應的屬性資訊，包括所屬的 Cluster 名稱，一個 Master Broker 和多個 Slave Broker 的地址資訊
  • HashMap<String ClusterName, Set<String BrokerName>> clusterAddrTable：存儲的是集群中 Cluster 的資訊，就是一個 Cluster 名稱對應一個由 BrokerName 組成的集合。
  • HashMap<String BrokerAddr, BrokerLiveInfo> brokerLiveTable：Key 是 BrokerAddr 對應著一台機器，BrokerLiveTable 存儲的內容是這台 Broker 機器的實時狀態，包括上次更新狀態的時間戳，NameServer 會定期檢查這個時間戳，超時沒有更新就認為這個 Broker 無效了，將其從 Broker 列表裡清除。
  • HashMap<String BrokerAddr, List<String> FilterServer> filterServerTable：Key 是 Broker 的地址，Value 是和這個 Broker 關聯的多個 FilterServer 的地址。Filter Server 是過濾伺服器，是 RocketMQ 的一種服務端過濾方式，一個 Broker 可以有一個或多個 Filter Server。

工作流程

然後我們來看一下 NameServer 簡單的工作流程，其他角色會主動向 NameServer 上報狀態，根據上報消息里的請求碼做相應的處理，更新存儲的對應資訊。

image-20220612152922567image-20220612152922567

  • Broker 接到創建 Topic 的請求後向 NameServer 發送註冊資訊，NameServer 收到註冊資訊後首先更新 Broker 資訊，然後對每個 Master 角色的 Broker，創建一個 QueueData 對象。如果是新建 Topic，就是添加 QueueData 對象；如果是修改 Topic，就是把舊的 QueueData 刪除，加入新的 QueueData。
  • Broker 向 NameServer 發送的心跳會更新時間戳，NameServer 每 10 秒檢查一次檢查時間戳，檢查到時間戳超過 2 分鐘則認為 Broker 已失效，便會觸發清理邏輯。
  • 連接斷開的事件也會觸髮狀態更新，當 NameServer 和 Broker 的長連接斷掉以後，onChannelDestroy 函數會被調用，把這個 Broker 的資訊清理出去。
  • Producer/Consumer 啟動之後會和 NameServer 建立長連接，定時從 NameServer 獲取路由資訊保存到本地。消息的發送與拉取都會用到上面的數據。

為了讓大家感受更真切，別以為都是三此君胡說八道，我們簡簡單單來看看源碼：

總結

以上就是本文的全部內容，那麼多數據，相信大家看的有點暈，三此君簡單總結下：NameServer 通過 brokerLiveInfo 來維護存活的 Broker。Producer 會獲取上面的路由資訊，發送消息的時候指定發送到哪個 Topic，根據 Topic 可以從 topicQueueTable 選擇一個 Broker，根據 BrokerName 可以從 BrokerAddrTable 獲取到Broker IP 地址。有了 IP 地址 Producer 就可以和 Broker 建立連接將消息通過網路傳遞給 Broker。

最後，看懂的點贊，沒看懂的收藏。來都來了，交個朋友，有任何問題，可以評論區留言或者私信。關注微信公眾號：三此君。回復 mq，可以領取 RocketMQ 相關的所有資料。感謝觀看，我們下期再見。

bannerbanner

參考文獻

  • RocketMQ 官方文檔

  • RocketMQ 源碼

  • 丁威, 周繼鋒. RocketMQ技術內幕：RocketMQ架構設計與實現原理. 機械工業出版社, 2019-01.

  • 李偉. RocketMQ分散式消息中間件：核心原理與最佳實踐. 電子工業出版社, 2020-08.

  • 楊開元. RocketMQ實戰與原理解析. 機械工業出版社, 2018-06.

轉載請註明出處

Tags:

VirMach 便宜 VPS

QNews

QNews