Zookeeper学习笔记（一）

---

1.zookeeper是什么？

1.1 zookeeper概览

zookeeper是一个分布式服务框架，是Apache Hadoop的一个子项目，它主要用来解决分布式应用中经常遇到的一些数据管理问题，如：统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。Zookeeper也实现诸如数据发布/订阅、负载均衡、分布式协调/通知、分布式锁和分布式队列等功能。

1.2 分布式系统的协调工作

分布式系统的协调工作就是通过某种方式，让每个节点的信息能够同步和共享，这依赖于服务进程之间的通信，通信方式有两种：

1.通过网络进行信息共享
通过人与人之间的直接沟通完成任务的下达和传递，比如在项目开发过程中，当任务分配有变化时，leader会单独告诉组员或者召开会议。

2.通过共享存储
将任务分配的更新信息提交到中央存储上，而组员可以每天从中央存储，比如SVN这种，拉取最新的任务分配表，保证每次更新组员都能第一时间获取最新的信息。

1.3 zookeeper如何实现分布式系统的协调

zookeeper针对分布式系统的协调，使用的是第二种方式，共享存储。

zookeeper的主从节点通知

当主节点也就是leader对某个从节点的分工信息做出了改变时，相关订阅的从节点会得到zookeeper的通知，取得自己最新的任务分配，完成工作后，把完成情况提交到zookeepeer，主节点订阅了该任务的完成情况信息，所以得到zookeeper的完工的通知。（注：slave节点想要获取Zookeeper的更新通知，需事先在关心的数据节点上设置观察点）

此处参考：https://blog.csdn.net/liyiming2017/article/details/83035157

1.4 zookeeper的相关概念

1.4.1 znode

zookeeper采用了类似文件系统的层级树状结构进行管理，zookeeper所保存的任务分配，完成情况等共享信息都被保存在一个个节点上，这些节点被称为znode。

zookeeper的存储结构.png

根节点 " / " 包含4个子节点，其中三个拥有下一级节点。有的叶子节点存储了信息。而有的节点上没有存储数据但也有着重要含义，比如/master下没有数据代表着分布式应用的主节点还没有被选举出来。znode节点存储的数据为字节数组，存储数据的格式没有限制，也不提供解析，需要应用自己实现。

• /master，存储了当前主节点的信息
• /workers，下面的每个子znode代表一个从节点，子znode上存储的数据，如“foo.com:2181”，代表从节点的信息。
• /tasks，下面的每个子znode代表一个任务，子znode上存储的信息如“run cmd”，代表该内务内容
• /assign，下面每个子znode代表一个从节点的任务集合。如/assign/worker-1，代表worker-1这个从节点的任务集合。/assign/worker-1下的每个子znode代表分配给worker-1的一个任务。

znode的类型

1. 持久节点（persistent）和临时节点（ephemeral）
   持久节点只能通过delete删除，而临时节点在创建该节点的客户端崩溃或关闭时，自动被删除。通俗的讲，在客户端与zookeeper断开连接后，持久化目录节点依然存在，而临时目录节点被删除。

2. 有序节点
   znode可以被设置为有序（sequentional）节点，有序的znode节点会被分配一个唯一的递增的证书，如果创建了一个名为worker-的有序节点，zk会自动分配一个1在它后面，名称变为worker-1，通过这种方式可以保证znode名称的唯一性，且方便看到节点创建的顺序。

znode一些操作的API

create /path data  //创建一个名为/path的znode，数据为data
delete /path //删除名为/path的znode
exists /path //检查是否存在名为/path的znode
setData /path data //设置名为/path的znode的数据为data
getData /path //返回名为/path的znode的数据
getChildren /path //返回所有/path节点的所有子节点列表

1.4.2 观察和通知（Watcher）

Watcher（事件监听器），是zk中的一个很重要的特性，zk允许用户在指定节点上注册一些Watcher，并且在一些特定事件触发的时候，zk服务端会将事件通知到感兴趣的客户端上去，该机制是zk实现分布式协调服务的重要特性。

使用zk时不能期望能够监控到节点每次的变化，因为每次设置观察点，观察点在触发一次之后立即失效，观察点一旦被触发，就需要再次设置新的观察点。所以当客户端C1在处理第一次触发的逻辑时，C2更新了tasks，那么C1不会得到新的通知，要想不错过，C1需要在设置监视点之前读取/tasks的数据，进行对比，发现更新。

