Zookeeper(一)

关于Zookpper，他是一个管家一样的角色，起协调作用。我们先来说一下他的产生背景，当我们的单体架构转变到分布式架构的时候，多个服务之间是怎么协调的呢？这里的协调包括了服务的上线和宕机，应用如何知道多个服务的ip地址以及ip地址的实时更新？如何保证并发请求的幂等性？还有每天的定时任务分配给那一个结点来执行？RPC远程调用的时候，怎么样发现服务的ip？这些都是Zookeeper要解决的问题。

Zookeeper可以实现的功能包括了分布式配置，分布式锁，分布式服务发现，心跳检测等等，在实现这些之前，我们先来说一说Zookeeper的数据结构，以及核心的api，这样才是知道他的强大的功能从何而来。

先来说他的数据结构，Zookeeper的数据结构和文件系统十分相似，但他没有文件和文件夹之分，而是统一叫做ZNode结点，每个ZNode是一个数据结构他包含了自己所在的唯一路径Path，他下面的子结点childNode，他的结点类型Type，他的状态属性state，ZNode的所有的功能都是依靠操作这些数据结构来实现的。

先来说说ZNode的基本功能。每个ZNode结点有两个功能，一是可以保存数据，二是可以挂载子结点，是一个树形结构。因为他的每个结点都能保存数据，所以我们可以将每个服务的ip地址保存于此，又因为他能挂载子结点，所以我们可以对服务进行很好的分类管理。

除此之外，他还有一些高级特性是依赖ZNode的数据结构Type的。ZNode通过Type值被定义了很多类型，他包括持久化结点，临时结点，序号结点，非序号结点。我们一个一个来讨论。首先是持久结点，他是我们在创建结点时的默认类型，很显然他会一直存在，不会主动删除，哪怕创建他的session会话已经和Zookeeper断开了，他也是存在的，他就比较适合于用来做每个服务ZNode的父结点。与之相对的是临时结点，他在创建他的Session断开后就会被销毁，而且，他只能用来做叶子结点，不能有自己的子结点，显然他适合于做服务的注册，每个服务上线时就会在Zookeeper中在对应服务的持久化结点下创建临时节点，临时节点的数据就会存服务的ip地址。当服务断开后，临时节点就会被销毁，对应服务的下线，但是很显然有个问题，就是分布式系统中，我们有多个服务都要注册在一个持久节点下，他们之间是不能够重名的，所以就要靠临时序号节点了，他在创建节点时，节点的名称后面会自带带上序号，就类似于数据库的自增id，但是是从1开始的，因为0代表的是父节点，而且，节点删除后，序号也不会改变，这一点和数据库的自增id又相同，他就解决了叶子节点重名的问题，除此之外，他的序号还可以用来实现分布式锁。当然仅仅通过临时序号节点仅仅解决了服务的上线和下线，但没办法进行通知，实现分布式的数据一致性，他涉及到之后要说的Zookeeper的监听机制，之后再说。

还有就是ZNode的Stat属性，他里面记录了节点的一些重要信息，包括节点的创建时间，创建节点的事务ID，修改节点的事务ID，他们的作用我暂时还没懂。还有一些信息就是ephemeralOwner，如果他为空，说明他不属于Session，所以是永久节点，相反，不为空则和Session相关联，是临时节点。除此之外还有cversion版本号，dataversion数据的版本号，aclversion权限的版本号，numChildren子节点的数量。

我们再来说说为了实现服务通知而产生的监听机制，每个节点可以监听一个节点的变化，所谓的变化分为该节点的数据的变化，该节点的子节点的数量变化，和该节点的属性的变化，他们都是隔离的，需要用不同的命令来控制，比如ls -w用来监听子节点的数量变化，用get -w监听节点数据变化，用stat -w监听节点属性变化。他是Zookeeper的核心功能，有了他，当节点发现变化时，就会通知其他节点来进行相应的操作，保证了数据的一致性和可以实现服务发现的功能。

Zookeeper最后一个特性就是权限的设置了，之前我们已经说了，每个节点的权限信息会保存在他的state信息中。他存在的意义就在于为提供了安全机制，权限限制了 增删节点和读改节点数据的操作。Zookeeper的权限机制的粒度是很小的，我们甚至可以给每个ZNode节点单独设置权限，但是需要注意的是我们在该节点设置的权限并不能被该节点的子节点继承。除了这方面的粒度外，粒度小还体现在，我们可以给单独的ip地址开权限。权限模式分为world开放模式，ip模式，auth明文密码模式，digest密文密码模式，用sha-1+base64加密。