根据
CAP理论
，同时最多只能满⾜两个点，而zookeeper满足的是CP，也就是说zookeeper并不能保证服务的可用性，zookeeper在进⾏选举的时候，整个选举的时间太⻓，期间整个集群都处于不可用的状态，而这对于⼀个注册中⼼来说肯定是不能接受的，作为服务发现来说就应该是为可⽤性而设计。
基于性能的考虑，NameServer本身的实现⾮常轻量，⽽且可以通过增加机器的⽅式水平扩展，增加集群的抗压能⼒，而zookeeper的写是不可扩展的，⽽zookeeper要解决这个问题只能通过划分领域，划分多个zookeeper集群来解决，⾸先操作起来太复杂，其次这样还是⼜违反了CAP中的A的设计，导致服务之间是不连通的。
持久化的机制来带的问题，ZooKeeper 的 ZAB 协议对每⼀个写请求，会在每个 ZooKeeper 节点上保持写⼀个事务⽇志，同时再加上定期的将内存数据镜像（Snapshot）到磁盘来保证数据的⼀致性和持久性，而对于⼀个简单的服务发现的场景来说，这其实没有太⼤的必要，这个实现⽅案太重了。而且本身存储的数据应该是高度定制化的。
消息发送应该弱依赖注册中心，而RocketMQ的设计理念也正是基于此，生产者在第⼀次发送消息的时候从NameServer获取到Broker地址后缓存到本地，如果NameServer整个集群不可用，短时间内对于生产者和消费者并不会产⽣太⼤影响。
