NameServer 是专为 RocketMQ 设计的轻量级名字服务，它的源码非常精简，八个类 ，少于1000行代码。
图片
这篇文章， 笔者会从基础概念、Broker发送心跳包、NameServer 维护路由、Zookeeper vs NameServer 四个模块揭秘名字服务的设计精髓。
图片
1、Broker 会每隔 30 秒向所有的 NameServer 发送心跳命令 ；
使用 CountDownLatch 实现多线程同步，可以获取发往所有的 NameServer 的心跳命令的响应结果
2、心跳命令包含两个部分：请求头和请求体
图片
NameServer 在接收到 Broker 发送的心跳请求之后，通过默认的处理器来处理请求，保存路由信息成功后，注册成功状态返回给 Broker 服务。
源码中，我们可以看到路由信息保存在 HashMap 中 。
图片
2、读操作：查询主题信息，操作读锁
图片
我们可以将 NameServer 实现注册中心的方式总结为：RPC 服务 + HashMap 存储容器 + 读写锁 + 定时任务 。
1、NameServer 监听固定的端口，提供 RPC 服务
2、HashMap 作为存储容器
3、读写锁控制锁的颗粒度
4、定时任务
那为什么 RocketMQ 不用 Zookeeper 做为注册中心呢 ？
我们先温习下 CAP 理论。
图片
CAP 理论是分布式架构中重要理论。
1、一致性( Consistency ) ：所有节点在同一时间具有相同的数据 ;
2、可用性( Availability ) ：保证每个请求不管成功或者失败都有响应 (某个系统的某个节点挂了，但是并不影响系统的接受或者发出请求) ;
3、分隔容忍( Partition tolerance ) ：系统中任意信息的丢失或失败不会影响系统的继续运作。 (在整个系统中某个部分，挂掉了，或者宕机了，并不影响整个系统的运作或者说使用) 。
Zookeeper 是一个典型的 CP 注册中心 ，通过使 ZAB 协议来保证节点之间数据的强一致性。
笔者曾经遇到过一起神州专车服务宕机事故，zookeeper 集群不堪重负，一直在选主 。架构负责人修改了 zookeeper 的 jvm 参数，重启集群后 , 才临时解决了问题。
因为 MetaQ 集群和服务治理共用一组 zookeeper 集群 。
为了减少 zookeeper 集群的性能压力，架构团队将 MetaQ 使用的 zookeeper 集群独立出来。
这次事故让我认识到：Zookeeper 作为 CP 注册中心，大规模使用场景下，它就变得很脆弱，我们要非常小心的使用。
淘宝中间件博客出了一篇文章 : 阿里巴巴为什么不用 ZooKeeper 做服务发现 ？
文章有两个观点，笔者认为非常有借鉴意义。
1、当数据中心服务规模超过一定数量 ( 服务规模=F{服务 pub 数,服务 sub 数} )，作为注册中心的 ZooKeeper 很快就会像下图的驴子一样不堪重负。
2、可以使用 ZooKeeper，但是大数据请向左，而交易则向右，分布式协调向左，服务发现向右。
相比 ZooKeeper ，NameServer 是一个典型的 AP 注册中心，它有如下优点：
1、代码不到 1000 行，实现简单，易于维护 ;
2、性能极好，除了网络消耗，基本都是本地内存操作 ;
3、服务都是无状态，且节点之间并不交互，运维简单；
RocketMQ 的设计者之所以选择自研名字服务，遵循着架构设计的准则，笔者总结为：简单、高效、适当妥协。
本文链接：http://www.28at.com/showinfo-26-5193-0.html聊聊 RocketMQ 名字服务
声明：本网页内容旨在传播知识，若有侵权等问题请及时与本网联系，我们将在第一时间删除处理。邮件：2376512515@qq.com
Copyright © 2016-2023 天津谷骐科技有限公司 版权所有 sitemap.xml
违法及侵权请联系：2376512515@qq.com 津ICP备18001702号
津公网安备 12010102000574号
