zookeeper对我们开发人员来说并不陌生，它在分布式系统中它占据了重要的地位。但是随着互联网的不断发展，现在慢慢的很多的大厂弃用zookeeper了，下面我们来聊聊zookeeper不受待见的原因。

1、认识zookeeper

zookeeper是开放源码的分布式应用程序协调服务，是Google的Chubby的一个开源的实现。它是一个为分布式应用提供一致性服务的软件，我们经常使用的是zookeeper提供功能如下所示：

（1）zookeeper注册中心：

（2）zookeeper的配置中心

在我们熟悉的中间件中，如dubbo使用zookeeper作为注册中心，kafka早期的版本使用zookeeper作为配置中心，还有RocketMQ等等中间件。

2、盘点zookeeper不受待见原因

（1）CP机制

zookeeper设计的初衷就是保证集群节点数据之间的强一致性，也就是主节点和从节点之间的数据部不一致的情况下整个zookeeper集群的服务是不可用的，换句话将zookeeper为了保证节点数据的一致性进而牺牲了可用性。但是在某些场景下如提供服务发现的能力的时候，虽然数据获取到的不是最新的数据但是可以继续保持服务通信，有时候还是可以容忍的，不一定要牺牲可用性。这种场景下使用zookeeper做服务发现就不合适了。

（2）主从节点直接数据阻塞同步

zookeeper主节点和从节点同步数据的时候，主节点给从节点发送同步请求，从节点接受到请求之后处理完成要给主节点一个响应，如果主节点没有接受到响应则认为本次数据同步失败。由于网络原因存在一定的延迟，加上zookeeper本身是CP的机制，那么在高并发下就存在一定的性能问题。

（3）状态的变更会记录日志

zookeeper在设计的时候要求就是高可靠的中间件，其主和从之间的同步都会记录一个持久化的日志，像服务发现的场景是不关心中间的状态变化的，我们只是希望可以实时的获取服务列表数据就可以了，如果记录状态变更日志就损耗的一定的性能。

（4）健康检查机制

zookeeper将服务的健康检测绑定在zookeeper对于session的健康检测，换句话讲就是绑定在TCP长连接的探活上，其实并没有对服务的可用性做检测的，也就是即使服务下线了zookeeper的健康检查是检测不了，所以zookeeper的检测对实际的业务没有什么帮助的。

随着互联网技术的不断发展，zookeeper这些机制不适用于一些场景了，所以人们开始寻找一些替代方案来替代zookeeper，但是也不是说zookeeper直接就淘汰了，像数据的订阅/发布、选举master、分布式锁等业务场景下zookeeper还是很适用的。

总结：

（1）zookeeper是强一致性的，但是在一些场景下我们更重视可用性。

（2）zookeeper主从同步数据的时候，从节点必须给主节点响应才算数据同步成功，但是由于网络延迟等原因，就造成了zookeeper在高并发下存在性能问题。

（3）zookeeper的状态变更会记录日志，但是在某些应用场景下是不需要记录这些日志的，这也就无形中损耗了zookeeper的性能。

（4）zookeeper的健康检查不检查服务的可用性，对实际的业务是没有帮助的。