RocketMQ 为什么选择自研 NameServer，而不是直接使用 ZooKeeper ？

RocketMQ 选择放弃 ZooKeeper（ZK）而自研 NameServer，是基于架构演进、CAP 定理权衡、以及系统运维复杂度等多方面深思熟虑的结果。

实际上，RocketMQ 的前身（MetaQ 1.x 和 2.x 版本）是使用 ZooKeeper 的，但在进化到 RocketMQ 3.0 时，阿里团队果断移除了 ZK 依赖，转而自研了极为轻量级的 NameServer。

以下是做出这一架构选择的核心原因：

ZooKeeper 是 CP 系统：ZK 保证强一致性（C）和分区容错性（P）。为了保证强一致性，在进行 Leader 选举时（例如节点宕机、网络抖动），ZK 集群会短暂不可用，牺牲了可用性（A）。
NameServer 是 AP 系统：RocketMQ 的 NameServer 节点之间互相独立，不进行任何数据同步（无状态）。它优先保证可用性（A）。只要还有一个 NameServer 存活，整个消息队列集群就能继续提供路由发现服务。
为什么选 AP？ 对于消息队列的路由注册与发现（即“哪个 Topic 在哪个 Broker 上”）来说，稍微延迟几秒感知到节点上下线是完全可以容忍的，但注册中心不可用是绝对不能容忍的。如果因为 ZK 选举导致路由服务整体挂掉，会直接阻断所有业务的消息收发。

ZooKeeper 太重：ZK 引入了复杂的 ZAB 协议（类似 Paxos），依赖磁盘持久化事务日志，对磁盘 I/O 和网络延迟非常敏感。运维一个高可用的 ZK 集群需要极高的专业知识，增加了系统的整体复杂度。
NameServer 极轻量：NameServer 的核心代码只有几千行，本质上就是一个基于内存的 KV 读写服务。它没有任何外部依赖，启动极快，部署极其简单。这大大降低了 RocketMQ 的使用门槛和运维成本。

在大型分布式网络环境中，网络分区（机房之间网络断开）是常态。ZK 集群如果遭遇网络分区，少数派节点会直接停止服务（因为无法凑齐过半数）。如果在高并发场景下，海量客户端同时重连 ZK，极易引发 ZK 集群雪崩。
NameServer 的设计中，Broker 会向所有的 NameServer 节点同时建立长连接并发送心跳。客户端（Producer/Consumer）只需要随机连接其中一台 NameServer 即可。这种 Peer-to-Peer 的架构天然免疫网络分区问题。

ZooKeeper 的所有写操作（如 Broker 注册）都需要通过 Leader 节点，并同步到半数以上的 Follower 节点才能返回成功。在节点规模庞大的集群中，这会成为性能瓶颈。
NameServer 的注册是直接写本地内存，无须节点间同步，性能极高。

很多人的疑问是：如果 NameServer 各个节点的数据不一致，导致 Producer 拿到了过时的路由信息（比如某个 Broker 已经宕机了，但 NameServer 里还有它的记录），该怎么办？

RocketMQ 的设计哲学是：注册中心只负责“尽力而为”的最终一致性，强一致性和容错由客户端（Producer/Consumer）来兜底。

具体机制如下：

心跳机制：Broker 每隔 30 秒向所有 NameServer 发送心跳。NameServer 如果 120 秒没收到心跳，就会剔除该 Broker。
客户端拉取：Producer/Consumer 每隔 30 秒从 NameServer 拉取一次最新路由信息。
(核心) 客户端容错（Fault Latency 机制）：如果 Producer 拿到了旧的路由信息，向一个已经宕机的 Broker 发送消息，必然会发生 TCP 连接失败或超时。此时，Producer 会在本地捕获异常，并自动重试另一个 Broker。同时，Producer 的“故障延迟机制”会在本地记录这个坏掉的 Broker，在接下来的一段时间内（如几分钟内）不再向它发送消息。

RocketMQ 放弃 ZooKeeper 自研 NameServer，本质上是“大道至简”架构理念的体现。它舍弃了 ZK 提供的、但对消息路由并非必需的强一致性，换取了极致的高可用性、极低的运维成本和极高的性能。客户端容错机制的配合，使得这种 AP 架构完美契合了消息队列的实际需求。

(注：业界后来的发展也印证了这一决策的正确性。Kafka 在早期的架构中重度依赖 ZooKeeper，导致饱受集群规模瓶颈和运维痛苦，最终在 Kafka 2.8 版本之后推出了 KRaft 模式，正式开始移除 ZooKeeper 依赖。)

播面