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

1、 Zookeeper介绍

ZooKeeper 是一个开源的分布式协调框架，是Apache Hadoop 的一个子项目，主要用来办理分布式集群中应用系统的一致性问题。Zookeeper 的设计目标是将那些复杂且容易堕落的分布式一致性服务封装起来，构成一个高效可靠的原语集，并以一系列简单易用的接口提供给用户利用。
官方：https://zookeeper.apache.org/

ZooKeeper本质上是一个分布式的小文件存储系统（Zookeeper=文件系统+监听机制）。提供基于类似于文件系统的目次树方式的数据存储，而且可以对树中的节点进行有用管理，从而用来维护和监控存储的数据的状态变化。通过监控这些数据状态的变化，从而可以到达基于数据的集群管理、同一命名服务、分布式配置管理、分布式消息队列、分布式锁、分布式协调等功能。
Zookeeper从设计模式角度来理解：是一个基于观察者模式设计的分布式服务管理框架，它负责存储和管理大家都关心的数据，然后接受观察者的注册，一旦这些数据的状态发生变化，Zookeeper 就将负责通知已经在Zookeeper上注册的那些观察者做出相应的反应。

2、Zookeeper快速开始

2.1 Zookeeper安装
下载地址：https://zookeeper.apache.org/releases.html
运行环境：jdk8
1）修改配置文件
解压安装包后进入conf目次，复制zoo_sample.cfg，修改为zoo.cfg
cp zoo_sample.cfg zoo.cfg
修改 zoo.cfg 配置文件，将 dataDir=/tmp/zookeeper 修改为指定的data目次
zoo.cfg中参数含义：

2）启动zookeeper server

1. # 可以通过 bin/zkServer.sh  来查看都支持哪些参数
2. # 默认加载配置路径conf/zoo.cfg
3. bin/zkServer.sh start
4. bin/zkServer.sh start conf/my_zoo.cfg
5. # 查看zookeeper状态
6. bin/zkServer.sh status

复制代码

3）启动zookeeper client毗连Zookeeper server

1. bin/zkCli.sh
2. # 连接远程的zookeeper server
3. bin/zkCli.sh -server ip:port

复制代码

2.2 客户端命令行操作
输入命令 help 查看zookeeper支持的所有命令：
常见cli命令
https://zookeeper.apache.org/doc/r3.8.0/zookeeperCLI.html
命令根本语法

2.3 GUI工具

• Zookeeper图形化工具：ZooInspector
  
• Zookeeper图形化工具：开源的prettyZoo
  
• Zookeeper图形化工具：收费的ZooKeeperAssistant
  

3、ZooKeeper数据布局

ZooKeeper 数据模型的布局与 Unix 文件系统很类似，整体上可以看作是一棵树，每个节点称做一个 ZNode。
ZooKeeper的数据模型是条理模型，条理模型常见于文件系统。条理模型和key-value模型是两种主流的数据模型。ZooKeeper利用文件系统模型主要基于以下两点考虑:

• 文件系统的树形布局便于表达数据之间的条理关系
  
• 文件系统的树形布局便于为差别的应用分配独立的命名空间( namespace )
  

ZooKeeper的条理模型称作Data Tree，Data Tree的每个节点叫作Znode。差别于文件系统，每个节点都可以生存数据，每一个 ZNode 默承认以或许存储 1MB 的数据，每个 ZNode 都可以通过其路径唯一标识，每个节点都有一个版本(version)，版本从0开始计数。

1. public class DataTree {
2.     private final ConcurrentHashMap<String, DataNode> nodes =
3.         new ConcurrentHashMap<String, DataNode>();
4.         
5.         
6.     private final WatchManager dataWatches = new WatchManager();
7.     private final WatchManager childWatches = new WatchManager();
8.    
9. }
10. public class DataNode implements Record {
11.     byte data[];
12.     Long acl;
13.     public StatPersisted stat;
14.     private Set<String> children = null;
15. }      

复制代码

3.1 节点分类
zookeeper存在几种差别的节点类型，他们具有差别的生命周期：

一个znode可以使持久性的，也可以是暂时性的:

• 持久节点(PERSISTENT): 如许的znode在创建之后即使发生ZooKeeper集群宕机大概client宕机也不会丢失。
  
• 暂时节点(EPHEMERAL ): client宕机大概client在指定的timeout时间内没有给ZooKeeper集群发消息，如许的znode就会消散。
  

