[[386520]]

本文轉(zhuǎn)載自微信公眾號(hào)「大魚仙人」，作者大魚。轉(zhuǎn)載本文請(qǐng)聯(lián)系大魚仙人公眾號(hào)。

消息隊(duì)列RocketMQ版是阿里云基于Apache RocketMQ構(gòu)建的低延遲、高并發(fā)、高可用、高可靠的分布式消息中間件。

我們知道RocketMQ是個(gè)消息隊(duì)列，這個(gè)消息隊(duì)列是分為多個(gè)組件的，其中包括broker、producer、consumer等，那么這些個(gè)組件之間如何交互呢?或者說(shuō)它們?nèi)绾潍@得對(duì)方的狀態(tài)呢

大魚相信聰明的你應(yīng)該已經(jīng)猜到了，就是通過(guò)一個(gè)注冊(cè)中心來(lái)控制，其實(shí)大魚本人我在寫這篇文章之前一直在糾結(jié)到底如何稱呼NameServer在RocketMQ中的地位呢?

說(shuō)是大腦吧，但是它又不完全算是指揮中心，也沒有存儲(chǔ)消息(消息存儲(chǔ)在broker中)，大腦中應(yīng)該是存儲(chǔ)這這些才有資格叫做大腦吧;要說(shuō)不是大腦吧，它又存在一部分的指揮作用，producer發(fā)送消息，需要先通過(guò)NameServer獲取到broker和Topic的對(duì)應(yīng)關(guān)系，獲取到broker的地址信息，再去長(zhǎng)連接broker來(lái)發(fā)送消息，而且還和broker之間有著心跳機(jī)制來(lái)維持broker的存活狀態(tài)，維持整個(gè)集群的穩(wěn)定性和可用性

所以，大魚我給NameServer起名叫做 偽大腦 ;

啥玩意?偽大腦，那是不是還有真大腦呢?真大腦是什么?

我真是太喜歡好奇的你了，一猜你就是風(fēng)華正茂，愛好學(xué)習(xí)的中華好兒女，沒錯(cuò)，我賣關(guān)子其實(shí)就是下一篇咱們要一起學(xué)習(xí)的broker，這是RocketMQ中最核心的了，因?yàn)楹芏噙壿嬁刂贫际窃谶@里邊完成(定時(shí)延時(shí)、半消息)，還有存儲(chǔ)消息的文件、存儲(chǔ)消費(fèi)offset的文件等等

NameServer

NameServer是什么

知其然，再知其所以然，那到底NameServer是個(gè)什么東西呢?

NameServer是一個(gè)非常簡(jiǎn)單的Topic路由注冊(cè)中心，其角色類似Dubbo中的zookeeper，支持Broker的動(dòng)態(tài)注冊(cè)與發(fā)現(xiàn)。NameServer是一個(gè)幾乎無(wú)狀態(tài)節(jié)點(diǎn)，可集群部署，節(jié)點(diǎn)之間無(wú)任何信息同步。

NameServer存儲(chǔ)Topic和Broker的信息，Broker啟動(dòng)的時(shí)候會(huì)向所有的NameServer注冊(cè)。Producer在發(fā)送消息之前會(huì)先從NameServer獲取Broker地址列表，按照負(fù)載均衡算法從列表中選擇一臺(tái)Broker服務(wù)器發(fā)送消息

NameServer和Broker保持長(zhǎng)連接，每隔30s檢測(cè)Broker是否存活，如果Broker宕機(jī)，從路由注冊(cè)表中刪除。路由變化不會(huì)馬上通知Producer，這樣實(shí)現(xiàn)降低了NameServer實(shí)現(xiàn)復(fù)雜度，Producer會(huì)通過(guò)容錯(cuò)機(jī)制來(lái)保證消息發(fā)送高可用。

Producer與Name Server集群中的其中一個(gè)節(jié)點(diǎn)(隨機(jī)選擇)建立長(zhǎng)連接，定期從Name Server取Topic路由信息，并向提供Topic服務(wù)的Master建立長(zhǎng)連接，且定時(shí)向Master發(fā)送心跳。Producer完全無(wú)狀態(tài)，可集群部署。

Consumer與Name Server集群中的其中一個(gè)節(jié)點(diǎn)(隨機(jī)選擇)建立長(zhǎng)連接，定期從Name Server取Topic路由信息，并向提供Topic服務(wù)的Master、Slave建立長(zhǎng)連接，且定時(shí)向Master、Slave發(fā)送心跳。Consumer既可以從Master訂閱消息，也可以從Slave訂閱消息，訂閱規(guī)則由Broker配置決定。

NameServer集群

RocketMQ集群，應(yīng)該是線上采用的相當(dāng)多的一種架構(gòu)了，分為四個(gè)主要組成部分：生產(chǎn)者集群、消費(fèi)者集群、NameServer集群和Broker集群，其中的NameServer集群是什么樣子的呢?這個(gè)還挺有意思的，和別的集群不太一樣，一起來(lái)看看為啥

