深入分析zookeeper（理论加实战）

文件系统顾名思义就是一个多层级的类似咱们电脑上的文件夹之类的数据结构，如下图所示：
zookeeper数据结构
每个子目录项如 NameService 都被称作为 znode(这里NameService属于目录节点)，和平常使用的文件夹一样，我们能够自由的增加、删除znode，在一个znode下增加、删除子znode。当然znode有自己独特的地方，也就是它的这些znode可以用来设置关联的数据，具体就是只有文件节点可以存放数据而目录节点不可以。同时为了保证高吞吐低延迟，zookeeper需要在内存中维护这个树状的目录结构，因此zookeeper不能存放大量的数据，每个节点的存放数据上限是1M。

zookeeper一共有四个类型的znode节点：

PERSISTENT 持久化节点

持久化节点是指在节点创建后，就一直存在，直到有删除操作来主动清除这个节点。否则不会因为创建该节点的客户端会话失效而消失。
PERSISTENT_SEQUENTIAL 持久顺序节点

持久顺序节点和持久化节点的基本特征是一致的。只是它额外的特性是：在zookeeper中，每个父节点会为他的第一级子节点维护一份时序，会记录每个子节点创建的先后顺序。基于这个特性，我们在创建子节点的时候，可以设置这个属性，这样在创建节点过程中，zookeeper会自动为这个节点名加上一个数字后缀作为新的节点名。这个数字后缀的范围是整型的最大值。比如在创建节点的时候只需要传入节点 “csdn_”，然后zookeeper自动会给”csdn_”后面补充数字。
EPHEMERAL 临时节点

和持久节点不同的是，临时节点的生命周期和客户端会话绑定。也就是说，如果客户端会话失效，那么这个节点就会自动被清除掉。（注意：这里提到的是会话失效，而非连接断开）另外，在临时节点下面不能创建子节点。这里还要注意一件事，就是当你客户端会话失效后，所产生的节点并不是瞬间就消失了，而是需要一段时间，大概是 10 秒以内。例如，本机操作生成节点，在服务器端用命令来查看当前的节点数目，你会发现客户端已经 stop，但是产生的节点还在。
EPHEMERAL_SEQUENTIAL 临时自动编号节点

属于带有顺序的临时节点，在客户端会话结束后节点就消失。

1.2、监听通知机制

简单来说就是客户端会对某个znode建立一个watcher事件，当这个znode发生了变化，比如数据改变、删除、子目录节点新增删除等情况时，客户端会收到zookeeper的通知，然后好处就是客户端就可以根据znode的变化来调整对应的业务情况。

二、实际生产中的作用

2.1、配置管理

通过前面介绍zookeeper的数据结构，相信很多人首先想到的就是它可以解决各种需要同步的麻烦的配置。比如数据库连接等。一般我们都是使用配置文件的方式，在代码中引入这些配置文件。当我们只有一种配置，只有一台服务器，并且不经常修改的时候，使用配置文件是一个很好的做法，但是如果我们配置非常多，有很多服务器都需要这个配置，这时使用配置文件就不是个好主意了。这个时候往往需要寻找一种集中管理配置的方法，就是希望我们在这个集中的地方修改了配置，然后所有使用这个配置的服务器上的服务都可以获得变更。

Zookeeper就是这种服务，它使用Zab这种一致性协议来提供一致性。

其实有很多开源项目都是使用 Zookeeper 来维护配置，比如在HBase中，本来内置的就有zookeeper，也可以使用外部的zookeeper。它的客户端就是通过连接一个Zookeeper，获得必要的 HBase 集群的配置信息，然后才可以进一步操作。

再比如实际生产中必不可少的开源的消息队列Kafka，也是使用 Zookeeper来维护broker的信息。还有Alibaba开源的SOA框架Dubbo中也是通过使用Zookeeper管理一些配置来实现服务治理的。

2.2、统一命名服务

统一命名服务比较容易理解，就像DNS一样，由于我们访问网络时直接输入IP地址非常不友好（记不住），因此诞生了域名，但是域名也不是每台计算机都保存的，我们不可能在每台计算机上保存全世界所有的域名和IP的映射。因此DNS诞生了，我们只需要固定的访问一个大家都熟知的服务器（根服务器），它就会告诉你这个域名对应的 IP 是什么（根服务器一般会根据域名的构成来指向一级、二级服务器层层去寻找这个域名对应的IP）。

