为什么需要 Zookeeper

Posted by ZY on June 5, 2019

很多中间件,比如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可能会更合适。