Zookeeper-Zookeeper特性与节点数据类型详解

1.Zookeeper介绍
        ZooKeeper 是一个开源的分布式协调框架，是Apache Hadoop 的一个子项目，主要用来解决分布式集群中应用系统的一致性问题。Zookeeper 的设计目标是将那些复杂目容易出错的分布式一致性服务封装起来，构成一高效可靠的原语集，并以一系列简单易用的接口提供给用户使用。

        Zookeeper本质上是一个分布式的小文件存储系统(Zookeeper=文件系统+监听机制)。提供基于类似于文件系统的目录树式的数据存储，并且可以对树中的节点进行有效管理，从而用来维护和监控存储的数据的状态变化。通过监控这些数据状态的变化，从而可以达到基于数据的集群管理、统一命名服务、分布式配置管理、分布式消息队列、分布式锁、分布式协调等功能。

        Zookeeper从设计模式角度来理解:是一个基于观察者模式设计的分布式服务管理框架，它负责存储和管理大家都关心的数据，然后接受观察者的注册，一旦这些数据的状态发生变化，Zookeeper 就将负责通知已经在Zookeeper上注册的那些观察者做出相应的反应。

 

 2.Zookeeper快速开始
2.1 Zookeeper安装
下载地址: https://zookeeper.apache.org/releases.html
运行环境: jdk8

 1)修改配置文件
解压安装包后进入conf目录，复制zoo sample.cfg，修改为zoo.cfg

 

 2)启动zookeeper server

#可以通过 bin/zkServer.sh 来查看都支持哪些参数
#默认加载配置路径conf/zoo.cfg
bin/zkServer.sh start
bin/zkServer.sh start conf/my_zoo.cfg

# 查看zookeeper状态
bin/zkServer.sh status

3)启动zookeeper client连接Zookeeper server

 

 2.3GUI工具
         Zookeeper图形化工具: Zoolnspector
        Zookeeper图形化丁具: 开源的prettyZoo
        Zookeeper图形化工具: 收费的ZooKeeperAssistant

3.ZooKeeper数据结构
        ZooKeeper 数据模型的结构与Unix 文件系统很类似，整体上可以看作是一棵树，每个节点称做一个ZNode。

ZooKeeper的数据模型是层次模型，层次模型常见于文件系统。层次模型和key-value模型是两种主流的数据模型。ZooKeeper使用文件系统模型主要基于以下两点考虑:
        1.文件系统的树形结构便于表达数据之间的层次关系
        2.文件系统的树形结构便于为不同的应用分配独立的命名空间( namespace)
ZooKeeper的次模型称作Data Tree，Data Tree的每个节点叫作Znode。不同于文件系统，每人节点都可以保存数据，每一个ZNode 默认能够存储1MB 的数据，每个ZNode 都可以通过其路径唯-标识，每个节点都有一个版本(version)，版本从0开始计数。 

3.1节点分类
        zookeeper存在几种不同的节点类型，他们具有不同的生命周期:

一个znode可以使持久性的，也可以是临时性的
        1.持久节点(PERSISTENT): 这样的znode在创建之后即使发生ZooKeeper集群宕机或者client宕机也不会丢失.

2.临时节点(EPHEMERAL): dlient宕机或者dlient在指定的timeout时间内没有给ZooKeeper集群发消息，这样的znode就会消失。

如果上面两种znode具备顺序性，又有以下两种znode：

        3.持顺序节点(PERSISTENT SEQUENTIAL): znode除了具备持久性znode的特点之外，znode的名字具备顺序性.

        4.临时顺序节点(EPHEMERAL SEQUENTIAL): node除了具备临时性znode的特点之外，zorde的名字具备顺序性.zookeeper主要用到的是以上4种节点

        5.Container节点(3.5.3版本新增): Container容器节点，当容器中没有任何子节点，该容器节点会被zk定期删除(定时任务默认60s 检查一次)。和持久节点的区别是 ZK 服务端启动后，会有一个单独的线程去扫描，所有的容器节点，当发现容器节点的子节点数量为0时，会自动删除该节点。可以用于leader 或者锁的场景中。

 6.TTL节点: 带过期时间节点，默认禁用，需要在00.cig中添加 extendedTypesEnabledetrue 开启。注意: TTL不能用于临时节点

 节点状态信息
类似于树状结构，节点下面是可以存储一些信息和属性的。可以通过stat命令来进行查看。

        cZxid: Znode创建的事务id.
        ctime:节点创建时的时间戳.
        mZxid: Znode被修改的事务id，即每次对znode的修改都会更新mZxid.

