NameServer是一個注冊中心，提供服務注冊和服務發現的功能。NameServer可以集群部署，集群中每個節點都是對等的關系（沒有像ZooKeeper那樣在集群中選舉出一個Master節點），節點之間互不通信。
服務注冊
Broker啟動的時候會向所有的NameServer節點進行注冊，注意這里是向集群中所有的NameServer節點注冊，而不是只向其中的某些節點注冊，因為NameServer每個節點都是對等的，所以Broker需要向每一個節點進行注冊，這樣每一個節點都會有一份Broker的注冊信息。

服務發現
Broker向NameServer注冊以后，生產者Producer和消費者Consumer就可以從NameServer中獲取所有注冊的Broker信息，并從中選取Broker進行消息的發送和消費。

以生產者為例，在NameServer集群部署模式下，生產者會從多個NameServer中隨機選取一個進行通信，從中拉取所有Broker的注冊信息，并將拉取到的信息進行緩存，生產者知道了Broker的信息后，就可以得知Topic的分布情況，然后選取一個消息隊列，與其所在的Broker通信進行消息的發送。如果通信的Nameservre宕機，消費者會輪詢選擇下一個NameServer。

為什么需要NameServer?

在使用RocketMQ的時候，為了提升性能以及應對高并發的情況，一般都會使用多個Broker進行集群部署，假設沒有注冊中心，對于Broker來說，如果想獲取到集群中所有的Broker信息（生產者和消費者需要通過某個Broker獲取整個集群的信息，從而得到Topic的分布情況），每個Broker都需要與其他Broker通信來交換信息，以此來得到集群內所有Broker的信息，在Broker數量比較大的情況下，會造成非常大的通信壓力。

為什么不使用zookeeper這樣的分布式協調組件？
首先zookeeper的實現復雜，引入zookeeper會增加系統的復雜度，并且zookeeper在CAP中選擇了CP，也就是一致性和分區容錯性，從而犧牲了可用性，為了保持數據的一致性會在一段時間內會不可用。

而NameServer在實現上簡單，RocketMQ的設計者也許認為對于一個消息隊列的注冊中心來說，一致性與可用性相比，可用性更重要一些，至于一致性可以通過其他方式來解決。

假如選擇了CP的ZooKeeper，先不考慮其他原因，在ZooKeeper不可用的時候，如果有消費者或生產者剛好需要從NameServer拉取信息，由于服務不可用，導致生產者和消費者無法進行消息的生產和發送，在高并發或者數據量比較大的情況下，大量的消息無法發送/無法消費影響是極大的，而如果選擇AP，即便數據暫時處于不一致的狀態，在心跳機制的作用下也可以保證數據的最終一致性，所以RocketMQ選擇了自己實現注冊中心，簡單并且輕量。

舉個例子，假如集群中有三個Broker（分別為 A、B、C），向三臺NameServer進行了注冊（也分別為A、B、C），消費者從NameServer中獲取到了三個Broker的信息，如果此時BrokerA需要停止服務，分別通知三臺NameServer需要下線，從NameServer中剔除該Broker的信息，由于網絡或者其他原因，NameServer A和B收到了下線的請求，NameServer C并未收到，此時就處于數據不一致的狀態，如果某個消費者是與NameServer C進行通信，會認為Broker還處于可用的狀態：

對于這種情況，首先NameServer與Broker之間會有一個心跳機制，NameServer定時檢測在某個時間范圍內是否收到了Broker發送的心跳請求，如果未收到，會認為該Broker不可用，將其剔除（在下面會講到），所以對于NameServer來說，盡管數據會暫時處于不一致的狀態，但是可以保證過一段時間之后恢復數據的一致性，也就是最終一致性。

對于消費者來說，既然可以從NameServer C中獲取到Broker A的信息，那么消費者就認為Broker A可用，如果發送的消息所在的消息隊列在Broker A中，就會與Broker A通信進行發送，但實際上Broker A實際上是不可用的，消息會發送失敗，所以RocketMQ設計了消息重試機制以及故障延遲機制。

Broker注冊

Broker啟動后會開啟定時向NameServer進行注冊（發送心跳包）的任務，發送心跳包的時間間隔可以在配置文件中進行設置，但是最長不能超過10s，也就是說Broker最長10秒鐘會向Nameserver發送一次心跳包。

NameServer收到Broker的注冊請求（心跳包）后，會判斷Broker之前是否已經注冊過，如果未注冊過將其加入到注冊的Broker集合brokerAddrTable中，同時也會記錄收到注冊請求的時間，將其加入到brokerLiveTable中，里面記錄了NameServer收到每個Broker發送心跳包的時間，在進行心跳檢測的時候根據這個時間戳來判斷是否在規定時間內未收到該Broker發送的心跳包。

讀寫鎖
由于NameServer可能同時收到多個Broker的注冊以及生產者或者消費者的拉取請求，為了保證數據的一致性（因為有讀寫請求同時發生或者寫與寫請求同時發生），在處理相關請求的時候需要加鎖，為了提高性能，使用了ReadWriteLock讀寫鎖，處理注冊請求時會先添加寫鎖，處理拉取請求時添加讀鎖，這樣如果某一時刻都是讀的請求可以同時進行，互不影響，如果有寫請求，其他請求就需要等鎖釋放才可以進行往下進行。如果不使用讀寫鎖，直接對所有的請求加鎖，會影響性能，實際上讀與讀之間并不需要加鎖。

心跳檢測

Nameserver在啟動的時候會開啟一個用于心跳檢測的定時任務（每10s執行一次），定時掃描處于不活躍狀態的Broker，如果在規定時間內未收到某個Broker的心跳包，會認為此Broker不可用，需要將其進行剔除。

上面說到brokerLiveTable保存了當前NameServer收到的心跳數據，里面記錄了每一個Broker最近進行注冊/發送心跳的時間戳，所以只需遍歷brokerLiveTable，獲取每一個Broker最近一次發送心跳的時間進行判斷，如果上一次發送心跳的時間 + 過期時間（120s） 小于 當前時間，也就是超過120s沒有收到某個Broker的心跳包，則認為此Broker已下線，將Broker移除。

Broker下線

正常下線
當Broker下線的時候會向NameServer發起取消注冊的請求，NameServer收到請求后會將Broker剔除。

異常下線

如果Broker異常宕機，或者發送給NameServer的取消注冊請求由于某些原因并未發送成功，NameServer可能并未感知到Broker的下線，由于心跳機制定時檢測的功能，會在一段時間后發現未收到Broker的心跳請求，主動將Broker剔除。

生產者和消費者

生產者和消費者都會定時從NameServer中更新Broker的注冊信息，默認是30s進行一次更新:

public class MQClientInstance {private void startScheduledTask() {this.scheduledExecutorService.scheduleAtFixedRate(new Runnable() {@Overridepublic void run() {try {// 更新路由信息 MQClientInstance.this.updateTopicRouteInfoFromNameServer();} catch (Exception e) {log.error("ScheduledTask updateTopicRouteInfoFromNameServer exception", e);}}}, 10, this.clientConfig.getPollNameServerInterval(), TimeUnit.MILLISECONDS);}
}

對應的相關源碼可參考：

【RocketMQ】【源碼】NameServer的啟動
【RocketMQ】【源碼】Broker服務注冊