Zookeeper特性与节点数据类型详解-编程知识

CAP&Base理论

CAP理论

cap理论是指对于一个分布式计算系统来说，不可能满足以下三点:

一致性 ：在分布式环境中，一致性是指数据在多个副本之间是否能够保持一致的

特性，等同于所有节点访问同一份最新的数据副本。在一致性的需求下，当一个系统

在数据一致的状态下执行更新操作后，应该保证系统的数据仍然处于一致的状态。

可用性： 每次请求都能获取到正确的响应，但是不保证获取的数据为最新数据。

分区容错性： 分布式系统在遇到任何网络分区故障的时候，仍然需要能够保证对

外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障。

一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。

在这三个基本需求中，最多只能同时满足其中的两项，P 是必须的，因此只能在 CP 和 AP 中选择， zookeeper 保证的是 CP ，对比 spring cloud 系统中的注册中心 eureka实现的是 AP

思考：zookeeper是强一致性吗？

答 : Zookeeper写入是强一致性,读取是顺序一致性。

BASE 理论

BASE 是 Basically Available(基本可用)、Soft-state(软状态) 和 Eventually Consistent(最终一致性) 三个短语的缩写。

基本可用： 在分布式系统出现故障，允许损失部分可用性（服务降级、页面降级）。

软状态： 允许分布式系统出现中间状态。而且中间状态不影响系统的可用性。这里的中间状态是指不同的 data replication（数据备份节点）之间的数据更新可以出现延时的最终一致性。

最终一致性： data replications 经过一段时间达到一致性。

BASE 理论是对 CAP 中的一致性和可用性进行一个权衡的结果，理论的核心思想就是：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。

强一致性:又称线性一致性(linearizability )

1.任意时刻，所有节点中的数据是一样的,

2.一个集群需要对外部提供强一致性，所以只要集群内部某一台服务器的数据发生了改变，那么就

需要等待集群内其他服务器的数据同步完成后，才能正常的对外提供服务

3.保证了强一致性，务必会损耗可用性

弱一致性:

1.系统中的某个数据被更新后，后续对该数据的读取操作可能得到更新后的值，也可能是更改前的值。

2.即使过了不一致时间窗口，后续的读取也不一定能保证一致。

最终一致性:

1.弱一致性的特殊形式,不保证在任意时刻任意节点上的同一份数据都是相同的，但是随着时间的迁移，不同节点上的同一份数据总是在向趋同的方向变化

2.存储系统保证在没有新的更新的条件下，最终所有的访问都是最后更新的值

顺序一致性:

1.任何一次读都能读到某个数据的最近一次写的数据。

2.对其他节点之前的修改是可见(已同步)且确定的,并且新的写入建立在已经达成同步的基础上

Zookeeper介绍

ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是 Google的Chubby一个开源的实现，是 Hadoop和 Hbase的重要组件。

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

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

Zookeeper实战

Zookeeper安装

下载地址： https://zookeeper.apache.org/releases.html

运行环境：jdk8

1）修改配置文件

解压安装包后进入conf目录，复制zoo_sample.cfg，修改为zoo.cfg

修改 zoo.cfg 配置文件，将 dataDir=/tmp/zookeeper 修改为指定的data目录

zoo.cfg中参数含义：

2）启动zookeeper server

# 可以通过 bin/zkServer.sh 来查看都支持哪些参数
# 默认加载配置路径conf/zoo.cfg
bin/zkServer.sh start conf/zoo.cfg  
# windows  直接双击zkServer.cmd
# 查看zookeeper状态bin/zkServer.sh status

3）启动zookeeper client连接Zookeeper server

bin/zkCli.sh# 连接远程的zookeeper serverbin/zkCli.sh ‐server ip:port

客户端命令行操作

输入命令 help 查看zookeeper支持的所有命令：

常见cli命令

ZooKeeper: Because Coordinating Distributed Systems is a Zoo

ZooKeeper数据结构

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

点称做一个 ZNode

ZooKeeper的数据模型是层次模型，层次模型常见于文件系统。层次模型和key-value模型是两种主流的数据模型。 ZooKeeper使用文件系统模型主要基于以下两点考虑:

1. 文件系统的树形结构便于表达数据之间的层次关系

2. 文件系统的树形结构便于为不同的应用分配独立的命名空间( namespace )

ZooKeeper的层次模型称作Data Tree，Data Tree的每个节点叫作Znode。不同于文件系统，每个节点都可以保存数据，每一个 ZNode 默认能够存储 1MB 的数据，每个 ZNode 都可以通过其路径唯一标识，每个节点都有一个版本(version)，版本从0开始计数。

节点分类

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

1. 持久节点(PERSISTENT): 这样的znode在创建之后即使发生ZooKeeper集群宕机或者client宕机也不会丢失。

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

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

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

4. 临时顺序节点(EPHEMERAL_SEQUENTIAL): znode除了具备临时性znode的特点之外，zorde的名字具备顺序性。

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

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

6. TTL节点: 带过期时间节点，默认禁用，需要在zoo.cfg中添加 extendedTypesEnabled=true 开启。注意：ttl不能用于临时节点

#创建持久节点
create /servers xxx
#创建临时节点
create ‐e /servers/host xxx
#创建临时有序节点
create ‐e ‐s /servers/host xxx
#创建容器节点
create ‐c /container xxx
# 创建ttl节点
create ‐t 10 /ttl

节点状态信息

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 ：子节点的数量（只统计直接子节点的数量）

监听通知（watcher）机制

一个Watch事件是一个一次性的触发器，当被设置了Watch的数据发生了改变的时候，则服务器将这个改变发送给设置了Watch的客户端，以便通知它们。

Zookeeper采用了 Watcher机制实现数据的发布订阅功能，多个订阅者可同时监听某一特定主题对象，当该主题对象的自身状态发生变化时例如节点内容改变、节点下的子节点列表改变等，会实时、主动通知所有订阅者。 watcher机制事件上与观察者模式类似，也可看作是一种观察者模式在分布式场景下的实现方式。

watcher的过程：

1. 客户端向服务端注册watcher

2. 服务端事件发生触发watcher

3. 客户端回调watcher得到触发事件情况

注意：Zookeeper中的watch机制，必须客户端先去服务端注册监听，这样事件发送才会触发监听，通知给客户端。

支持的事件类型：

None: 连接建立事件

NodeCreated ：节点创建

NodeDeleted ：节点删除

NodeDataChanged ：节点数据变化

NodeChildrenChanged ：子节点列表变化

DataWatchRemoved ：节点监听被移除