在 RocketMQ 的架构设计中，注册中心为何不采用 Zookeeper，而是自行实现了 NameServer？请说明其设计考量。
考察说明
考查对 RocketMQ 架构设计及注册中心选型权衡的理解。
回答思路
- 【回答框架 1】RocketMQ 选择自研 NameServer 而非直接使用 Zookeeper，核心原因在于两者设计目标不同。Zookeeper 是通用的分布式协调服务，提供强一致性的数据存储与通知，而消息队列的注册中心更关注路由信息的轻量、高可用与可用性。
- 【回答框架 2】NameServer 的设计强调简单与高性能，它只维护 Broker 的路由信息（如 Topic 与 Broker 映射），并采用最终一致性模型。每个 NameServer 节点独立持久化全量路由，无节点间通信，从而避免了 Zookeeper 的选主、事务等复杂机制，也降低了运维成本。
- 【回答框架 3】Zookeeper 的强一致性能保证路由数据的实时一致，但会带来额外的同步开销与可用性问题（如 Leader 选举期间的不可用）。在消息场景中，短暂的注册信息不一致是可容忍的，NameServer 通过客户端（Producer/Consumer）定期拉取和 Broker 心跳上报来最终收敛，优先保证了整个集群的可用性。
- 【回答框架 4】此外，RocketMQ 的设计目标之一是高吞吐与简单部署。自行实现 NameServer 可以减少外部依赖，便于快速故障恢复和水平扩展，同时避免了 Zookeeper 在大量 Topic 或高频心跳下可能出现的性能瓶颈。这一选择体现了架构上对可用性与简单性的优先权衡。
- 【关键点 1】NameServer 采用最终一致性，避免 Zookeeper 强一致带来的性能代价。
- 【关键点 2】每个 NameServer 节点独立全量存储路由，无节点间通信，简化协调。
- 【关键点 3】使用心跳和定时拉取机制实现路由收敛，优先保证消息服务可用性。
- 【关键点 4】自研可减少外部依赖，降低运维复杂度，便于水平扩展。
- 【易错点 1】不认为 NameServer 完全无状态，它实际持久化路由信息。
- 【易错点 2】不把 Zookeeper 的一致性保证与 NameServer 的最终一致性混为一谈，二者适用场景不同。
- 【易错点 3】不忽略 NameServer 故障时的客户端重试与路由刷新机制。