在我们的应用中也会存在很多这类问题，特别是在我们的服务特别多的时候，如果我们在本地保存服务的地址的时候将非常不方便，但是如果我们只需要访问一个大家都熟知的访问点，然后从这里提供统一的入口，那么维护起来将方便得多了。

2.3、分布式锁

zookeeper本质上是一个分布式协调服务。因此我们可以利用zookeeper来协调多个分布式进程之间的活动。比如在一个分布式环境中，为了提高可靠性，我们的集群的每台服务器上都部署着同样的服务。但是，一件事情如果集群中的每个服务器都进行的话，那相互之间就要协调，编程起来将非常复杂。而如果我们只让一个服务进行操作，那又存在单点故障风险。

因此通常情况下我们的做法就是使用分布式锁，在某个时刻只让一个服务去干活，当这台服务出故障的时候把锁释放掉，并立即fail over到别的服务。这在很多分布式系统中都是这么做，这种设计有一个更好听的名字叫 Leader Election(leader 选举)。比如 HBase 的 Master 就是采用这种机制。但要注意的是分布式锁跟同一个进程的锁还是有区别的，所以使用的时候要比同一个进程里的锁更谨慎的使用。

2.4、集群管理等服务

在现在大数据的场景及微服务的场景下，由于是分布式的集群，经常会由于各种原因，比如硬件故障，软件故障，网络问题等，导致部分节点进进出出。有新的节点加入进来，也有老的节点退出集群。这个时候，集群中其他机器需要感知到这种变化，然后根据这种变化做出对应的决策。

比如我们是一个分布式存储系统，有一个中央控制节点负责存储的分配，当有新的存储进来的时候我们要根据现在集群目前的状态来分配存储节点。这个时候我们就需要动态感知到集群目前的状态。

再比如一个分布式的 SOA 架构中，服务是一个集群提供的，当消费者访问某个服务时，就需要采用某种机制发现现在有哪些节点可以提供该服务(这也称之为服务发现，比如Alibaba开源的SOA框架Dubbo就采用了Zookeeper作为服务发现的底层机制)。还有常用的Kafka 队列就采用了Zookeeper作为Cosnumer的上下线管理。

三、纸上得来总觉浅，zookeeper实战

3.1、使用docker安装zookeeper最新版

为啥使用docker安装呢？因为我个人觉得学习一门技术主要是要掌握它的原理、架构、以及具体的使用，而不是纠结于安装配置。（其实是因为懒。。。。）

好，docker不管在任何系统下安装任何东西步骤都一样：

3.1.1、下载zookeeper镜像

docker pull zookeeper

下载zookeeper镜像

3.1.2、启动容器并暴露2181端口

docker run --privileged=true -d --name zookeeper --publish 2181:2181  -d zookeeper:latest

启动容器

3.1.3、查看容器状态

docker ps

容器状态
可以看到，我这个zookeeper已经连续启动19个小时了（这篇文章比较费时间）。

3.1.4、进行一些基本操作

以bin/bash进入到容器中
```
docker exec -it 60d /bin/bash
```
以本地2181客户端连接zk，进行命令行界面
```
./zkCli.sh -server 127.0.0.1:2181
```
进行基本的增删改查

3.2、使用idea配置zookeeper plugin

强大的idea提供了一个zookeeper的插件，可以用来连接zookeeper及查看内容。

windows：左上角File------>Settings------>Plugins
Mac：左上角Intellij IDEA------>Preserences------>Plugins

在plugin里输入zoo，然后选择第二个zoolytic并点击install进行安装（第一个zookeeper在新版idea里已经不能用了，已踩坑。。。。），如下图：
安装zoolytic插件

安装后重启idea

然后在点击右上角zoolytic，打开后，点击➕号，然后在弹框中输入localhost:2181，最后点击ok，如下图：
配置zoolytic

在列表里点击刚才的localhost:2181，展开后，点击connect，如下图：
连接zookeeper

然后就会出现咱们刚才新增的csdn节点，并且这个节点上的数据qq_26803795（这是我的csdn ID）也会出现，如下图：
连接zookeeper成功

感兴趣的可以好好的把玩一番。

且听_风吟

发布了103 篇原创文章 · 获赞 173 · 访问量 23万+

私信关注