消息隊列RocketMQ版是阿里云基于Apache RocketMQ構建的低延遲、高并發、高可用、高可靠的分布式消息中間件。
我們知道RocketMQ是個消息隊列，這個消息隊列是分為多個組件的，其中包括broker、producer、consumer等，那么這些個組件之間如何交互呢?或者說它們如何獲得對方的狀態呢
大魚相信聰明的你應該已經猜到了，就是通過一個注冊中心來控制，其實大魚本人我在寫這篇文章之前一直在糾結到底如何稱呼NameServer在RocketMQ中的地位呢?
說是大腦吧，但是它又不完全算是指揮中心，也沒有存儲消息(消息存儲在broker中)，大腦中應該是存儲這這些才有資格叫做大腦吧;要說不是大腦吧，它又存在一部分的指揮作用，producer發送消息，需要先通過NameServer獲取到broker和Topic的對應關系，獲取到broker的地址信息，再去長連接broker來發送消息，而且還和broker之間有著心跳機制來維持broker的存活狀態，維持整個集群的穩定性和可用性
所以，大魚我給NameServer起名叫做 偽大腦 ;
啥玩意?偽大腦，那是不是還有真大腦呢?真大腦是什么?
我真是太喜歡好奇的你了，一猜你就是風華正茂，愛好學習的中華好兒女，沒錯，我賣關子其實就是下一篇咱們要一起學習的broker，這是RocketMQ中最核心的了，因為很多邏輯控制都是在這里邊完成(定時延時、半消息)，還有存儲消息的文件、存儲消費offset的文件等等
NameServer
NameServer是什么
知其然，再知其所以然，那到底NameServer是個什么東西呢?
NameServer是一個非常簡單的Topic路由注冊中心，其角色類似Dubbo中的zookeeper，支持Broker的動態注冊與發現。NameServer是一個幾乎無狀態節點，可集群部署，節點之間無任何信息同步。
NameServer存儲Topic和Broker的信息，Broker啟動的時候會向所有的NameServer注冊。Producer在發送消息之前會先從NameServer獲取Broker地址列表，按照負載均衡算法從列表中選擇一臺Broker服務器發送消息
NameServer和Broker保持長連接，每隔30s檢測Broker是否存活，如果Broker宕機，從路由注冊表中刪除。路由變化不會馬上通知Producer，這樣實現降低了NameServer實現復雜度，Producer會通過容錯機制來保證消息發送高可用。
Producer與Name Server集群中的其中一個節點(隨機選擇)建立長連接，定期從Name Server取Topic路由信息，并向提供Topic服務的Master建立長連接，且定時向Master發送心跳。Producer完全無狀態，可集群部署。
Consumer與Name Server集群中的其中一個節點(隨機選擇)建立長連接，定期從Name Server取Topic路由信息，并向提供Topic服務的Master、Slave建立長連接，且定時向Master、Slave發送心跳。Consumer既可以從Master訂閱消息，也可以從Slave訂閱消息，訂閱規則由Broker配置決定。
NameServer集群
RocketMQ集群，應該是線上采用的相當多的一種架構了，分為四個主要組成部分：生產者集群、消費者集群、NameServer集群和Broker集群，其中的NameServer集群是什么樣子的呢?這個還挺有意思的，和別的集群不太一樣，一起來看看為啥
我們了解的集群，一般都是互幫互助，起到一個高可用的作用;絕大多數集群應該都是這個樣子的，而NameServer集群卻不是這個樣子的，NameServer集群說白了其實屬于一個偽集群，為什么這么說呢?
因為NameServer集群中的多個節點是互不交互的，就是等同于多個獨立的NameServer機器部署在NameServer集群中，每個機器都可以單獨支持這個集群的運轉，多個機器的作用其實就是備份的作用
NameServer集群如何部署
NameServer 是整個集群的路由中心，如果沒有了它，生產者往哪個 Broker 投遞消息都不知道，沒有了它，會很麻煩!
為了保證高可用性，NameServer 必然是需要支持多臺部署的。如果 NameServer 就部署一臺機器的話，一旦它宕機了會導致 RocketMQ 集體出現故障。
所以多機器部署保證了任何一臺 NameServer 宕機，其他機器上的 NameServer 可以繼續對外提供服務。
如果NameServer集群中的一個機器掛掉了怎么辦，對集群有什么影響
對于整個RocketMQ集群來說問題不大，因為設計優秀的RocketMQ集群不會因為一臺NameServer機器掛掉而導致整個集群受影響甚至不可用。一般我們會有報警系統來報警關于NameServer機器掛掉的信息，有相應的運維人員再去處理
NameServer作用
NameServer是一個非常簡單的Topic路由注冊中心，其角色類似Dubbo中的zookeeper，支持Broker的動態注冊與發現。NameServer是一個幾乎無狀態節點，可集群部署，節點之間無任何信息同步。
NameServer在RocketMQ集群中起到了類似于注冊中心的作用，我們先來看下NameServer的源碼架構
其實結構也很簡單，不算復雜，大家如果有興趣研究，可以花點時間去研究，源碼地址：
https://github.com/rocketmq
NameServer在RocketMQ中的作用大概大魚同學給分了三類，叫做路由管理、路由發現和路由刪除，也很好理解，來，我給大家簡單解釋下
- 路由管理就是保存著broker的活躍列表和Topic對應的關系
- 路由注冊和發現就是Topic對應的broker信息發生變化時的更新(非實時性)
- 路由刪除就是對于broker機器宕機或者關閉時自動刪除相應路由
我們知道broker和NameServer的關系是很緊密的，單個broker會和所有的NameServer保持長連接，broker啟動時會輪詢所有的NameServer并進行注冊
broker每隔30秒(此時間沒有辦法更改的哦，切記哦)會向所以的NameServer發送心跳，心跳包含了所有的Topic信息
由此可以看出：如果broker中包含太多Topic，心跳信息過大的話可能會造成網絡傳輸較慢
NameServer每隔10秒也會掃描所有存活著的broker的，這個時間也是無法更改的，若某個連接2分鐘內(當前時間與最后更新時間差值超過2分鐘，此時間無法更改)沒有發送心跳數據，則斷開連接，一旦連接斷開，nameserver會感知，感知會有稍稍的延遲，為啥延遲我應該不用說了吧?
接著就是更新topc與隊列的對應關系，但不會通知生產者和消費者
路由管理：保存著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相關的所有信息，包括topic有哪些隊列，這些隊列在那些broker上等。
DefaultRequestProcessor是NameServer的默認請求處理器，他處理了定義在rocketmq-common模塊中RequestCode定義的部分請求，比如注冊broker、注銷broker、獲取topic路由、刪除topic、獲取broker的topic權限、獲取NameServer的所有topic等
路由注冊和發現：Broker的啟動注冊和Topic的關系變動
Broker在啟動時向所有的NameServer心跳語句，每隔30S向所有NameServer發起心跳包。NameServer收到心跳包后更新緩存。NameServer每隔10S掃描brokerLiveTable，如果連續120S沒有收到心跳包，則NameServer移除Broker的路由信息同時關閉Socket連接。
路由注冊在broker啟動時觸發，broker啟動時會和所有NameServer創建心跳連接，向NameServer發送Broker的相關信息。NameServer在RouteInfoManager類中維護了Broker相關信息的緩存，進行更新動作。更新時用了讀寫鎖，既保證了極高并發場景下的讀效率，又避免了并發修改緩存。
路由發現：RocketMQ的路由發現是非實時的。當topic對應的路由信息發生變化，NameServer并不會通知給客戶端。而是由客戶端定時拉取Topic對應的最新路由。不實時的路由發現引起的問題由客戶端進行解決，保證了NameServer邏輯的簡潔。客戶端定時向NameServer發起請求GET_ROUTEINFO_BY_TOPIC，獲取對應的信息
路由刪除：對于宕機或者關閉的broker，自動刪除相應的路由信息
路由刪除的觸發點有兩個：
- NameServer啟動時開啟的定時任務，每隔10s掃描一次brokerLiveTable，檢測上次心跳包與當前系統時間差，如果時間差大于120s，則移除Broker的相關信息。
- Broker正常關閉，會向NameServer發送UNREGISTER_BROKER消息。
其實初期RocketMQ采用的是zookeeper作為注冊中心的，后來為什么改成自研的NameServer了?
這個問題其實我也不想太多的多說，這個可能需要了解zookeeper，如果不了解這個東西的話，其實我說了也是沒啥大用的
首先，zookeeper中最主要的功能就是master的選舉，但是呢?對于RocketMQ不太合適，你想啊，RocketMQ中的master并不會存在全部的Topic信息，所以選擇master沒什么意義
其次，對于RocketMQ來說，這個注冊中心的作用不僅要保存相關的信息(broker活躍列表、Topic對應信息等)，還有就是需要一些邏輯來處理相應的數據，比如每隔10秒檢測一次活躍的broker來更新列表，這些邏輯如果換做是zookeeper的客戶端來處理的話，算是比較麻煩的
因此，既然zookeeper對于RocketMQ來說是屬于一個重量級的注冊中心，所以不如自己寫一個簡易的注冊中心來實現，像上面說的集群，NameServer集群是屬于偽集群，節點之間不存在相應的交互，只是起到一個備份的作用，這樣使得RocketMQ集群變得更加靈活。
原文地址：https://mp.weixin.qq.com/s/nDBbOyfo9I1o3LHgYg2XgQ
