RocketMQ学习：NameServer

NameServer

NameServer是一个Broker和Topic路由的注册中心，支持Broker的动态注册和发现

主要包括两个功能

Broker管理:接受 Broker集群的注册信息并且保存下来作为路由信息的基本数据;提供心跳检测机制,检查 Broker是否还存活。

路由信息管理:每个NameServer中都保存着 Broker集群的整个路由信息和用于客户端查询的队列信息。Producer和 Consumer通过NameServer可以获取整个 Broker集群的路由信息,从而进行消息的投递和消费。

为什么放弃Zookeeper选择NameServer？

1.失去独立性
2.Zookeeper是CP强一致性的，RocketMQ不需要强一致性

路由注册

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

Broker节点为了证明自己是活着的,为了维护与NameServer间的长连接,会将最新的信息以心跳包的方式上报给NameServer,每30秒发送一次心跳。心跳包中包含 Brokered、 Broker地址、 Broker名称、Broker所属集群名称等等。NameServer在接收到心跳包后,会更新心跳时间戳,记录这个 Broker的最新存活时间。

NameServer无状态方式有什么优缺点：

优点：NameServer集群搭建简单
缺点：对于Broker，必须明确指出所有NameServer地址，否则未指出的将不会去注册。NameServer不能随便扩容

路由剔除

由于 Broker关机、宕机或网络抖动等原因, NameServer没有收到 Broker的心跳, NameServer可能会将其从 Broker列表中剔除。
NameServer中有一个定时任务,每隔10秒就会扫描一次 Broker表,查看每一个 Broker的最新心跳时间戳距离当前时间是否超过120秒,如果超过,则会判定 Broker失效,然后将其从 Broker列表中剔除。

路由发现

Rocketmq的路由发现采用的是pull模型。当 Topic路由信息出现变化时, Nameserver不会主动推送给客户端,而是客户端定时拉取主题最新的路由。默认客户端每30秒会拉取一次最新的路由。

Push模型：推送模型。需要维护一个长链接，其实时性较好。适合于实时性要求较高，Client数量较少，Server端数据变化较频繁。
Pull模型：拉取模型。存在的问题，实时性较差

客户端NameServer选择策略

客户端在配置时必须要写上NameServer集群的地址,那么客户端到底连接的是哪个NameServer节点呢?客户端首先会首先一个随机数,然后再与NameServer节点数量取模,此时得到的就是所要连接的节点索引,然后就会进行连接。如果连接失败,则会采用轮询策略,逐个尝试着去连接其它节点。