对于zk来说，每次的变化都会产生一个唯一的事务id,zxid (Zookeeper Transaction ld) ，通过zxid，可以确定更新操作的先后顺序。例如，如果zxid1小于zxid2，说明zxid1操作先于zxid2发生，zxid对于整个zk都是唯一的，即使操作作的是不同的znode。
        pZxid:表示该节点的子节点列表最后一次修改的事务1D，添加子节点或删除子节点就会影响子节点列表，但是修改子节点的数据内容则不影响该ID注意: 只有子节点列表变更了才会变更pzxid，子节点内容变更不会影响pzxid)。

         mtime: 节点最新一次更新发生时的时间戳
        cversion: 子节点的版本号。当znode的子节点有变化时，cversion 的值就会增加1。
        dataVersion: 数据版本号，每次对节点进行set操作，dataVersion的值都会增加1即使设置的是相同的数据)，可有效避免了数据更新时出现的先后顺序问题。
        ephemeral0wner：如果该节点为临时节点ephemeralOwner值表示与该节点绑定的session id。如果不是ephemeral0wner值为0(持久节点)。

在dlient和server通信之前,首先需要建立连接,该连接称为session。连接建立后,如果发生连接超时、授权失败,或者显式关闭连接连接便处于closed状态此时session结束
         dataLength :数据的长度
        numChildren:子节点的数量(只统计直接子节点的数量)

 3.2监听机制详解
watch机制，顾名思义是一个监听机制。Zokeeper中的watch机制，必须客户端先去服务端注册监听，这样事件发送才会触发监听，通知给客户端。
监听的对象是事件，支持的事件类型如下:
        None: 连接建立事件
        NodeCreated:节点创建
        NodeDeleted: 节点删除
        NodeDataChanged: 节点数据变化
        NodeChildrenChanged: 子节点列表变化
        DataWatchRemoved: 节点监听被移除
        ChildWatchRemoved: 子节点监听被移除

 永久性Watch
        在被触发之后，仍然保留，可以继续监听ZNode上的变更，是Zookeeper 3.6.0版本新增的功能。

 addWatch的作用是针对指定节点添加事件监听，支持两种模式
        PERSISTENT，持久化订阅，针对当前节点的修改和删除事件，以及当前节点的子节点的删除和新增事件。

        PERSISTENT RECURSIVE，持久化递归订阅(默认)，在PERSISTENT的基础上，增加了子节点修改的事件发，以及子节点的子节点的数据变化都会触发相关事件(满足递归订阅特性)

示例:协同服务

设计一个master-worker的组成员管理系统，要求系统中只能有一个master,master能实时获取系统中worker的情况保证组里面只有一个master的设计思路。

 master监控worker状态的设计思路

 

 示例:条件更新
设想用znode /c实现一个counter，使用set命令来实现自增1操作。条件更新场景:
        1.客户端1把/c更新到版本1，实现/c的自增1。
        2客户端2把/c更新到版本2，实现/c的自增1。
        3.客户端1不知道(C已经被客户端2 更新过了，还用过时的版本1是去更新/，更新失败。如果客户端1使用的是无条件更新，C就会更新为2，没有实现自增1。
        使用条件更新可以避免出现客户端基于过期的数据进行数据更新的操作。

 3.4应用场景详解
        ZooKeeper适用于存储和协同相关的关键数据，不适合用于大数据量存储.有了上述众多节点特性，使得zookeeper 能开发不出不同的经典应用场景，比如:
        注册中心
        数据发布/订阅(常用于实现配置中心)
        负载均衡
        命名服务
        分布式协调/通知
        集群管理
        Master选举
        分布式锁
        分布式队列

统一命名服务
        在分布式环境下，经常需要对应用/服务进行统一命名，便于识别。

例:IP不容易记住，而域名容易记住

 利用 Zookeeper 顺序节点的特性，制作分布式的序列号生成器，或者叫 id 生成器。(分布式环境下使用作为数据库 id，另外一种是UUID(缺点:没有规律))，ZooKeeper 可以生成有顺序的容易理解的同时支持分布式环境的编号.

数据发布/订阅
        数据发布订阅的一个常见的场景是配置中心，发布者把数据发布到 ZooKeeper 的一个或一系列的节点上，供订阅者进行数据订阅，达到动态获取数据的目的。

配置信息一般有几个特点
        1.数据量小的KV
        2.数据内容在运行时会发生动态变化
        3.集群机器共享，配置一致
ZooKeeper采用的是推拉结合的方式
        1.推服务端会推给注册了监控节点的客户端Watcher 事件通知
        2.拉: 客户端获得通知后，然后主动到服务端拉取最新的数据

统一集群管理
        分布式环境中，实时掌握每个节点的状态是必要的，可根据节点实时状态做出一些调整.

ZooKeeper可以实现实时监控节点状态变化:
        可将节点信息写入ZooKeeper上的一个ZNode
        监听这个ZNode可获取它的实时状态变化。

 负载均衡
        在Zookeeper中记录每台服务器的访问数，让访问数最少的服务器去处理最新的客户端请求

 Master-Worker架构
        master-work是一个广泛使用的分布式架构master-work架构中有一个master负责监控worker的状态，并为worker分配任务。
        在任何时刻，系统中最多只能有一个master，不可以出现两个master的情况，多个master共存会导致脑。

        系统中除了处于active状态的master还有一个backup master，如果active master失败了，backup master可以很快的进入active状态
        master实时监控worker的状态，能够及时收到worker成员变化的通知。master在收到worker成员变化的时候，通常重新进行任务的重新分配。