ZooKeeper学习（一）了解ZooKeeper

一、什么是ZooKeeper

• ZooKeeper主要服务于分布式系统，可以用ZooKeeper来做：统一配置管理、统一命名服务、分布式锁、集群管理。
• 使用分布式系统就无法避免对节点管理的问题(需要实时感知节点的状态、对节点进行统一管理等等)，而由于这些问题处理起来可能相对麻烦和提高了系统的复杂性，ZooKeeper作为一个能够通用解决这些问题的中间件就应运而生了。

二、ZooKeeper的数据结构

　　ZooKeeper和Redis一样，也是C/S结构(分成客户端和服务端)。

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

 　　如图所示，Znode分为两种类型：

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

三、ZooKeeper的监听器

　　前面了解了，我们可以通过ZooKeeper去通用的实现很多功能，那么实现原理是怎么样的呢？ZooKeeper配合了监听器，才能够做那么多事的。

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

• 监听Znode节点的数据变化
• 监听子节点的增减变化

 　　通过监听+Znode节点(持久/短暂[临时])，ZooKeeper就可以解决很多分布式系统的问题了。

统一配置管理

　　比如我们现在有三个系统A、B、C，他们有三份配置，分别是ASystem.yml、BSystem.yml、CSystem.yml，然后，这三份配置又非常类似，很多的配置项几乎都一样。

• 痛点：如果我们要改变其中一份配置项的信息，很可能其他两份都要改。并且，改变了配置项的信息很可能就要重启系统

　　于是，我们希望把ASystem.yml、BSystem.yml、CSystem.yml相同的配置项抽取出来成一份公用的配置common.yml，并且即便common.yml改了，也不需要系统A、B、C重启。　　

 　　做法：我们可以将common.yml这份配置放在ZooKeeper的Znode节点中，系统A、B、C监听着这个Znode节点有无变更，如果变更了，及时响应。

　　代码参考：基于zookeeper实现统一配置管理

统一命名服务

　　统一命名服务的理解其实跟域名一样，是我们为这某一部分的资源给它取一个名字，别人通过这个名字就可以拿到对应的资源。

　　例如一个域名可能对应多个IP地址的资源信息，也可能部署多个服务器集群，那么别人访问的时候，不是直接通过IP去访问对应的主机，而是通过一个域名就可以了。

　　例如：https://www.cnblogs.com/riches/对应了4台服务器：

• 192.168.1.1
• 192.168.1.2
• 192.168.1.3
• 192.168.1.4

 分布式锁

　　我们可以使用ZooKeeper来实现分布式锁，那是怎么做的呢？？下面来看看：系统A、B、C都去访问/locks节点

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

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

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

集群管理

　　还是以我们三个系统A、B、C为例，在ZooKeeper中创建临时节点即可：

　　只要系统A挂了，那/groupMember/A这个节点就会删除，通过监听groupMember下的子节点，系统B和C就能够感知到系统A已经挂了。(新增也是同理)

　　除了能够感知节点的上下线变化，ZooKeeper还可以实现动态选举Master的功能。(如果集群是主从架构模式下)

　　原理：如果想要实现动态选举Master的功能，Znode节点的类型是带序号的临时节点就好了。

• Zookeeper会每次选举最小编号的作为Master，如果Master挂了，自然对应的Znode节点就会删除。然后让新的最小编号作为Master，这样就可以实现动态选举的功能了。

 

参考资料：

• 什么是ZooKeeper？（特此感谢！）