RocketMQ-NameServer

介绍

功能介绍
NameServer是一个Broker与Topic路由的注册中心，支持Broker的动态注册与发现，主要功能如下

• Broker管理：接受Broker集群的注册信息并且保存下来作为路由信息的基本数据，提供心跳监测机制，检查Broker是否还存活
• 路由信息管理：每个NameServer中都保存Broker集群的整个路由信息可用于客户端查询队列信息，Producer和Consumer通过NameServer可以获取真个Broker集群路由信息从而进行消息投递和消费

在RockerMQ的早期版本其实不叫RockerMQ，而是叫MetaQ，在MetaQ1.0和MetaQ2.0实际上是依赖的是Zookeeper，但是从MetaQ3.0的时候更名为RockerMQ，同时也去掉了Zookeeper，RocketMQ整体设计思想是来自于kafka的，kafka是使用Zookeeper的，所以早期版本也是使用的Zookeeper，到了后期发展，摈弃了Zookeeper，自己写了一套NameServer，保证独立性，采用Zookeeper需要保持强一致性，如果采用Zookeeper那么就会降低RockerMQ，使用Zookeeper，还会导致整体架构就会变得复杂，在维护、搭建成本都会上升，为了保证高新能，低维护成本，那么就开发了NameServer

路由注册
NameServer通常也是以集群方式部署的，不过NameSever是无状态的，即NameServer集群中各个节点间是无差异的，各个节点间相互不进行信息通讯，那各节点是如何进行数据同步的呢？是在Broker启动时，轮询NameServer列表，与每个NameServer建立长连接，发起注册请求，在NameServer内部维护着一个Broker列表，采用动态存储Broker的信息！

• 优点：NameServer集群搭建简单，NameServer扩容简单
• 缺点：如果新增NameServer节点，对于已经启动Broker而言是无感知的，必须需要从新在Broker的NameServer列表上新增NameServer的节点信息，然后从新启动，那么也就是说对于Broker扩容是不简单的

路由删除
由于Broker关机、宕机、或者网络波动等原因，NameServer没有收到Broker的心跳，NameServer可能将其从Broker列表中剔除！在NameServer中有一个定时任务，默认每个10秒扫描一次Broker列表，查看每个Broker的罪行心跳时间戳距离当前时间是否超过120秒，如果操过，则会判断Broker失败，然后将其从Broker中剔除

对于RockerMQ日常运维工作时，例如对RockerMQ进行升级，需要停掉某台机器上的Broker，那么运维需要将Broker的读写权限禁用掉，一旦client端（生产者、消费者）发送、接受消息的时候，都会收到Broker的NO_PERMISSION响应，然后client会对其Broker进行重试，并且切换到Broker集群的其他Broker节点上去，然后等待当前这台Broker机器流量为0时，然后将起Broker停掉

路由发现
RocketMQ的路由发现采用的是Pull模型，当Topic路由信息发生变化时，NameServer不会主动推送给客户端，而是客户端定时拉取主题最新的路由，默认让客户端每30秒会拉取一次最新的路由

• Push：NameServer主动推送，推送模型，实时性较好，需要client(生产者、消费者)维护一个长链接，适用于实时性较高、client数量不多，NameServer数据变化比较频繁的场景
• Pull：拉取模型，client主动去拉，实时性较差
• Long Polling：长轮询模型，如Nacos就是采用这种长轮询的机制做服务心跳监测和配置中心的，长轮询就是客户端定时向服务端发送请求查看是否有数据变更，没有变更会阻塞在服务端，并不是直接返回，这里会阻塞住一段时间，如30秒，如果在这阻塞的30秒钟服务端数据发生变化，那么即可返回数据给客户端，这种长轮询的模型是对Push和Pull的结合，充分利用二者的优势，屏蔽了他们的劣势

客户端（生产者、消费则）NameServer的选择策略
客户端在配置的时候必须写上NameServer集群的地址，那么客户端到底连接哪个NameServer节点呢？客户端会产生一个随机数，然后再与NameServer节点数量取模，此时得到的就是所要连接的节点索引，然后进行连接，如果连接失败，那么采用Round-Robin的策略，逐个尝试连接其他节点！
说白了就是首 先采用随机策略进行选择，如果失败后在采用轮询策略！