study-rpc-关于nameServer和zk做注册中心的思考

study-rpc-all文档（nameServer和zk做注册中心的思考 ）

• 作者：爱抄中间件代码的路人丙

源码地址：https://gitee.com/li-zhongwei/study-rpc-all添加链接描述

打个小广告，觉得有收获的小伙伴，希望给一个stater，这是笔者前进最大的动力！

第三章 分布式协调者

zk，想要了解的话，大家可以百度

最近准备去看一下rocketMq的nameServer模块的源码（听说nameServer也是一个轻量级的分布式的协调组件）

3.1 roketMQ的分布式协调者nameServer分析（待完成）

3.1.1 nameServer的角色-大脑中枢

nameServer在roketMQ中主要扮演的是注册中心的角色或者说大脑的角色，可以说在roketMQ集群中缺一不可，但听说在roketMQ早期版本，注册中心用的还是zk（zk做注册中心确实强大，watcher可以很容易的实现动态扩缩容上下线通知）,不过后面换成了nameServer，至于为什么，还听我胡编乱造（说错了，娓娓道来）

关于nameServer

• nameServer的职责

通过上图可以发现，nameServer主要通过心跳包来维护broker集群（这里不做解释，感兴趣的老铁们可以去翻阅相关的源码看一看，nameServer的代码比较少，比较好看懂，实在害怕，推荐一本书籍：《RocketMQ技术内幕》）

以下粘贴一些关于自己阅读nameServer源码时：梳理的一些流程图

nameServer启动流程：

nameServer路由管理：

3.2 关于注册中心zk VS nameServer

先简单看一下zk实现注册中心的流程：

再看一下nameServer实现注册中心的流程：

不知道大家有不有看到什么区别？

再来一张比较全的图：

大家注意红色字体了吗，nameServer集群之间是没有消息同步手段的，是通过broker节点定时轮询的方式向每个nameServer节点上报自己的信息状态

而关于zk呢？了解zk的朋友肯定知道，zk集群之间存在选举算法，并且数据同步强一致性

简单总结一下：nameServer和zk实现注册中心的区别

nameServer：弱数据一致性

• 存在的问题：nameServer集群之间数据存在延迟，消费者或者生产者获取的路由信息存在延迟，可能导致生产或者消费的broker已经下线（关于这个问题，roketMQ是在生产和消费端做的处理）
• 优点：相比较于zk来说，少了很多操作，性能会比zk更好，更适合于高并发的场景

zk：强数据一致性

• 存在的问题：性能不如nameServer，在高并发的场景容易成为瓶颈
• 优势：数据一致性，不存在延迟

最后，我简单分享一下自己的观点：关于为什么roketMQ最终会选在nameServer作为注册中心：

（1）初期的时候，可能那时候的阿里的流量和并发对系统的要求并没有那么高，zk完全可以支撑

（2）随着流量的增长，zk集群成为整个系统的瓶颈越发的明显

（3）一顿分析之后，发现业务上并用不到zk的强一致性，注册中心对于延迟是可以容忍的，而且针对延迟带来的问题也可以在业务负载的层面去做

（4）最终研发了小巧性能不错且贴合业务的nameServer

大家也可以在评论区分享一下自己的看法