有一段时间没写博客，今天想着把自己近几个月做的笔记分享一波。
前两个月我一直在看zk的视频：https://coding.imooc.com/learn/list/201.html 从开始看这位老师的视频，到现在有一年多，觉得这位老师讲的很不错，所以分享一波，接下来，我们步入正题。
第一：zookeeper主要目录结构
bin：主要的一些运行命令
conf：存放配置文件，其中需要修改zk.cfg
contrib:附加的一些功能
dist-maven:mvn编译后目录
docs：文档
recipes：案例demo代码
src：源码
第二：配置文件简介
zoo.cfg配置
ticktime：用于计算的时间单元。比如session超时：N*ticktime
initLimit：用于集群，允许从节点连接并同步到master节点的初始化时间，以ticktime的倍数来表示。
syncLimit：用于集群，master主节点与从节点之间发送消息，请求和应答时间长度。（心跳机制）
dataDir：必须配置 zk相关存储的数据
dataLogDir：日志目录，不配置会和dataDir共用目录。
clientPort：连接服务器端口，默认2181
第三：zk数据模型
zk:是一个树形结构，类似于前段开发组件tree.js
zk的数据模型也可以理解为Linux/unix文件目录：/usr/local.../
每个节点都称之为znode，它可以有子节点，也可以有数据
每个节点分为临时节点和永久节点，临时节点在客户端断开后就消失
每个zk节点都各自的版本号，可以通过命令行来显示节点信息
每个节数据发生变化，那么该节点的版本号会累加（乐观锁）
删除/修改过时节点，版本号不匹配则会报错
每个zk节点存储的数据不宜过大，几k即可
节点可以设备权限acl，可以通过权限来限制用户的访问。
第四：zk作用体现
一：master节点选举，主节点挂了以后，从节点就会接受工作，并保证这个节点是唯一的，这也是所谓的首脑模式，从而保证我们的集群是高可用的。
二：统一配置文件管理，即只需要不熟一台服务器，则可以把相同配置文件同步更新到其他所哟与的服务器，次操作在云计算中用的特别的多（假设修改了redis统一配置）
三：发布与订阅，类似消息队列MQ（amq，rmq。。），dubbo发布者把数据存在znode上，订阅者会读取这个数据。
四：提供分布式锁，分布式环境不同进程之间争夺资源，类似于多线程中的锁。
五：集群管理，集群保证数据的强一致性。 主节点数据会同步到附属节点 客户端不管链接任何客户端的时候都会保证读取数据的一致性。