[[410693]]

本文轉(zhuǎn)載自微信公眾號「SH的全棧筆記」，作者SH的全棧筆記。轉(zhuǎn)載本文請聯(lián)系SH的全棧筆記公眾號。

在之前的文章中，已經(jīng)把 Broker、Producer 和 Conusmer 的部分源碼和核心的機制介紹的差不多了，但是其實 RocketMQ 中還有一個比較關(guān)鍵但是我們平時很容易忽略的組件——NameServer。

在日常的使用中，我們接觸的最多的還是 Producer 和 Consumer，而 NameServer 沒有直接跟我們有交互。就像 Kafka 集群背后用于其集群元數(shù)據(jù)管理的 Zookeeper 集群一樣，NameServer 也在背后支撐著 RocketMQ 正常工作。

你給翻譯翻譯，什么叫 NameServer

NameServer 你可以簡單的把它理解成注冊中心。

Broker 啟動的時候會將自己注冊到 NameServer 中，注冊的同時還會將 Broker 的 IP 地址、端口相關(guān)的數(shù)據(jù)，以及保存在 Broker 中的 RocketMQ 集群路由的數(shù)據(jù)一并跟隨心跳發(fā)送到 NameServer。這里的路由信息是指 Topic 下的 MessageQueue 分別都在哪臺 Broker 上。

而 Producer 則會從 NameServer 中獲取元數(shù)據(jù)，從而將 Message 發(fā)到對應(yīng)的 Broker 中去。

相應(yīng)的，Consumer 也需要從 NameServer 中獲取數(shù)據(jù)。平常我們配置消費者，里面重要的信息主要就兩個，分別是你要消費的 Topic 和當(dāng)前的 Consumer Group。根據(jù)配置，Consumer 會去 NameServer 獲取對應(yīng)的 Topic 都有哪些 Broker，其真實的 IP 地址和端口是多少，拿到了這個之后就可以開始進行消息消費了。

注冊 Broker 都做了什么

這里我們先通過注冊 Broker 的源碼來預(yù)熱一下，為后面閱讀整個部分的源碼做準(zhǔn)備，直接上代碼。

首先這里做了一個對 Broker 版本的區(qū)分，不同的版本采用不同的處理方式，鑒于官網(wǎng)現(xiàn)在最新的版本都已經(jīng)到了 4.9.0 了，就暫時先不考慮低版本的情況了，后面有時間再討論。

只有向上面那種幾行的代碼會給大家貼出來，其余的代碼我會盡量用流程圖代替

校驗 Body 的完整性

首先是校驗 Broker 傳過來的數(shù)據(jù)的完整性。很簡單的一個判斷，將 Broker 傳過來的 Body 用 CRC32算法 加密之后，和請求中 Header 中所帶的由 Broker 加密的值進行對比，不同的話就說明數(shù)據(jù)的完整性出了問題，接下來需要中斷注冊流程。

解析Body

這里分成兩種情況：

• Body為空
• Body不為空

如果 Body 為空，則會將當(dāng)前要注冊的 Broker 的 DataVersion 給重置;

而 **Body 不為空 **則會進行對 Body 進行解析，主要是從中解析出 DataVersion ，代表 Broker 中的數(shù)據(jù)版本。其次解析出這個 Broker 中存儲的所有 Topic 及其相關(guān)的配置。

執(zhí)行注冊邏輯

這里就是注冊的核心邏輯了，這里為了更加容易理解，我們來分情況討論，就不把兩種情況揉在一起了。

• 首次注冊
• 非首次注冊

維護集群中 Broker 的 Name

在整個操作開始之前，會先給 RouteInfoManager 加一把鎖，這個 RouteInfoManager 里面就是 NameServer 存儲數(shù)據(jù)的地方。這個鎖是個讀寫鎖，使用的是 Java 中的 ReentrantReadWriteLock。

這里的 BrokerName 是在 RocketMQ 配置文件中配置的變量。就是用于標(biāo)識一個 Broker 的名字，但我們知道 Broker 是有主從架構(gòu)的，并且 RocketMQ 4.5 之后推出的 Dleger 可以實現(xiàn)一主多從，換句話說，一個 Broker Name 可能會對應(yīng)多個 Broker 實例。

在 MQ 看來，Broker 是多實例部署的;而在 Producer 或者 Consumer 來看，Broker就只有一個。所以，這個步驟內(nèi)所維護的就是在當(dāng)前集群中，有多少個這樣的 Broker Name。

維護 Broker 的數(shù)據(jù)

然后，RocketMQ 會在 brokerAddrTable 中維護每個 Broker 的核心數(shù)據(jù)，包含：

Broker 所處的集群

Broker 的名字(上面剛剛討論過)

所有 Broker 的 BrokerID 和 Address 的對應(yīng)關(guān)系，是個 Map，Address 為 IP+端口