假如上面两种znode具备次序性，又有以下两种znode :

• 持久次序节点(PERSISTENT_SEQUENTIAL): znode除了具备持久性znode的特点之外，znode的名字具备次序性。
  
• 暂时次序节点(EPHEMERAL_SEQUENTIAL): znode除了具备暂时性znode的特点之外，zorde的名字具备次序性。
  

zookeeper主要用到的是以上4种节点。

• Container节点 (3.5.3版本新增)：Container容器节点，当容器中没有任何子节点，该容器节点会被zk定期删除（定时使命默认60s 检查一次)。 和持久节点的区别是 ZK 服务端启动后，会有一个单独的线程去扫描，所有的容器节点，当发现容器节点的子节点数目为 0 时，会主动删除该节点。可以用于 leader 大概锁的场景中。
  
• TTL节点: 带过期时间节点，默认禁用，需要在zoo.cfg中添加 extendedTypesEnabled=true 开启。
  

1. #创建持久节点
2. create /servers  xxx
3. #创建临时节点
4. create -e /servers/host  xxx
5. #创建临时有序节点
6. create -e -s /servers/host  xxx
7. #创建容器节点
8. create -c /container xxx
9. # 创建ttl节点
10. create -t 10 /ttl

复制代码

示例：实现分布式锁
分布式锁要求假如锁的持有者宕了，锁可以被释放。ZooKeeper 的 ephemeral 节点恰恰具备如许的特性。
终端1:

1. zkCli.sh
2. create –e /lock
3. quit

复制代码

终端2：

1. zkCli.sh
2. create –e /lock
3. stat –w /lock
4. create –e /lock

复制代码

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

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

对于zk来说，每次的变化都会产生一个唯一的事务id，zxid（ZooKeeper Transaction Id），通过zxid，可以确定更新操作的先后次序。例如，假如zxid1小于zxid2，说明zxid1操作先于zxid2发生，zxid对于整个zk都是唯一的，即使操作的是差别的znode。

• pZxid:
  体现该节点的子节点列表最后一次修改的事务ID，添加子节点或删除子节点就会影响子节点列表，但是修改子节点的数据内容则不影响该ID（注意: 只有子节点列表变动了才会变动pzxid，子节点内容变动不会影响pzxid）
  
• mtime：节点最新一次更新发生时的时间戳.
  
• cversion ：子节点的版本号。当znode的子节点有变化时，cversion 的值就会增长1。
  
• dataVersion：数据版本号，每次对节点进行set操作，dataVersion的值都会增长1（即使设置的是类似的数据），可有用避免了数据更新时出现的先后次序问题。
  
• ephemeralOwner:假如该节点为暂时节点, ephemeralOwner值体现与该节点绑定的session id。假如不是, ephemeralOwner值为0(持久节点)。
  在client和server通信之前,首先需要创建毗连,该毗连称为session。毗连创建后,假如发生毗连超时、授权失败,大概显式关闭毗连,毗连便处于closed状态, 此时session竣事。
  
• dataLength ： 数据的长度
  
• numChildren ：子节点的数目
  （只统计直接子节点的数目）
  

3.2 监听机制详解
watch机制，顾名思义是一个监听机制。Zookeeper中的watch机制，必须客户端先去服务端注册监听，如许事件发送才会触发监听，通知给客户端。
监听的对象是事件，支持的事件类型如下：

• None: 毗连创建事件
  
• NodeCreated： 节点创建
  
• NodeDeleted： 节点删除
  
• NodeDataChanged：节点数据变化
  
• NodeChildrenChanged：子节点列表变化
  
• DataWatchRemoved：节点监听被移除
  
• ChildWatchRemoved：子节点监听被移除
  

1. #监听节点数据的变化
2. get -w path
3. stat -w path
4. #监听子节点增减的变化
5. ls -w path

复制代码

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

1. addWatch [-m mode] path

复制代码

addWatch的作用是针对指定节点添加事件监听，支持两种模式

• PERSISTENT，持久化订阅，针对当前节点的修改和删除事件，以及当前节点的子节点的删除和新增事件。
  
• PERSISTENT_RECURSIVE，持久化递归订阅(默认)，在PERSISTENT的基础上，增长了子节点修改的事件触发，以及子节点的子节点的数据变化都会触发相关事件（满足递归订阅特性）
  

