前言
上次我們一起了解了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-王子的文章，帶你更深入的走進訊息中介軟體。
往期文章推薦：