我們了解的集群，一般都是互幫互助，起到一個(gè)高可用的作用;絕大多數(shù)集群應(yīng)該都是這個(gè)樣子的，而NameServer集群卻不是這個(gè)樣子的，NameServer集群說(shuō)白了其實(shí)屬于一個(gè)偽集群，為什么這么說(shuō)呢?

因?yàn)镹ameServer集群中的多個(gè)節(jié)點(diǎn)是互不交互的，就是等同于多個(gè)獨(dú)立的NameServer機(jī)器部署在NameServer集群中，每個(gè)機(jī)器都可以單獨(dú)支持這個(gè)集群的運(yùn)轉(zhuǎn)，多個(gè)機(jī)器的作用其實(shí)就是備份的作用

NameServer集群如何部署

NameServer 是整個(gè)集群的路由中心，如果沒有了它，生產(chǎn)者往哪個(gè) Broker 投遞消息都不知道，沒有了它，會(huì)很麻煩!

為了保證高可用性，NameServer 必然是需要支持多臺(tái)部署的。如果 NameServer 就部署一臺(tái)機(jī)器的話，一旦它宕機(jī)了會(huì)導(dǎo)致 RocketMQ 集體出現(xiàn)故障。

所以多機(jī)器部署保證了任何一臺(tái) NameServer 宕機(jī)，其他機(jī)器上的 NameServer 可以繼續(xù)對(duì)外提供服務(wù)。

如果NameServer集群中的一個(gè)機(jī)器掛掉了怎么辦，對(duì)集群有什么影響

對(duì)于整個(gè)RocketMQ集群來(lái)說(shuō)問題不大，因?yàn)樵O(shè)計(jì)優(yōu)秀的RocketMQ集群不會(huì)因?yàn)橐慌_(tái)NameServer機(jī)器掛掉而導(dǎo)致整個(gè)集群受影響甚至不可用。一般我們會(huì)有報(bào)警系統(tǒng)來(lái)報(bào)警關(guān)于NameServer機(jī)器掛掉的信息，有相應(yīng)的運(yùn)維人員再去處理

NameServer作用

NameServer是一個(gè)非常簡(jiǎn)單的Topic路由注冊(cè)中心，其角色類似Dubbo中的zookeeper，支持Broker的動(dòng)態(tài)注冊(cè)與發(fā)現(xiàn)。NameServer是一個(gè)幾乎無(wú)狀態(tài)節(jié)點(diǎn)，可集群部署，節(jié)點(diǎn)之間無(wú)任何信息同步。

NameServer在RocketMQ集群中起到了類似于注冊(cè)中心的作用，我們先來(lái)看下NameServer的源碼架構(gòu)

其實(shí)結(jié)構(gòu)也很簡(jiǎn)單，不算復(fù)雜，大家如果有興趣研究，可以花點(diǎn)時(shí)間去研究，源碼地址：

https://github.com/rocketmq

NameServer在RocketMQ中的作用大概大魚同學(xué)給分了三類，叫做路由管理、路由發(fā)現(xiàn)和路由刪除，也很好理解，來(lái)，我給大家簡(jiǎn)單解釋下

• 路由管理就是保存著broker的活躍列表和Topic對(duì)應(yīng)的關(guān)系
• 路由注冊(cè)和發(fā)現(xiàn)就是Topic對(duì)應(yīng)的broker信息發(fā)生變化時(shí)的更新(非實(shí)時(shí)性)
• 路由刪除就是對(duì)于broker機(jī)器宕機(jī)或者關(guān)閉時(shí)自動(dòng)刪除相應(yīng)路由

我們知道broker和NameServer的關(guān)系是很緊密的，單個(gè)broker會(huì)和所有的NameServer保持長(zhǎng)連接，broker啟動(dòng)時(shí)會(huì)輪詢所有的NameServer并進(jìn)行注冊(cè)

broker每隔30秒(此時(shí)間沒有辦法更改的哦，切記哦)會(huì)向所以的NameServer發(fā)送心跳，心跳包含了所有的Topic信息

由此可以看出：如果broker中包含太多Topic，心跳信息過(guò)大的話可能會(huì)造成網(wǎng)絡(luò)傳輸較慢

NameServer每隔10秒也會(huì)掃描所有存活著的broker的，這個(gè)時(shí)間也是無(wú)法更改的，若某個(gè)連接2分鐘內(nèi)(當(dāng)前時(shí)間與最后更新時(shí)間差值超過(guò)2分鐘，此時(shí)間無(wú)法更改)沒有發(fā)送心跳數(shù)據(jù)，則斷開連接，一旦連接斷開，nameserver會(huì)感知，感知會(huì)有稍稍的延遲，為啥延遲我應(yīng)該不用說(shuō)了吧?

接著就是更新topc與隊(duì)列的對(duì)應(yīng)關(guān)系，但不會(huì)通知生產(chǎn)者和消費(fèi)者

路由管理：保存著broker的活躍列表和Topic對(duì)應(yīng)的隊(duì)列列表

NameServer保存著活躍的broker列表，包括master和slave;NameServer用來(lái)保存所有的Topic和Topic對(duì)應(yīng)的所有隊(duì)列的列表;NameServer用來(lái)保存所有的broker的filter列表