同一個 Broker Name 下，為什么會有多個地址信息已經(jīng)在上個步驟解答過，不在此贅述。

Broker 的數(shù)據(jù)維護主要有兩個方面：

• 該 Broker 數(shù)據(jù)在 brokerAddrTable 中是否存在
• brokerAddrTable 中維護的數(shù)據(jù)不能有重復(fù)的地址信息

第一個過于基礎(chǔ)簡單，就不再贅述。我們重點看第二個點，我們知道會有多個 Broker 地址，存在一個 Map 中，因為 Broker 是基于主從架構(gòu)。那不知道你有沒有想過，NameServer 如何區(qū)分 主 和 從 的呢?

答案是通過 Map 的 Key，如果是 0 則代表是 Master 節(jié)點，1 則代表 Slave 節(jié)點，因為 RocketMQ 自己實現(xiàn)的 Broker 主從架構(gòu)是一主一從，而一主多從則是由 RocketMQ 4.5 之后加入的 Dleger 實現(xiàn)的，暫時先不討論。區(qū)分的邏輯如下圖：

那什么時候會出現(xiàn)重復(fù)呢?

答案是主從切換

舉個例子，假設(shè)某個 Slave Broker 的 Address 為 192.168.1.101:8081 ，且已經(jīng)注冊。此時brokerAddrs 中已經(jīng)有一個key: 1 value: 192.168.1.101:8081 記錄了。

當(dāng)集群中的 Master 宕機之后，會進行故障恢復(fù)，假設(shè)選中了上面這個 Broker 為新的 Master，在進行注冊的時候會發(fā)現(xiàn)，brokerAddrs 中已經(jīng)有一個同樣的 Address 了，只是 Key 不同。但是由于它們從本質(zhì)上來說就是同一臺機器，如果不將 key 為1，也就是角色為 Slave 的記錄去掉，就會造成數(shù)據(jù)一致性的問題。

簡單總結(jié)一下來說，同一個 Adreess，在 brokerAddrs 中只能存在一個。感興趣的可以看一下源碼，其實跟上面文字描述的邏輯是一樣的。

去除了重復(fù)的 Address 數(shù)據(jù)之后，就會將本次注冊的 Broker 的數(shù)據(jù)注冊進 brokerAddrs 中。

維護 MessageQueue 的數(shù)據(jù)

這里主要是根據(jù) Broker 的數(shù)據(jù)更新其 MessageQueue 相關(guān)的數(shù)據(jù)。接下來，我們詳細解析一下 Message Queue 的維護流程，同樣會給出源碼和流程圖，兩部分等價，可選擇性觀看。

當(dāng) Master 節(jié)點來注冊時，如果是首次注冊或者數(shù)據(jù)有更新，便會調(diào)用一個方法createAndUpdateQueueData去維護 MessageQueue 相關(guān)的數(shù)據(jù)。這里對數(shù)據(jù)是否更新的判斷，是基于 DataVersion 的，代表 Broker 數(shù)據(jù)的版本。

此后通過 Topic 的 Name 拿到對應(yīng)的 MessageQueue 的列表，這里可能會有點疑問，一個 Topic 難道不應(yīng)該只有一個對 MessageQueue 相關(guān)的配置嗎，為什么這里拿到的是個列表?

小了，格局小了

Topic 是個邏輯上的概念，一個 Topic 的 MessageQueue 會分布在不同的 Broker 上，所有這里是個列表。

更新的流程如上圖，拿到了 MessageQueue 的列表之后，會和本次注冊的 Broker 中的 MessageQueue 數(shù)據(jù)做一個對比，如果發(fā)現(xiàn)不同就進行全量的替換，沒什么其他的復(fù)雜對比邏輯。源碼等同上圖，感興趣的可以自行查看。

維護 Broker 的存活信息

到這里，MessageQueue 相關(guān)的邏輯就處理完了，接下來 NameServer 會再去更新 brokerLiveTable 中的數(shù)據(jù)，這里存放了當(dāng)前正在活躍的所有 Broker。這塊的作用后續(xù)會講。

NameServer 啟動流程

上面通過了解注冊 Broker的整個流程，對整個 NameServer 的架構(gòu)有了個大概的了解，接下來再從整體視角來看一下 NameServer。

NameServer的主要流程

整體的流程上面這張圖已經(jīng)給出來了，就不放源碼了，意義不大。

這里說一下掃描不再活躍的Broker，這個后臺線程會每 10秒 鐘執(zhí)行一次，這里會對上文提到的 brokerLiveTable 進行遍歷處理，因為這里面維護了所有的正在活躍的 Broker。

如果某個 Broker 超過了 120秒 沒有發(fā)送心跳給 NameServer，就會將其從 brokerLiveTable 中移除。

NameServer 可處理的操作