zookeeper只能保证最终一致性，而不能保证强一致性，其达到最终一致性有两种方式：（1）再次设置观察点前再取一次数据和通知时取到的数据对比，发现变化了再执行逻辑（2）什么也不做，只是等再次变化时获取通知，最终一致。两者的区别是中间的时间差，具体如何选择取决于系统能否忍耐这个时间差。

zookeeper也可以定义不同的观察类型，如观察znode数据变化，或观察znode子节点变化，观察znode创建或者删除。

1.4.3 版本

对于每一个znode，zookeeper都会为其维护一个叫做Stat的数据结构，它记录了这个znode的三个数据版本，分别是version（当前znode的版本），cversion（当前znode子节点的版本）和cversion（当前znode的ACL版本）。

版本号随着每次数据变化递增，setData和delete操作以版本号作为参数，当传入的版本号与服务器上不一致时，会调用失败。当多个zk客户端同时对一个znode操作时，版本会起到有效避免分布式更新的并发问题的作用。

1.4.4 法定人数

zookeeper服务器运行于两种模式：独立模式和仲裁模式（集群）。仲裁模式下，会复制所有服务器的数据树。但如果让客户端等待所有复制完成，延迟太高。这里引入法定人数概念，指为了使zookeeper集群正常工作，必须有效运行的服务器数量。同时也是服务器通知客户端保存成功前，必须保存数据的服务器最小数。例如我们有一个5台服务器的zookeeper集群，法定人数为3，只要任何3个服务器保存了数据，客户端就会收到确认。只要有3台服务器存活，整个zookeeper集群就是可用的。

下图展示了客户端提交请求到收到回复的过程：

客户端提交请求到收到回复的过程

法定人数需要大于服务器数量的一半。也称为多数原则。举个例子说明，假如集群有5台服务器，法定人数为2，那么有2台服务器参与复制即可，若这2台server刚刚复制完/z这个znode，就挂掉了。此时剩下了3台server，大于法定人数2，所以zookeeper认为集群正常（当集群中存活的服务器数量大于等于法定人数，zookeeper认为集群正常），但这三台服务器是无法发现/z这个znode的。如果法定人数大于服务器数量一半，那么法定人数复制完成，就可以确保集群存活时，至少有一台服务器有最新的znode，否则集群认为自己已经崩溃。

引用https://blog.csdn.net/liyiming2017/article/details/83035157

1.4.5 会话（Session）

Session 指的是 ZooKeeper 服务器与客户端会话。在 ZooKeeper 中，一个客户端连接是指客户端和服务器之间的一个 TCP 长连接。客户端启动的时候，首先会与服务器建立一个 TCP 连接，从第一次连接建立开始，客户端会话的生命周期也开始了。通过这个连接，客户端能够通过心跳检测与服务器保持有效的会话，也能够向Zookeeper服务器发送请求并接受响应，同时还能够通过该连接接收来自服务器的Watch事件通知。Session的sessionTimeout值用来设置一个客户端会话的超时时间。当由于服务器压力太大、网络故障或是客户端主动断开连接等各种原因导致客户端连接断开时，只要在sessionTimeout规定的时间内能够重新连接上集群中任意一台服务器，那么之前创建的会话仍然有效。

在为客户端创建会话之前，服务端首先会为每个客户端都分配一个sessionID。由于 sessionID 是 Zookeeper 会话的一个重要标识，许多与会话相关的运行机制都是基于这个 sessionID 的，因此，无论是哪台服务器为客户端分配的 sessionID，都务必保证全局唯一。

如何保证session全局唯一？
保证sessionId全局唯一的基本思想是机器标识+随机数（时间戳），机器标识用来区分集群中不同的机器，同一台机器内的session可以用随机数、内存地址、计数器等多种手段来区分。

1.4.6 ACL

zookeeper采用ACL（AccessControlLists）策略来进行权限控制，类似于UNIX文件系统的权限控制，Zookeeper定义了5种权限：

• CREATE：创建子节点的权限
• READ：获取节点数据和子节点列表的权限
• WRITE：更新节点数据的权限
• DELETE：删除子节点的权限
• ADMIN：设置节点ACL的权限

注：CREATE和DELETE都是针对子节点的权限控制。

参考：

https://www.jianshu.com/p/93b3818434d3
https://blog.csdn.net/liyiming2017/article/details/83035157
https://blog.csdn.net/yangguosb/article/details/78262518