這些在RouteInfoManager這個(gè)類中都有

每個(gè)屬性通過(guò)名字就能清楚的知道是什么意思，之所以能用非線程安全的HashMap，是因?yàn)橛凶x寫鎖lock來(lái)對(duì)HashMap的修改做保護(hù)。

我們注意到保存broker的Map有兩個(gè)，即brokerAddrTable用來(lái)保存所有的broker列表和brokerLiveTable用來(lái)保存當(dāng)前活躍的broker列表，而BrokerData用來(lái)保存broker的主要新增，而BrokerLiveInfo只用來(lái)保存上次更新(心跳)時(shí)間

你幾乎可以在NameServer這里知道topic相關(guān)的所有信息，包括topic有哪些隊(duì)列，這些隊(duì)列在那些broker上等。

DefaultRequestProcessor是NameServer的默認(rèn)請(qǐng)求處理器，他處理了定義在rocketmq-common模塊中RequestCode定義的部分請(qǐng)求，比如注冊(cè)broker、注銷broker、獲取topic路由、刪除topic、獲取broker的topic權(quán)限、獲取NameServer的所有topic等

路由注冊(cè)和發(fā)現(xiàn)：Broker的啟動(dòng)注冊(cè)和Topic的關(guān)系變動(dòng)

Broker在啟動(dòng)時(shí)向所有的NameServer心跳語(yǔ)句，每隔30S向所有NameServer發(fā)起心跳包。NameServer收到心跳包后更新緩存。NameServer每隔10S掃描brokerLiveTable，如果連續(xù)120S沒有收到心跳包，則NameServer移除Broker的路由信息同時(shí)關(guān)閉Socket連接。

路由注冊(cè)在broker啟動(dòng)時(shí)觸發(fā)，broker啟動(dòng)時(shí)會(huì)和所有NameServer創(chuàng)建心跳連接，向NameServer發(fā)送Broker的相關(guān)信息。NameServer在RouteInfoManager類中維護(hù)了Broker相關(guān)信息的緩存，進(jìn)行更新動(dòng)作。更新時(shí)用了讀寫鎖，既保證了極高并發(fā)場(chǎng)景下的讀效率，又避免了并發(fā)修改緩存。

路由發(fā)現(xiàn)：RocketMQ的路由發(fā)現(xiàn)是非實(shí)時(shí)的。當(dāng)topic對(duì)應(yīng)的路由信息發(fā)生變化，NameServer并不會(huì)通知給客戶端。而是由客戶端定時(shí)拉取Topic對(duì)應(yīng)的最新路由。不實(shí)時(shí)的路由發(fā)現(xiàn)引起的問題由客戶端進(jìn)行解決，保證了NameServer邏輯的簡(jiǎn)潔?？蛻舳硕〞r(shí)向NameServer發(fā)起請(qǐng)求GET_ROUTEINFO_BY_TOPIC，獲取對(duì)應(yīng)的信息

路由刪除：對(duì)于宕機(jī)或者關(guān)閉的broker，自動(dòng)刪除相應(yīng)的路由信息

路由刪除的觸發(fā)點(diǎn)有兩個(gè)：

• NameServer啟動(dòng)時(shí)開啟的定時(shí)任務(wù)，每隔10s掃描一次brokerLiveTable，檢測(cè)上次心跳包與當(dāng)前系統(tǒng)時(shí)間差，如果時(shí)間差大于120s，則移除Broker的相關(guān)信息。
• Broker正常關(guān)閉，會(huì)向NameServer發(fā)送UNREGISTER_BROKER消息。

其實(shí)初期RocketMQ采用的是zookeeper作為注冊(cè)中心的，后來(lái)為什么改成自研的NameServer了?

這個(gè)問題其實(shí)我也不想太多的多說(shuō)，這個(gè)可能需要了解zookeeper，如果不了解這個(gè)東西的話，其實(shí)我說(shuō)了也是沒啥大用的

首先，zookeeper中最主要的功能就是master的選舉，但是呢?對(duì)于RocketMQ不太合適，你想啊，RocketMQ中的master并不會(huì)存在全部的Topic信息，所以選擇master沒什么意義

其次，對(duì)于RocketMQ來(lái)說(shuō)，這個(gè)注冊(cè)中心的作用不僅要保存相關(guān)的信息(broker活躍列表、Topic對(duì)應(yīng)信息等)，還有就是需要一些邏輯來(lái)處理相應(yīng)的數(shù)據(jù)，比如每隔10秒檢測(cè)一次活躍的broker來(lái)更新列表，這些邏輯如果換做是zookeeper的客戶端來(lái)處理的話，算是比較麻煩的

因此，既然zookeeper對(duì)于RocketMQ來(lái)說(shuō)是屬于一個(gè)重量級(jí)的注冊(cè)中心，所以不如自己寫一個(gè)簡(jiǎn)易的注冊(cè)中心來(lái)實(shí)現(xiàn)，像上面說(shuō)的集群，NameServer集群是屬于偽集群，節(jié)點(diǎn)之間不存在相應(yīng)的交互，只是起到一個(gè)備份的作用，這樣使得RocketMQ集群變得更加靈活