一位7年工作经验的小伙伴去面架构师岗位，被问到这样一道面试题，说”RocketMQ为什么要放弃Zookeeper“。然后，想了很久好像没关注过，也不敢瞎猜。
那么今天，我给大家来聊一聊我对这个问题的理解。
1、注册中心
对于分布式消息中间件而言，当不同的消息存储在不同的Broker上，生产者和消费者对于Broker的选取，路由选择会面临以下几个问题：
1、生产者发一条消息，应该发到哪个Broker？消费者接收消息，从哪个Broker获取消息？
2、如果Broker增加或者减少了，客户端怎么知道？
3、一个新的生产者或者消费者加入，如何感知？
所以，只要是跟分布式服务调用的场景，都需要一个注册中心，在RocketMQ当然也中需要有一个这样的角色来管理Broker的信息。
而Kafka就是用了现成的Zookeeper，但是RocketMQ却偏偏没有这么做，而是自己实现了一个服务，这个服务叫做NameServer。
我们可以把NameServer理解为是RocketMQ的路由中心，每一个NameServer节点都保存了全量的路由信息。为了保证高可用，NameServer自身也可以做集群的部署。它的作用有点像Eureka或者Redis的Sentinel。
也就是说，Broker会在NameServer上注册自己，Porducer和Consumer用NameServer来发现Broker。
每个Broker节点在启动时，都会根据配置遍历NameServer列表。
与每个NameServer建立TCP长连接，注册自己的信息，之后每隔30s发送心跳信息。
如果Broker挂掉了，不发送心跳了，NameServer怎么发现呢？
所以，除了主从注册，还有定时探活。每个NameServer每隔10s检查一下各个Broker的最近一次心跳时间，如果发现某个Broker超过120s都没发送心跳，就认为这个Broker已经挂掉了，会将其从路由信息里移除。
2、放弃理由
既然，Nameserver的作用也是用来管理Broker的服务的，也就是服务注册与发现，那为什么不直接用Zookeeper、Consul、etcd、Eureka这样的组件呢？
实际上在RocketMQ的早期版本中，跟Kafka一样也是用Zookeeper实现服务管理的，但到RokcetMQ开源的时候去掉了ZooKeeper依赖，转而采用自己的NameServer。
因为，RocketMQ是一个保持最终一致性的架构设计，它架构决定了它只需要一个轻量级的元数据服务器就足够了，而不需要像Zookeeper这样的强一致性解决方案。不依赖另一个中间件，从而减少整体维护成本。
根据著名的CAP理论，在一致性(Consistency)、可用性(Availability)、分区容错性(Partiton Tolerance)中，Zookeeper实现了CP，而NameServer选择了AP，放弃了实时一致性。
以上就是我对RocketMQ为什么要放弃Zookeeper的理解！
我是被编程耽误的文艺Tom，关注我，面试不再难！
