Zookeeper基础知识（一）

一、Zookeeper是什么？

ZooKeeper是一个开放源码的分布式协调服务，它是集群的管理者，监视着集群中各个节点的状态根据节点提交的反馈，进行下一步合理操作。最终，将简单易用的接口和性能高效、功能稳定的系统提供给用户。
分布式应用程序可以基于Zookeeper实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master选举、分布式锁和分布式队列等功能。最主要用处：解决单点故障。
Zookeeper保证了如下分布式一致性特性：

• 顺序一致性：来自客户端的更新将严格按照客户端发送的顺序处理
• 原子性：更新或者成功或者失败，不存在部分成功或者部分失败的场景
• 单一视图：无论客户端连接到哪个服务器，看到的都是一样的视图
• 可靠性：一旦一个更新生效，它将一直保留，直到再次更新
• 实时性：在特定的一段时间内，任何系统的改变都能被客户端看到，或者被监听到

客户端的读请求可以被集群中的任意一台机器处理。对于写请求，这些请求会同时发给其他zookeeper机器并且达成一致后，请求才会返回成功。因此，随着zookeeper的集群机器增多，读请求的吞吐会提高但是写请求的吞吐会下降。
有序性是zookeeper中非常重要的一个特性，所有的更新都是全局有序的，每个更新都有一个唯一的时间戳，这个时间戳称为zxid（Zookeeper Transaction Id）。而读请求只会相对于更新有序，也就是读请求的返回结果中会带有这个zookeeper最新的zxid。

二、常见API和命令

1.API
Create /path data
Delete /path
Exists /path
setData /path data
getData /path
getChildren /path

java：参照Apache curator(Netflix开源)、或者zk自带zkClient
Curator框架在原生zk客户端基础上进行了包装，提供了zk各种应用场景，如：分布式锁，集群领导者选举，共享计数器、缓存机制、分布式队列等。
Curator主要从以下几个方面降低了zk使用的复杂性：
重试机制：将所有捕获可恢复异常（后面会讲）配置了一个重试策略，内部也提供了几种标准的重试策略（指数补偿）
连接状态监控：Curator初始化之后会一直对zk连接进行监听，一旦状态变化做出相应处理
Zk客户端实例管理：Curator会对zk客户端到server集群连接进行管理，并在需要的时候重建zk实例，保证zk集群连接的可靠性。

2.命令
启动：./zkServer.sh start
查看zk运行状态：./zkServer.sh status
客户端连接zk: ./zkClis.sh
ls：查看
get：获取节点数据和更新
cZxid ：创建节点的id
ctime ： 节点的创建时间
mZxid ：修改节点的id
mtime ：修改节点的时间
pZxid ：子节点的id
cversion : 子节点的版本
dataVersion ： 当前节点数据的版本
aclVersion ：权限的版本
ephemeralOwner ：判断是否是临时节点
dataLength ： 数据的长度
numChildren ：子节点的数量
stat：获得节点更新信息
create –e：创建临时节点
create –s：创建顺序节点
delete /path ：删除
stat path watch ：设置watch事件
get path watch：设置watch事件

三、Zookeeper的权限控制

ACL权限控制：
ZK的节点有5种操作权限：CREATE、READ、WRITE、DELETE、ADMIN 也就是 增、删、改、查、管理权限，这5种权限简写为crwda(即：每个单词的首字符缩写)。
注：这5种权限中，delete是指对子节点的删除权限，其它4种权限指对自身节点的操作权限

身份的认证有4种方式：

• world：默认方式，相当于全世界都能访问
• auth：代表已经认证通过的用户(cli中可以通过addauth digest user:pwd 来添加当前上下文中的授权用户)
• digest：即用户名:密码这种方式认证，这也是业务系统中最常用的
• ip：使用Ip地址认证
  命令：
  getAcl: 获取某个节点的权限信息
  setAcl: 设置权限

四、Znode节点

1. 持久节点
2. 临时节点
3. 持久有序
4. 临时有序
   
   所谓持久节点，是指在节点创建后，就一直存在，直到有删除操作来主动清除这个节点——不会因为创建该节点的客户端会话失效而消失。
   这类节点的基本特性和上面的节点类型是一致的。额外的特性是，在ZK中，每个父节点会为他的第一级子节点维护一份时序，会记录每个子节点创建的先后顺序。基于这个特性，在创建子节点的时候，可以设置这个属性，那么在创建节点过程中，ZK会自动为给定节点名加上一个数字后缀，作为新的节点名。这个数字后缀的范围是整型的最大值。
   和持久节点不同的是，临时节点的生命周期和客户端会话绑定。也就是说，如果客户端会话失效，那么这个节点就会自动被清除掉。注意，这里提到的是会话失效，而非连接断开。另外，在临时节点下面不能创建子节点。
   临时节点的生命周期和客户端会话绑定。也就是说，如果客户端会话失效，那么这个节点就会自动被清除掉。注意 创建的节点会自动加上编号。

数据保存在内存中，所以高吞吐，低延迟，也证明zk文件节点不宜存储过大数据。

五、监视和通知

1、轮询查看

2、Watcher机制

zookeeper这个机制，减少了图1-1中多次2的网络开销。
在图1-2中为设置监听点watch的流程：
1：客户端c2 监听变化，C1连接后在监听/tasks目录下创建一个有序递增节点task1
2：C2收到watch通知
3：C2 向zk再次注册/task
问题：在第三步，C2添加新的watch节点时，如果有新的客户端c3连接后，向/tasks 添加一个新的任务，客户端C2是不是要错过这个变更？
答案：需在3步设置新的watch节点的之前读取下状态

注：尽量将多次变更合并为一个watch事件，watch是单次事件，不一定每次都成功，watch只会保存在内存，而不会持久化到硬盘，客户端与服务端断开连接，需要重置watch

使用watch需要注意的几点：

• Watches通知是一次性的，必须重复注册.
• 发生CONNECTIONLOSS之后，只要在session_timeout之内再次连接上（即不发生SESSIONEXPIRED），那么这个连接注册的watches依然在。
• 节点数据的版本变化会触发NodeDataChanged，注意，这里特意说明了是版本变化。存在这样的情况，只要成功执行了setData()方法，无论内容是否和之前一致，都会触发NodeDataChanged。
• 对某个节点注册了watch，但是节点被删除了，那么注册在这个节点上的watches都会被移除。
• 同一个zk客户端对某一个节点注册相同的watch，只会收到一次通知。
• Watcher对象只会保存在客户端，不会传递到服务端在，具体流程上，简单讲，客户端在向 ZooKeeper 服务器注册 Watcher 的同时，会将 Watcher 对象存储在客户端的 WatchManager 中。当ZooKeeper 服务器触发 Watcher 事件后，会向客户端发送通知，客户端线程从 WatchManager 的实现类中取出对应的 Watcher 对象来执行回调逻辑。

六、版本与运行模式

版本控制并发
举例：Client1和Client2每次setData后，会保存服务器的版本号在客户端，下次变更会携带版本号，两个调用以版本号作为传入参数，只有传入参数和服务器版本号一致，才能变更(CAS)

Zookeeper两种运行模式：
独立模式、仲裁模式
仲裁模式下有法定人数的概念，一般最少设置为（n/2+1）后续讲解

七、会话

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

会话生命周期：

如果一个客户端与服务器因超时断开连接，客户端仍然保持connecting状态，直到sessionTimeout。如果设sessionTimeout = t，那么在t/3的时刻，客户端会重连，如果失败，在2t/3的时候，会寻找其他服务器，尝试连接。
连接的新服务器的状态不能落后于原服务器。所以用zxid来决定是否落后。