为什么 RocketMQ 不使用 Zookeeper 作为注册中心呢？而选择自己实现 NameServer？

RocketMQ 为何选择 NameServer 而非 ZooKeeper

RocketMQ 选择自研轻量级的 NameServer 作为注册中心，而非使用 ZooKeeper，主要是基于高性能、低依赖、简单可靠的设计哲学，以更好地适配消息队列场景的高吞吐、低延迟核心需求。

架构定位不同
ZooKeeper 是强一致性的分布式协调服务，而 RocketMQ 的注册中心只需实现最终一致性的节点发现与状态维护，无需复杂的选举、事务和 Watcher 机制，NameServer 的轻量化设计更符合该场景。
性能与吞吐优先
RocketMQ 作为高吞吐消息中间件，Broker 与注册中心之间需要频繁心跳（30秒一次），若使用 ZooKeeper 会产生大量 Watcher 通知和网络开销，而 NameServer 采用无状态+定时拉取模式，极大降低了注册中心压力。
去中心化与低依赖
ZooKeeper 本身是一个集群，存在选举和半数存活要求，增加了系统复杂性和故障点；NameServer 各节点相互独立，任意一个存活即可提供服务，实现了去中心化，提升了可用性。
自主可控与简化部署
自研 NameServer 避免了引入外部重量级组件，减少了依赖、运维成本和版本兼容问题，同时可以针对消息队列场景进行定制优化（如路由信息的高效组织与快速查询）。

ZooKeeper 的强一致性：通过 Zab 协议保证数据一致，但写操作需集群多数节点确认，延迟较高（通常 10-100ms），且 Watcher 机制在节点数多时存在“羊群效应”。
NameServer 的最终一致性：
- Step 1：Broker 每 30 秒向所有 NameServer 发送心跳包（包含 Topic 配置、Broker 地址等）。
- Step 2：NameServer 收到心跳后更新内存中的路由表（HashMap<String/* Topic */, List<QueueData>>），并记录 Broker 最后存活时间。
- Step 3：Producer/Consumer 每 30 秒从任意 NameServer 拉取最新路由信息，若发现 Broker 不可用（120秒无心跳），则从路由表中剔除。
- 设计合理性：消息队列场景允许短暂的路由不一致（消费者重试机制可弥补），换取更高的可用性和吞吐量。

线程安全：NameServer 使用 ConcurrentHashMap 存储路由表，保证多线程并发更新的安全性；Broker 心跳请求通过线程池处理。
版本差异：RocketMQ 4.x 版本 NameServer 已稳定；5.x 版本优化了网络模块（如使用 Netty），但核心路由机制不变。

NameServer 如何保证高可用？
答：NameServer 采用多节点部署，客户端随机连接一个，若连接失败自动切换到下一个；每个 NameServer 存储全量路由，任意存活节点均可提供服务。
如果 NameServer 全部宕机，现有连接是否受影响？
答：不影响。Producer/Consumer 会缓存路由信息，继续向已知的 Broker 发送/消费消息；仅当需要更新路由（如 Broker 下线）时才会受影响。
与 Kafka 使用 ZooKeeper 对比，优劣如何？
答：Kafka 早期依赖 ZooKeeper 管理元数据（Broker、Topic、分区），但 2.8 版本后开始推行 KRaft 模式（去 ZooKeeper），目的也是简化架构。RocketMQ 从一开始就采用更轻量的设计，更适合云原生环境。
NameServer 数据丢失怎么办？
答：路由数据本质是“状态缓存”，丢失后可通过 Broker 重新上报恢复；也可开启 configStorePath 将路由信息持久化到磁盘，重启时加载。

RocketMQ 选择 NameServer 是场景驱动设计的典型范例：在保证消息队列核心功能（路由发现）的前提下，通过牺牲强一致性、简化架构，实现了更高的性能、更低的延迟与更强的可控性，这是其能在高并发场景中稳定支撑万亿级消息流转的关键基础之一。