Zookeeper数据模型之初探-CSDN博客

本文链接：https://blog.csdn.net/milhua/article/details/78959109

ZK是hadoop生态圈的一个很重要的项目之一，在集群环境中，ZK的重要性越来越大，现在的集群环境基本很难脱离ZK实现分布式协调服务，任何集群环境都一个类中心控制器来协调服务，如果是自己去设计编写一个这样子的应用程序，不仅给开发带来很多难度,也不好去维护，大大降低效率，也消耗很多成本。所以使用ZK带来的好处就是你不用花太多时间去关注技术上面的实现，而更多去注重业务上面的开发就可以，但是了解ZK会大大的提高我们的开发效率！

（1）ZK数据模型之初探

a. 层次化的目录结构，类似于一棵倒起来的树，命名符合常规文件规范。

b. 在zookeeper中每一个节点都叫做Znode,并且其有一个唯一的路径标识。

c .Znode可以包含数据和子节点，但ephemeral类型的节点不能包含子节点，因为ephemeral标识的节点是临时的节点。

d. Zonde数据可以有多个版本，比如某一个路径下面存在多个版本，查看这个路径下面的数据要带上版本号。

e. 客户端应用可以在节点上设置监视器。

f.节点上的数据不支持部分读写，需要一次性完整读写，保证数据的原子性！

（2）ZK节点—Znode

a. znode可以被监控，包括目录下面的数据的修改，子目录的变化等，一旦变化可以通知设置监控的客户端，这个功能对于应用最重要的特性，通过这个特性可以实现的功能包括配置的集中管理、集群管理、分布式锁等等。

b. znode有两种节点，一种是持久的（Persistent）,另一种是临时的（ephemeral）。

c. znode在创建选择节点类型时确定并且之后不能再修改。

d. 短暂的znode在跟客户端回话结束时，zookeeper会将改短暂的znode删除，短暂的znode不能有子节点。

c.Znode有四种形式的目录节点，PERSISTENT、PERSISTENT_SEQUENTIAL、EPHEMERAL、EPHEMERAL_SEQUENTIAL

d.Znode 可以是临时节点，一旦创建这个 znode 的客户端与服务器失去联系，这个znode 也将自动删除，Zookeeper的客户端和服务器通信采用长连接方式，每个客户端和服务器通过心跳来保持连接，这个连接状态称为 session，如果 znode 是临时节点，这个 session 失效，znode 也就删除了；持久化目录节点，这个目录节点存储的数据不会丢失；顺序自动编号的目录节点，这种目录节点会根据当前已近存在的节点数自动加1，然后返回给客户端已经成功创建的目录节点名；临时目录节点，一旦创建这个节点的客户端与服务器端口也就是session 超时，这种节点会被自动删除；临时自动编号节点。

（3）ZK角色分析

a. 领导者（leader）,负责进行投票的发起和投票，更新系统状态。

b. 学习者（learner），包括跟随者（flower）跟观察者（observer），flower接收客户端的请求并向客户端返回结果，在选举过程参与投票。

c. observer可以接收客户端的链接，将写请求传给leader，observer不参与投票过程，只同步leader状态，observer的目的是为了扩展系统，提高读取速度。

d. 客户端（client），发起请求。

（4）ZK的顺序号

a. 创建znode时设置顺序标识，znode名称后会附加一个值。

b.顺序号是一个单调递增的计数器，由父节点维护。

c. 在分布式系统中，顺序号可以被用于为所有的事件进行全局排序，这样客户端可以通过顺序号推断事件的顺序。

（5）ZK的读写机制

a. Zookeeper是一个由多个server组成的集群

b. 一个leader，多个follower

c. 每个server保存一份数据副本

d. 全局数据一致

e. 分布式读写

f. 更新请求转发，由leader实施

（7）ZK保证

a. 更新请求顺序进行，来自同一个client的更新请求按其发送顺序依次执行

b. 数据更新原子性，一次数据更新要么成功，要么失败

c. 全局唯一数据视图，client无论连接到哪个server，数据视图都是一致的

d.实时性，在一定事件范围内，client能读到最新数据

（8）ZK的API接口

下面这些是我们常去操作ZK时要去实现的接口，这里我也把他记下来了。

String create(String path, byte[] data, List<ACL> acl, CreateMode createMode) 
Stat exists(String path, boolean watch) 
void delete(String path, int version) 
List<String> getChildren(String path, boolean watch) 
List<String> getChildren(String path, boolean watch) 
Stat setData(String path, byte[] data, int version) 
byte[] getData(String path, boolean watch, Stat stat) 
void addAuthInfo(String scheme, byte[] auth) 
Stat setACL(String path, List<ACL> acl, int version) 
List<ACL> getACL(String path, Stat stat)

（9）观察（watcher）

a. Watcher 在 ZooKeeper 是一个核心功能，Watcher 可以监控目录节点的数据变化以及子目录的变化，一旦这些状态发生变化，服务器就会通知所有设置在这个目录节点上的Watcher，从而每个客户端都很快知道它所关注的目录节点的状态发生变化，而做出相应的反应

b. 可以设置观察的操作：exists,getChildren,getData

c. 可以触发观察的操作：create,delete,setData

（10）ZK的工作原理

Zookeeper的核心是原子广播，这个机制保证了各个server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，它们分别是恢复模式和广播模式。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数server的完成了和leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和server具有相同的系统状态。

一旦leader已经和多数的follower进行了状态同步后，他就可以开始广播消息了，即进入广播状态。这时候当一个server加入zookeeper服务中，它会在恢复模式下启动，发现leader，并和leader进行状态同步。待到同步结束，它也参与消息广播。Zookeeper服务一直维持在Broadcast状态，直到leader崩溃了或者leader失去了大部分的followers支持。（ Broadcast模式极其类似于分布式事务中的2pc（two-phrasecommit两阶段提交）：即leader提起一个决议，由followers进行投票，leader对投票结果进行计算决定是否通过该决议，如果通过执行该决议（事务），否则什么也不做。）

广播模式需要保证proposal被按顺序处理，因此zk采用了递增的事务id号(zxid)来保证。所有的提议(proposal)都在被提出的时候加上了zxid。实现中zxid是一个64为的数字，

它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch。低32位是个递增计数。

当leader崩溃或者leader失去大多数的follower，这时候zk进入恢复模式，恢复模式需要重新选举出一个新的leader，让所有的server都恢复到一个正确的状态。