为什么需要 Zookeeper

为什么需要 Zookeeper

很多中间件，比如 Kafka、Hadoop、HBase，都用到了 Zookeeper，于是很多人就会去了解这个 Zookeeper 到底是什么，为什么它在分布式系统里有着如此无可替代的地位。

在踩了很多坑之后，我决定来回答下这个问题。

其实学任何一项技术，首先都要弄明白，为什么需要这项技术。

为什么需要 Zookeeper

正经点来回答，就是我们需要一个用起来像单机但是又比单机更可靠的东西。

下面开始不正经的回答。

一个团队里面，需要一个 leader，leader 是干嘛用的？管理什么的咱不说，就说如果外面的人，想问关于这个团队的一切事情，首先就会去找这个 leader，因为他知道的最多，而且他的回答最靠谱。

比如产品经理小饼过来要人，作为 leader，老吕发现小耀最近没有项目安排，于是把小耀安排给了小饼的项目；

过了一会，另一个产品小西也过来要人，老吕发现刚刚把小耀安排走了，已经没人，于是就跟小西说，人都被你们产品要走了，你们产品自己去协调去。

如果老吕这时候忘了小耀已经被安排走了，把小耀也分配给小西，那到时两个产品就要打架了。

这就是 leader 在团队里的协调作用。

同样的，在分布式系统中，也需要这样的协调者，来回答系统下各个节点的提问。

比如我们搭建了一个数据库集群，里面有一个 Master，多个 Slave，Master 负责写，Slave 只读，我们需要一个系统，来告诉客户端，哪个是 Master。

有人说，很简单，我们把这个信息写到一个 Java 服务器的内存就好了，用一个 map，key:master，value:master 机器对应的 ip

但是别忘了，这是个单机，一旦这个机器挂了，就完蛋了，客户端将无法知道到底哪个是 Master。

于是开始进行拓展，拓展成三台服务器的集群。

这下问题来了，如果我在其中一台机器修改了 Master 的 ip，数据还没同步到其他两台，这时候客户端过来查询，如果查询走的是另外两台还没有同步到的机器，就会拿到旧的数据，往已经不是 master 的机器写数据。

所以我们需要这个存储 master 信息的服务器集群，做到当信息还没同步完成时，不对外提供服务，阻塞住查询请求，等待信息同步完成，再给查询请求返回信息。

这样一来，请求就会变慢，变慢的时间取决于什么时候这个集群认为数据同步完成了。

假设这个数据同步时间无限短，比如是 1 微妙，可以忽略不计，那么其实这个分布式系统，就和我们之前单机的系统一样，既可以保证数据的一致，又让外界感知不到请求阻塞，同时，又不会有 SPOF（Single Point of Failure）的风险，即不会因为一台机器的宕机，导致整个系统不可用。

这样的系统，就叫分布式协调系统。谁能把这个数据同步的时间压缩的更短，谁的请求响应就更快，谁就更出色，Zookeeper 就是其中的佼佼者。

它用起来像单机一样，能够提供数据强一致性，但是其实背后是多台机器构成的集群，不会有 SPOF。

其实就是 CAP 理论中，满足 CP，不满足 A 的那类分布式系统。

如果把各个节点比作各种小动物，那协调者，就是动物园管理员，这也就是 Zookeeper 名称的由来了，从名字就可以看出来它的雄心勃勃。

讲完了上面这些，现在再来看官网这句话，就很能理解了：

ZooKeeper: A Distributed Coordination Service for Distributed Applications

当然还有这句：

而以往的很多 ZK 教程，上来就是 “Zookeeper 是开源的分布式应用协调系统”blabla，很多像我这样的小年轻看到就会很费解，到底什么是分布式协调，为什么分布式就需要协调 …

上面只是回答了我自己提出的问题，为什么需要 Zookeeper，或者说，为什么需要分布式协调系统，如果想进一步学习 ZK，你还需要了解下 Zookeeper 的内部实现原理。

比如 ZK 的宏观结构：

到 ZK 的微观：

再到 ZK 是如何实现高性能的强一致的，即 ZAB 协议的原理，很多教程上来就开始介绍 ZAB 协议，很容易让人一头雾水，不知道为什么需要这样一个分布式一致性协议，有了上述介绍的背景，就好懂许多。

当然你还可以比较一下最近几年很火的 etcd 跟 ZK 的差别。

最后推荐两份 ZK 的学习资源：

• ZK 官网
• 《从 Paxos 到 Zookeeper》

== updated on 2019/06/14 ==

看完这篇文章之后，读者可能还有疑问，为什么就一定要用 Zookeeper，我用其他的也可以呀。

这点是我的锅，在写这篇文章时，我还是把 Zookeeper 等价成了分布式协调服务，把为什么需要 Zookeeper 这个问题，等价成了 「为什么需要分布式协调服务」，其实这样是有问题的，因为想做分布式协调服务，不一定需要 ZK 这种 CP 的中间件，用 AP 也可以。

而到底是用 AP 还是 CP，是由业务决定的。

