工作机制

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

特点

1.一个leader，多个follower组成的集群
2.集群中半数以上节点存活，zk就能正常服务，所以zk适合安装奇数节点
3.全局数据一致：每个Server保存一份相同的数据副本，Client无论连接哪个server，数据都一致
4.更新请求顺序执行，来自同一个client的更新请求按其发送顺序依次执行
5.数据更新原子性：一个更新要么成功，要么失败
6.实时性，在一定时间范围内，Client能读到最新数据

数据结构

树形，每个znode默认能够存储1MB的数据，每个znode通过其路径唯一标识。

应用场景

统一命名服务

图片.png

统一配置管理

图片.png

统一集群管理

图片.png

服务器节点动态上下线

图片.png

软负载均衡

图片.png

zookeeper集群

clientPort=2181 客户端连接端口，通常不做修改
dataDir:保存zk数据
tickTime=2000 zk服务器与客户端心跳时间
initLimit=10 LF初始通信时限。Leader和follower初始连接时能容忍的最多心跳数（tickTime数量）
syncLimit=5 LF同步通信时限。leader和follower通信时间如果超过syncLimit*tickTime，leader认为follower撕掉，从服务器列表移除follower

选举机制

节点数据内容

1.czxid：创建节点的事务zxid
2.ctime：创建时间
3.mtime:最后修改时间
4.mzxid：最后更新的事务id
5.pzxid:znode最后更新的子节点zxid
6.cversion：znode子节点修改次数（子节点变化号）
7.dataversion:znode数据修改次数（数据变化号）
8.aclVersion：访问控制列表的变化号
9.ephemeralOwner:如果是临时节点，这是znode的sessionid，否则为0
10.dataLength:znode数据长度
11.numChildren:子节点数量

监听原理

1.main线程中创建zkCli，这时会创建两个线程，一个负责网络连接通信（connect），一个负责监听（listener）。
2.通过connect把监听事件发送给zk。
3.zk把监听事件添加到监听器列表中
4.zk监听到变化，将消息发送给listener线程
5.listener内部调用process方法

客户端向服务端写数据

图片.png
图片.png

zk分布式锁

Curator框架实现分布式锁

注：生产集群安装多少zk合适：10台服务器3zk，20台服务器5zk，100服务器11zk，200服务器11zk