RocketMQ(五)：namesrv初探

原文链接： https://juejin.im/post/5acb5ebff265da237d035094

匠心零度 转载请注明原创出处，谢谢！

RocketMQ网络部署图

• NameServer：在系统中是做命名服务，更新和发现 broker服务。
• Broker-Master：broker 消息主机服务器。
• Broker-Slave： broker 消息从机服务器。
• Producer： 消息生产者。
• Consumer： 消息消费者。

说明： rocketmq系列都将会以rocketmq-4.1.0-incubating进行介绍。

在阅读源码时做了一定的注释，公众号【匠心零度】回复：rocketmq，可获得基于rocketmq4.1.0加详细中文代码注释 。欢迎大家 star、fork ！

下面来讨论下今天的主题namesrv。

namesrv存在意义

在RocketMQ网络部署图中，broker相当于服务端，而Producer、Consumer都是相当于其客户端，如果broker固定死永远不变，那么namesrv存在就没有任何一样的，但是由于服务端自动伸缩、故障以及升级等，服务端会变动，因此namesrv就有存在的意义了。

下面简单说明：

因此需要一个类似namesrv的东西存在，一般存在两种机制： 客户端发现机制和 服务端发现机制。

客户端发现机制

当发出请求服务时,客户端通过注册中心服务知道所有的服务实例。客户端接着使用负载均衡算法选择可用的服务实例中的一个并进行发送。

服务端发现机制

发出请求服务时,客户端通过请求负载平衡器，负载均衡器通过注册中心服务知道所有的服务实例。负载均衡器接着使用负载均衡算法选择可用的服务实例中的一个并进行发送。

备注： Nginx HTTP服务器和反向代理服务器就是这种。

两种机制总结

客户端发现机制：客户端有所有可用的服务实例，可以灵活方便的特定应用进行特定的负载均衡决策。

服务端发现机制：客户端只需要给负载均衡器发请求即可，客户端屏蔽掉了一些细节。

未完待续

---

如果读完觉得有收获的话，欢迎点赞、关注、加公众号【匠心零度】，查阅更多精彩历史！！！

加入知识星球，一起探讨！