比如你是一个文件上传的服务器，用户可能上传几个 g 的文件，那么如果用一个 AP 的系统，拿到的可能是不可用的节点，这样返回给客户端重试，客户端肯定得疯掉，这时候就需要用 CP。

而像 rpc 调用，调用失败了重试就好，成本代价都不大，这时候，用 AP 可能会更合适。

公众号：柳树的絮叨叨，欢迎关注！

柳树的絮叨叨

写下你的评论...

nginx 这些 reverse proxy 不可以做同样的事情吗？nginx 也可以告诉 client 哪个是 master，哪个是 slave，为什么还需要 zookeeper 呢？

很好的问题，其实分布式协调服务，很多中间件都可以做，但是有的是 AP 的，有的是 CP 的，ZK 属于 CP，而到底是用 AP 还是 CP，是由业务决定的，比如你是一个文件上传的服务器，用户可能上传几个 g 的文件，那么如果用一个 AP 的系统，拿到的可能是不可用的节点，这样返回给客户端重试，客户端肯定得疯掉，这时候就需要用 CP；而像 rpc 调用，调用失败了重试就好，成本代价都不大，这时候，用 AP 可能会更合适。

什么是 AP 什么是 CP

我觉得（个人观点），zk 也就是它的树形结构可以让它获取子节点，还有点用处，其他的，几乎被后来者秒杀（这个说的严重了点，但总之比 zk 好点）！

比如你是一个文件上传的服务器，用户可能上传几个 g 的文件，那么如果用一个 AP 的系统，拿到的可能是不可用的节点，这样返回给客户端重试，客户端肯定得疯掉，这时候就需要用 CP。

这个场景是不是举错例子了，节点不可用所以更需要 AP 啊，数据不一致才需要 CP 啊。

比如现在 zk 里存的两个节点的 ip，分别是 ipA ipB，现在 zk 发现 ipB 不可用了，于是把 ipB 删掉，假设 ZK 是 AP 的，无法保存数据一致性，并且有两台 ZK 的机器，其中一台已经把 ipB 删掉了，另一台没删，这时候客户端过来拿 ip，有可能拿到不可用的 ipB. 这里的节点不可用里的不可用，和 AP 的 A 可用性，指的不是一个对象。

所以你说的 zk 的 AP 还是 CP 是吧，我理解成服务的 CAP 了。

我觉得这个科普可以再深入一丢丢。

比如 ZK 在每次重新选举后通过 generation 进行的类版本控制。

在有 ZK 小宝宝挂掉之后的重新选举的通信和将 topic 和 slave 等信息给新 Leader 的再分配这些都可以讲一讲，不然这个看下来没有什么干货。

BTW：我了解的 ZK 的起名故事比你讲的多个了前因的样纸。

制造问题，希望不必解决问题多吧

答主再总结下 etcd 和 ZK 的区别？为啥 k8s 现在都用 etcd 管理各种状态相关的？

还没仔细研究，只知道在性能测试上 etcd 已经超过了 ZK，最主要的应该是一致性算法的优势，zk 基于从 paxos 改进而来的 zab，而 etcd 基于和 paxos 十分不同的 raft，这两个算法的细节我还没研究过，不过 zk 的成功说明了站在巨人（paxos）的肩膀上，可以看的更远，而 etcd 的成功，则说明了有时打破固定思维，另辟蹊径的创新也能带来成功。另外 etcd 采用没有垃圾回收机制的 go 语言来实现，相比 zk 用的 java，也可能给性能带来一些优势吧 ps: 有赞现在也在全面用 etcd 取代 zk

etcd 是 k8s 的官方用的，但是 golang 也有 GC：https://blog.golang.org/ismmkeynote，只不过相对而言 golang 的各种 goroutine 和内存开销比起 Java 好很多。不过 raft 和 paxos 的区别确实值得好好研究

网络天然的有延迟 客户端重试这个坑怎么都绕不过去的

如此简单入门的一篇文章解决了我多年的疑惑！

都说 zk 是一个处理分布式一致性的解决方案，那他是如何解决一致性问题的呢？你的文章强调了它协调的功能的吧

AP 最终一致性? CP 强一致性?

AP 不是可用吗？为啥会出现不可用的节点？

但 zookeeper 是遵循的 CP 啊。。。强调一致性的话会产生不可用的节点

写的好，通俗易懂！

解释得非常到位，学习了。
最后一部分应该有点问题。文件服务器应该就是遵循 AP 才对，不然文件传着传着服务就挂了，又要重新传，岂不是要崩溃。

我的关注点比较奇怪，mysql 集群中需要使用到 zookeeper 吗

我从 zk 的未授权访问漏洞，来看 zk 是个啥东西，看了那么多评论 感觉做安全的知道这是个啥就行，至于与 etcd 相比 我就不看了 哈哈 感谢作者的分享

正如作者所说，当我想学习一种从未了解过的知识或者技术时，首先会想去了解我们为什么需要它？它到底解决了什么样的课题？痛点？

相信很多人都有过这种感受，很大比例的书籍或文档，都没有这样的说明，包括大学让我挂科的高等数学，我曾经就不知道为什么要学它 [捂脸]

感谢作者带来的简单易懂的啰嗦文 [调皮]