[[386520]]

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

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

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

 

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

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

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

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

我真是太喜歡好奇的你了，一猜你就是風華正茂，愛好學習的中華好兒女，沒錯，我賣關(guān)子其實就是下一篇咱們要一起學習的broker，這是RocketMQ中最核心的了，因為很多邏輯控制都是在這里邊完成(定時延時、半消息)，還有存儲消息的文件、存儲消費offset的文件等等

 

NameServer

NameServer是什么

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

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

NameServer存儲Topic和Broker的信息，Broker啟動的時候會向所有的NameServer注冊。Producer在發(fā)送消息之前會先從NameServer獲取Broker地址列表，按照負載均衡算法從列表中選擇一臺Broker服務器發(fā)送消息

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

 

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

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

NameServer集群

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

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

因為NameServer集群中的多個節(jié)點是互不交互的，就是等同于多個獨立的NameServer機器部署在NameServer集群中，每個機器都可以單獨支持這個集群的運轉(zhuǎn)，多個機器的作用其實就是備份的作用

 

NameServer集群如何部署

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

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

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

如果NameServer集群中的一個機器掛掉了怎么辦，對集群有什么影響

對于整個RocketMQ集群來說問題不大，因為設計優(yōu)秀的RocketMQ集群不會因為一臺NameServer機器掛掉而導致整個集群受影響甚至不可用。一般我們會有報警系統(tǒng)來報警關(guān)于NameServer機器掛掉的信息，有相應的運維人員再去處理

 

NameServer作用

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

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

 

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

https://github.com/rocketmq

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

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

我們知道broker和NameServer的關(guān)系是很緊密的，單個broker會和所有的NameServer保持長連接，broker啟動時會輪詢所有的NameServer并進行注冊

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

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

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

接著就是更新topc與隊列的對應關(guān)系，但不會通知生產(chǎn)者和消費者

路由管理：保存著broker的活躍列表和Topic對應的隊列列表

NameServer保存著活躍的broker列表，包括master和slave;NameServer用來保存所有的Topic和Topic對應的所有隊列的列表;NameServer用來保存所有的broker的filter列表

這些在RouteInfoManager這個類中都有

 

每個屬性通過名字就能清楚的知道是什么意思，之所以能用非線程安全的HashMap，是因為有讀寫鎖lock來對HashMap的修改做保護。

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

 

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

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

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

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

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

 

路由發(fā)現(xiàn)：RocketMQ的路由發(fā)現(xiàn)是非實時的。當topic對應的路由信息發(fā)生變化，NameServer并不會通知給客戶端。而是由客戶端定時拉取Topic對應的最新路由。不實時的路由發(fā)現(xiàn)引起的問題由客戶端進行解決，保證了NameServer邏輯的簡潔。客戶端定時向NameServer發(fā)起請求GET_ROUTEINFO_BY_TOPIC，獲取對應的信息

路由刪除：對于宕機或者關(guān)閉的broker，自動刪除相應的路由信息

路由刪除的觸發(fā)點有兩個：

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

其實初期RocketMQ采用的是zookeeper作為注冊中心的，后來為什么改成自研的NameServer了?

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

 

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

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

 

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