一張圖進階 RocketMQ - NameServer

三此君發表於2022-06-17
MQServer

前言

「三此君看了好幾本書，看了很多遍原始碼整理的 一張圖進階 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.

轉載請註明出處

相關文章