zk学习笔记

ZooKeeper 是一个分布式的，开放源码的分布式应用程序协调服务。

二.ZooKeeper应用场景

1.分布式协调组件

 协调分布式状态：利用zk的watch机制通知系统状态

2.分布式锁

3.无状态化的实现

利用zk存储分布式系统中的用户登录信息。

tickTime=2000
#zk时间配置中的基本单位。毫秒
initLimit=5
#follower初始化连接到leader的时长，tickTime的倍数即：initLimit*tickTime
syncLimit=10
#follower与leader同步数据的最大时长，tickTime的倍数
dataDir=/data/zk1
#zk数据及日志的存储目录，如果没有dataLogDir配置，则日志也保存在这个目录
clientPort=2181
#对客户端暴露的端口
maxClientCnxns=60
#单个客户端与zk连接的最大并发数
autopurge.snapRetainCount=3
#保存的数据快照数量，之外的会被清除

autopurge.snapInterval=1
#清除快照的时间间隔，默认为0不会自动删除，小时

ls /
ls /ZooKeeper 查看znode子节点列表
create /zk “myData” 创建znode节点
get /zk
get /zk/node1 获取znode数据
set /zk “myData1” 设置znode数据
ls /zk watch 就对一个节点的子节点变化事件注册了监听
get /zk watch 就对一个节点的数据内容变化事件注册了监听
create -e /zk “myData” 创建临时znode节点
create -s /zk “myData” 创建顺序znode节点
create -e -s /zk “myData” 创建临时的顺序znode节点
delete /zk 只能删除没有子znode的znode
rmr /zk 不管里头有多少znode，统统删除
stat /zk 查看/zk节点的状态信

1.zk的数据保存在znode上，每个节点就是一个znode,多个znode构成一个树的目录结构

​

这样的层级结构使每个znode拥有唯一的路径，就像命名空间一样对不同信息作出清晰隔离。

2.znode的结构

data: znode中的数据

acl: 权限 

        c: create

        d: delete

        w: write

        r: read

        a: admin.  进行权限设置

stat: znode元数据（zxid......）

child: znode子节点

3.znode节点类型

1）持久化目录节点（PERSISTENT）

客户端与zookeeper断开连接后，该节点依旧存在

（2）持久化顺序编号目录节点（PERSISTENT_SEQUENTIAL）

客户端与zookeeper断开连接后，该节点依旧存在，只是Zookeeper给该节点名称进行顺序编号

（3）临时目录节点（EPHEMERAL）

客户端与zookeeper断开连接后，该节点被删除。zk-cli和zk-server之间会有一个sessionid，zk-cli和zk-server会话时会持续刷新sessionid过期时间，zk-server每隔一段时间会去检测sessionID，如果sessionID过期，会删除这个sessionID创建的临时节点。

（4）临时顺序编号目录节点（EPHEMERAL_SEQUENTIAL）

客户端与zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称进行顺序编号

（5）容器节点（CONTAINER）:当容器节点没有任何子节点时，会被zk定期删除（60s）

（6）TTL节点

1.事物日志：zk执行的命令以日志的的形式保存在datadir目录中。

2.数据快照：每隔一段时间进行一次快照。

1.普通删除：delete /zk

2.乐观锁删除：在删除期间没有其他客户端对当前节点做修改时删除成功，一旦修改过就会删除失败。delete -v  1 /zk.通过版本号实现

1.注册用户名密码：addauth digest  xxx;123

2.创建节点时加上权限：create /test abc auth:xxx:123:cdwra

1.zk分布式锁

        读锁：是一个共享锁，要想上读锁前提是没有写锁。

        读锁实现：（1）在/lock节点创建临时顺序节点。

                           （2）获取/lock节点下的所有比自己序号小的节点。

                           （3）判断序号最小的节点是不是写锁，如果不是加锁成功，如果是上锁失                                       败给最小节点加watch，最小节点释放后回到第二步骤。

写锁：只有得到写锁才能写，要想上写锁，之前必须没有任何锁

        读锁实现：（1）在/lock节点创建临时顺序节点。

                           （2）获取/lock节点下的所有比自己序号小的节点。

                           （3）判断序号最小的节点是不是自己，如果是加锁成功，如果不是上锁失                                       败给最小节点加watch，最小节点释放后回到第二步骤。

注意：这种上锁方式会导致羊群效应。即当最小节点释放后，之后的所有watch最小节点的所有节点都会触发监听事件，这样会对zk造成很大压力。

解决羊群效应：链式监听，节点只watch自己的上一个节点。

 watch机制：客户端去监听一个节点，当这个节点发生create、delete、setdata时就会触发监听事件，客户端会收到异步通知。

1.启动选举leader：

​

2.崩溃时leader选举

leader不断向follower发送心跳（ping命令，没有内容的socket），当leader崩溃后，follower发现socket通道关闭，于是修改状态为looking，回答启动时选举。

3.同步数据

​ 

注意：leader可以读和写，follower只能读，所以当客户端发送写请求给follower时，follower会把数据给leader由leader写入。 

十一. CAP

指的是在一个分布式系统中，

Consistency(一致性)、

Availability(可用性。任何时候都是可用的正常响应的，比如分布式系统在两个节点同步数据的时候依然提供服务，就表示满足A)、

Partition Tolerance(分区容错性,冗余部署)，

只能满足其中之二。 分布式环境中p是必须的所以只能在C 和 A 中取舍，zk满足AP，追求的是CP，它不是强一致性而是顺序一致性（事物ID）

zk官方文档

ZooKeeper: Because Coordinating Distributed Systems is a Zoohttps://zookeeper.apache.org/doc/current/zookeeperStarted.html

 curator官方

Apache Curator – https://curator.apache.org/getting-started.html