【大白话系列】-- zookeeper

一、Zookeeper是什么？

ZooKeeper主要服务于分布式系统，可以看做一个分布式协调系统，主要是用来解决分布式应用中经常遇到的一些数据管理问题，如：统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。

上面的解释有点抽象，简单来说zookeeper = 文件系统+监听通知机制。

二、Zookeeper数据结构

ZooKeeper的数据结构，跟Unix文件系统非常类似，可以看做是一颗树，每个节点叫做ZNode。每一个节点可以通过路径来标识，结构图如下：

​

ZooKeeper的节点我们称之为Znode，每个节点都可以保存数据，每个节点都有版本，Znode分为两种类型：

• 短暂/临时(Ephemeral)：当客户端和服务端断开连接后，所创建的Znode(节点)会自动删除

• 持久(Persistent)：当客户端和服务端断开连接后，所创建的Znode(节点)不会删除

三、监听通知机制

上面已经简单介绍了Zookeeper的数据结构了，它还要配合监听器才能做到那么多功能。

客户端注册监听它关心的目录节点，当目录节点发生变化（数据改变、被删除、子目录节点增加删除）时，zookeeper会通知客户端。

常见的监听场景有以下两项：

• 监听Znode节点的数据变化

• 监听子节点的增减变化

就这么简单，通过监听+Znode节点(持久/短暂[临时])，ZooKeeper就可以玩出这么多花样了。

四、Zookeeper的功能

4.1 统一配置管理

我们自己做项目时用到的配置比如数据库配置等，我们都是写死在项目里面的。如果需要更改，那么也是的修改配置文件然后再投产上去，那么问题来了，如果做集群的呢。有100台机器，这时候做修改那就太不切实际了；那么就需要用到统一配置管理。

解决思路：

• 把公共配置抽取出来：公共配置抽取存放于zookeeper中并落地数据库

• 对公共配置进行维护：对公共配置修改后发布到zookeeper中并落地数据库

• 修改公共配置后应用不需要重新部署：对应用开启配置实时监听，zookeeper配置文件一旦被修改，应用可实时监听到并获取

4.2 统一命名服务

zookeeper的命名服务功能主要是根据指定名字来获取资源或服务的地址，提供者等信息，利用其znode的特点和watcher机制，将其作为动态注册和获取服务信息的配置中心，统一管理服务名称和其对应的服务器列表信息，我们能够近乎实时地感知到后端服务器的状态(上线、下线、宕机)。

举例来说，B服务部署在六台服务器上，存在六个完全不同的ip地址，同时B服务本身提供一个dubbo接口对外，此时有个A服务需要调用此接口，如果提供某一台服务器的ip，则存在该服务器宕机情况下接口不可用的情况，再切换ip就会影响服务的正常使用。此时，可以使用zookeeper作为注册中心，B服务的六台服务在指定znode下创建子节点，而A服务调用之前先通过指定znode的路径获取B服务的任意子节点中的ip信息，然后通过ip访问。同时zookeeper动态维护这部分节点，定时利用心跳请求检查B服务的服务器状态，一旦发现某服务器无反馈，就删除节点，防止被A服务获取调用。

4.3 分布式锁

当 A，B，C三个系统同时去访问 /lock 节点时：

• Zookeeper访问的时候会创建带顺序号的临时/短暂(EPHEMERAL_SEQUENTIAL)节点，比如，系统A创建了id_000000节点，系统B创建了id_000002节点，系统C创建了id_000001节点。

• 接着，拿到/locks节点下的所有子节点(id_000000,id_000001,id_000002)，判断自己创建的是不是最小的那个节点。

• 如果是，则拿到锁。访问完毕则释放锁：执行完操作后，把创建的节点给删掉；如果不是，则监听比自己要小1的节点变化。