示例: 协同服务
设计一个master-worker的组成员管理系统，要求系统中只能有一个master , master能及时获取系统中worker的环境。
包管组内里只有一个master的设计思路

1. #master1
2. create -e /master "m1:2223"  
3. #master2
4. create -e /master "m2:2223"   # /master已经存在，创建失败
5. Node already exists: /master
6. #监听/master节点
7. stat -w /master
8. #当master2收到/master节点删除通知后可以再次发起创建节点操作
9. create -e /master "m2:2223"

复制代码

master-slave选举也可以用这种方式

master监控worker状态的设计思路

1. #master服务
2. create /workers
3. #让master服务监控/workers下的子节点
4. ls -w /workers
5. #worker1
6. create -e /workers/w1 "w1:2224" #创建子节点，master服务会收到子节点变化通知
7. #master服务
8. ls -w /workers
9. #worker2
10. create -e /workers/w2 "w2:2224"  #创建子节点，master服务会收到子节点变化通知
11. #master服务
12. ls -w /workers
13. #worker2
14. quit  #worker2退出，master服务会收到子节点变化通知

复制代码

3.3 节点特性总结
1.同一级节点 key 名称是唯一的
已存在/lock节点，再次创建会提示已经存在
2.创建节点时，必须要带上全路径
3.session 关闭，暂时节点扫除
4.主动创建次序节点
5.watch 机制，监听节点变化
事件监听机制类似于观察者模式，watch 流程是客户端向服务端某个节点路径上注册一个 watcher，同时客户端也会存储特定的 watcher，当节点数据或子节点发生变化时，服务端通知客户端，客户端进行回调处理。特别注意：监听事件被单次触发后，事件就失效了。
6.delete 命令只能一层一层删除。提示：新版本可以通过 deleteall 命令递归删除。
3.4 应用场景详解
ZooKeeper适用于存储和协同相关的关键数据，不适适用于大数据量存储。
有了上述众多节点特性，使得 zookeeper 能开发不出差别的经典应用场景，比如：

• 注册中心
  
• 数据发布/订阅（常用于实现配置中心）
  
• 负载均衡
  
• 命名服务
  
• 分布式协调/通知
  
• 集群管理
  
• Master选举
  
• 分布式锁
  
• 分布式队列
  

同一命名服务
在分布式环境下，经常需要对应用/服务进行同一命名，便于辨认。
例如：IP不容易记着，而域名容易记着。

利用 ZooKeeper 次序节点的特性，制作分布式的序列号天生器，大概叫 id 天生器。（分布式环境下利用作为数据库 id，另外一种是 UUID（缺点：没有规律）），ZooKeeper 可以天生有次序的容易理解的同时支持分布式环境的编号。
/
└── /order
├── /order-date1-000000000000001
├── /order-date2-000000000000002
├── /order-date3-000000000000003
├── /order-date4-000000000000004
└── /order-date5-000000000000005
数据发布/订阅
数据发布/订阅的一个常见的场景是配置中心，发布者把数据发布到 ZooKeeper 的一个或一系列的节点上，供订阅者进行数据订阅，到达动态获取数据的目的。
配置信息一般有几个特点:
1 数据量小的KV
2 数据内容在运行时会发生动态变化
3 集群机器共享，配置一致
ZooKeeper 采用的是推拉结合的方式。
推: 服务端会推给注册了监控节点的客户端 Watcher 事件通知
拉: 客户端得到通知后，然后主动到服务端拉取最新的数据

同一集群管理
分布式环境中，及时掌握每个节点的状态是必要的，可根据节点及时状态做出一些调整。
ZooKeeper可以实实际时监控节点状态变化：

• 可将节点信息写入ZooKeeper上的一个ZNode。
  
• 监听这个ZNode可获取它的及时状态变化。
  

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

Master-Worker架构
master-worker是一个广泛利用的分布式架构。 master-work架构中有一个master负责监控worker的状态，并为
worker分配使命。

• 在任何时候，系统中最多只能有一个master，不可以出现两个master的环境，多个master共存会导致脑裂。
  
• 系统中除了处于active状态的master另有一个backup master，假如active master失败了，backup master可以很快的进入active状态。
  
• master及时监控worker的状态，可以或许及时收到worker成员变化的通知。master在收到worker成员变化的时候，通常重新进利用命的重新分配。
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。