重温一下ZooKeeper关键点，虽然我不是很喜欢它

程序员文章站 2022-07-03 14:56:13

不羡鸳鸯不羡仙，一行代码调半天。原创：小姐姐味道（微信公众号ID：xjjdog），欢迎分享，转载请保留出处。我个人是非常不喜欢这个组件的，因为它的代码虐过我。引入一个Netty就可以轻易......

不羡鸳鸯不羡仙，一行代码调半天。原创：小姐姐味道（微信公众号ID：xjjdog），欢迎分享，转载请保留出处。

我个人是非常不喜欢这个组件的，因为它的代码虐过我。引入一个Netty就可以轻易实现的网络功能，非要自己在代码里抠 NIO，代码让人看的云里雾里。

另外，Zookeeper的扩容和缩容，也曾经让我的团队吃过亏，丢了不少数据。用不好的东西，对它印象就不好，所幸它老了，我也很少用它了。

关于它的客户端使用问题，看xjjdog这篇文章就可以了。

1. 什么是 ZooKeeper

重温一下ZooKeeper关键点，虽然我不是很喜欢它

ZooKeeper是一个分布式的协调系统，应用非常广泛。它原是 Hadoop 的一个子项目，目前是 Apache 基金会的*项目。像我们常用的微服务框架 SpringCloud、Dubbo 等，就可以采用 Zookeeper 作为它的注册中心。

除了作为注册中心，它还有非常多的使用场景，包括：命名服务、分布式协调/通知、选举、分布式锁、分布式队列、负载均衡、配置服务等。

既然 ZooKeeper 谈到自己是一个分布式系统，那它就离不开 CAP 理论，

CAP理论，指的是在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可兼得。下面介绍一下这三个概念：

重温一下ZooKeeper关键点，虽然我不是很喜欢它

一致性（C）：在分布式系统的不同节点或者备份中，同一时刻是否是一样的值。比如 MySQL 的主从节点，由于 binlog 复制存在时差，可能在从机上读到的数据和在主机上的不一致。
可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。
分区容忍性（P）：集群的分区数量多了，必然会在一致性和可用性上有一些问题。以实际效果而言，分区相当于对通信的时限要求。系统如果不能在一定时间内达成数据一致性，就意味着发生了分区的情况。

分布式系统，因为P是必须的，大多会在C和A之间做出选择。而 ZooKeeper ，就是一个倾向于 CP 的，强一致性的分布式系统。

所以我们要记住这一点，ZooKeeper 的一致性特别强，对于数据一致性要求较高的场景，ZooKeeper都可以有它的用武之地。

同时，我们也应该认识到。ZooKeeper 不能保证每次服务请求的可用性，在极端环境下，ZooKeeper可能会丢弃一些请求，消费者程序需要重新请求才能获得结果。

重温一下ZooKeeper关键点，虽然我不是很喜欢它

从官方的架构图就可以看到，不同的客户端，连接到 ZooKeeper 集群中的不同机器，所看到的数据，都是一致的，这也是它强一致性的由来。

像 Spring Cloud、Dubbo 等服务节点的信息，比如机器列表等，一般数据集都比较小，但是一致性却要求非常的高，而且数据经常会发生变动，这是非常适合 ZooKeeper 的一种场景。

通过将这样的信息发布到 ZooKeeper上，那么这些数据一旦有变动，应用节点可以获得获取数据的一致视图。

ZooKeeper有Watcher注册与异步通知机制，可以在不同的服务节点，甚至是不同的系统间进行协调。这非常像传统消息队列中的 Pub/Sub 机制，但由于 ZooKeeper的实时性，加上数据强一致性，使得数据的分发变的非常可靠。

所谓的选举，就是在众多的服务节点中，选举出一个具有最终决定权的领导，这在服务集群中，一般称为Master。比如，一项服务需要对外暴露接口，但是要保证这个服务的高可用。当正在服务的节点当机之后，需要采用选举功能，从备份的机制中，选择出一台来，继续进行服务。剩余的机器，则称为这台被选举机器的备份。

分布式锁，是为了协调分布式环境下的共享资源而设定的锁。比如，你有一个定时服务有两个节点，但要求在执行时只有一个节点进行业务逻辑的计算。这时候，任务就变成了共享资源，在获取任务的时候，就可以采用互斥的手段来保证彼此之间的干扰，保证一致性。

ZooKeeper 也可以实现分布式队列，比如对一批任务的执行，先处理完前面的任务，再处理后面的任务。这个时候，就可以将任务信息存放到 ZooKeeper中。

它与消息队列的队列概念相似，但比较适合小批量的、有严格顺序的任务。

ZooKeeper 是基于 ZAB 协议构建的，这个协议和 Paxos 协议有些相似。由于这些协议太复杂了，后续又有了基于 Raft 协议的 Etcd 和 Consul。ZooKeeper 是基于Java语言开发的，而后两者是使用 Golang 开发的。

Etcd 和 Consul 作为后起之秀，在功能和性能方面要优于 ZooKeeper，它们都是 CP 的系统，使用上区别不大。

在 Java 生态里，使用 ZooKeeper 更多一些。考虑到周边建设和产品生态问题，在Java 企业级应用中， ZooKeeper 的作用还非常大。

哪一天我再用它，那绝对只是工作需要，而不是兴趣使然。这也证明了我对它根本就不精通，虽然也买书看了一点点，但千万不要留言问我相关技术问题。

作者简介：小姐姐味道 (xjjdog)，一个不允许程序员走弯路的公众号。聚焦基础架构和Linux。十年架构，日百亿流量，与你探讨高并发世界，给你不一样的味道。我的个人微信xjjdog0，欢迎添加好友，进一步交流。

后台回复“加群”，带你进入高手如云交流群