前言
上次我們一起了解了RocketMQ的基本架構原理，那簡單的回顧一下RocketMQ的架構組成。
RocketMQ其實包含了四個核心部分，NameServer、Broker、Producer、Consumer。
具體什么含義請參考上一篇文章內容，這里就不再重復介紹了。
NameServer作為RocketMQ的注冊中心，它關聯着生產者和消費者之間的數據通信，同時又存儲着Broker集群的各種部署信息，它十分的重要。
今天我們就從NameServer這個核心部分入手，開始更深入的理解一下RocketMQ的內部原理。
NameServer的部署
要搭建一個RocketMQ技術棧，必然要部署NameServer，那么NameServer是如何部署的呢？
其實上篇文章我們就提到過，NameServer是支持集群化部署的，可以保證高可用性。
我們都知道NameServer作為一個十分重要的核心組成部分，它一旦宕機，整個MQ就無法正常運轉了。
所以NameServer是一定要部署多台機器，保證任何時候都能對外提供服務的。
Broker是如何向NameServer注冊信息的
下一個問題，Broker是如何向NameServer注冊信息的呢？
是不是有人會這么認為？比如我們有10台Broker機器，2個NameServer機器，其中5台互注冊到一個NameServer上，另外5台會注冊到另外的一個NameServer上，這樣一來NameServer中的數據也就實現了分布式存儲，有很高的可擴展性。那真實情況是這樣嗎？
答案是否定的，雖然我們經常接觸分布式的理論，MQ也是解決分布式系統中各種問題的關鍵技術，但不代表所有的情況都適用於分布式存儲。
試想一下，如果NameServer分布式存儲Broker注冊的信息，那生產者從NameServer獲取信息時不是又面臨着和Broker相同的問題了嗎，不知道應該訪問哪個NameServer，所以這樣的方式是錯誤的。
RocketMQ的實際方案是，每個Broker都會向每個NameServer進行服務注冊。
這樣從NameServer獲取數據時無論從哪台機器上都能獲取到所有的數據，而且就算其中一個NameServer宕機了，其他NameServer也能繼續提供服務。
系統是如何從NameServer獲取信息的
了解了向NameServer注冊信息的方式，那么系統是如何從NameServer中獲取信息的呢？
首先我們要知道，系統想要從NameServer里獲取到什么信息？
其實主要就獲取到兩個信息，一是整套的Broker集群列表，二是通過一定的算法選擇要訪問的Broker機器，可以稱其為路由信息。
生產者和消費者自己每隔一段時間，主動去NameServer中拉取這些信息，其實RocketMQ的內部就是這么實現的。
Broker宕機了，NameServer是如何感知到的
在Broker向NameServer注冊了自己的信息后，如果這個時候由於各種原因，Broker宕機了，此時如果不去告知NameServer，那么NameServer中的信息就是錯誤的，當系統獲取信息時可能會出現將消息發送到宕機的Broker的情況，導致系統出錯，所以NameServer中信息的准確性是很重要的，那么當Broker宕機時，NameServer是真么感知到的呢？
這就要講到心跳檢測了。
就和我們一樣，如果心跳停止了，就意味着系統出現了問題，需要治療了。
Broker會每隔30s向每一個NameServer發送心跳請求，證明自己還活着。而NameServer再接收到心跳請求后，就會記錄下這台Broker發送心跳請求的時間。
然后，NameServer自己每10s會掃描一次所有Broker留下的心跳請求時間，如果發現哪台Broker留下來的心跳請求時間距離當前時間超過120s了，那么就會斷定這台Broker已經掛掉了，就會更新自己的Broker列表信息。
系統是如何感知到Broker宕機的
剛才我們知道了Broker宕機后，NameServer是可以感知到的，但生產者和消費者系統如果不能感知到宕機的信息，問題還是不能解決的，那么系統是如何感知到Broker宕機的呢？難道只要有Broker宕機了，NameServer就要主動發送消息給各個系統嗎？
這是不靠譜的，就算是NameServer主動發送消息給所有系統，也無法解決問題。
我們想一下，如果這時候Broker宕機了，但是同時生產者已經把消息發出來給這台宕機的Broker了，而這個時候NameServer經過心跳檢測剛剛感知到這個情況，再去主動發送給這個生產者，這樣當然不能解決問題，報錯已經發生了。
再想一下，NameServer就算是不主動發送消息給生產者，上邊我們已經了解每個系統間隔一段時間就會主動向NameServer拉取信息了，所以NameServer主動發送消息既不能保證實時性，又是一個多此一舉的過程。
那么實際解決方案是什么呢？
針對這個問題，以后我們會在專門研究生產者的時候做更詳細的講解，歡迎小伙伴們持續關注H.U.C-王子的文章，帶你更深入的走進消息中間件。
往期文章推薦：
