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() {
@Override
public void run() {
try {
// 更新路由信息 MQClientInstance.this.updateTopicRouteInfoFromNameServer();
} catch (Exception e) {
log.error("ScheduledTask updateTopicRouteInfoFromNameServer exception", e);
}
}
}, 10, this.clientConfig.getPollNameServerInterval(), TimeUnit.MILLISECONDS);
}
}
对应的相关源码可参考：