剖析Zookeeper（一）

本人能力有限，描述不清晰或者有误的地方还请见谅，同时欢迎大家一起交流，jackice_thinker@163.com

Zookeeper是一个分布式的，开源的分布式协调服务程序，是一个以key/value为存储模型的存储系统，在服务发现、集群维护场景中得到了广泛的应用，Kafka集群场景下就是采用Zookeeper进行维护的。全局Session，分布式锁等场景同样可以使用Zookeeper实现，目前还有Etcd等KV存储系统可以作为分布式系统数据库，这里就不介绍Etcd了，感兴趣的朋友可以参考Etcd相关的文章。这篇文章主要介绍Zookeeper的文件存储模型。

Zookeeper 文件存储模型

Zookeeper采用树形节点模型存储，每个节点都是通过路径来识别。

Zookeeper的存储模型类似于linux文件系统，linux系统和Zookeeper都采用树形结构进行存储，存储都始于Root，在linux系统中有目录和文件的概念，zookeeper进行抽象，只有节点概念，所有节点均可以存储数据。这是和linux系统最大的区别。

Zookeeper每个节点都维护着自身以及子节点的信息，节点维护着创建时间、节点ACL（Access Control List）、长度、时间戳、版本信息等数据结构，每个节点ACL信息控制着节点的访问权限，在一定程度上保证了节点操作的安全性。节点ACL这里就不深入分析，后面会有专门的文章描述ZK ACL机制。

Zookeeper 之DataTree

其实Zookeeper的数据结构比较简单，主要由DataTree，DataNode组成，DataTree主要维护一个ConcurrentHashMap,ConcurrentHashMap是一个DataNode的集合，而Znode的acl、数据、子节点等信息由DataNode维护，从类图中可以看出Zookeeper的核心数据结构是比较简单的，如果想更深入的了解可以进一步的去阅读源码。

Zookeeper 节点类型

Znode具有生命周期控制，其生命周期控制有Znode类型决定，Znode一共有四种类型，分别是持久节点（PERSISTENT）、持久顺序节点（PERSISTENT_SEQUENTIAL）、临时节点（EPHEMERAL）以及临时顺序节点（EPHEMERAL_SEQUENTIAL），这里的顺序指的就是是否会自动添加编号，如果是顺序节点，新建节点会根据当前编号加1作为新节点的编号。

• 持久节点(PERSISTENT)

  持久节点一旦创建之后一直存在，不会随着创建节点会话Session的消失而删除，直到收到Delete请求之后才能删除。

  

• 持久顺序节点（PERSISTENT_SEQUENTIAL）

  持久顺序节点和持久节点类似，节点一旦创建之后就一直存在，不会因为创建节点会话的消失而删除，同样需要Delete请求才能抢器删除，唯一的区别就是持久顺序Znode会维护一个序列，每个子节点创建都会有一个序号，序号从1开始，每增加一个节点加1，最大是整数的取值范围（2147483647），也就是说这类节点上限就是2147483647个，当然在实际场景中这个数量级够用了。

• 临时节点（EPHEMERAL）

  临时节点和创建节点会话绑定，临时节点会随着创建session的失效而删除，而且临时节点下面不能创建子节点，在维护集群场景下临时节点可以得到很好的应用，临时节点是Zookeeper发现服务的设计核心之一。集群中的每个节点只需要在ZK上创建一个EPHEMERAL Znode即可实现节点的生命周期监控。

  

• 临时顺序节点（EPHEMERAL_SEQUENTIAL）

  临时顺序节点是在临时节点的基础上加上序列控制，在所有子节点列表中均被标上序号，序号和持久顺序节点的规则是一样的。

  ok，本文就写到这了，关于剖析Zookeeper更多的文章请关注EBCloud。