看完这篇文章告诉你RocketMQ为什么要放弃Zookeeper？

一位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，关注我，面试不再难！

最后， 6/7/8月份资料文档已整理，包含如下↓（还在持续更新中！）：

①100道最新大厂经典面试题解析资料文档！

②15万+字Java面试题解析和配套答案！

③从应届生到高级开发都适用的简历模板！

④从入门到精通的架构师学习路线图！

有需要的小伙伴可扫描下方二维码免费拿完整版！

↓     ↓     ↓