概念
zookeeper是一款开源的分布式协调服务框架，为分布式环境提供了一致性服务的功能，常见应用场景有：发布订阅，主动通知，文件管理，集群管理，分布式锁等功能 zk在设计的时候满足了cp两要素，即一致性和分区容错性
zookeeper的设计理念
一致性
leader
数据树
zookeeper的设计目的
最终一致性：client不论连接到哪个Server，展示给它都是同一个视图，这是zookeeper最重要的性能
可靠性：具有简单、健壮、良好的性能，如果消息m被到一台服务器接受，那么它将被所有的服务器接受
实时性：Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。但由于网络延时等原因，Zookeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口
原子性：更新只能成功或者失败，没有中间状态
顺序性：包括全局有序和偏序两种：全局有序是指如果在一台服务器上消息a在消息b前发布，则在所有Server上消息a都将在消息b前被发布；偏序是指如果一个消息b在消息a后被同一个发送者发布，a必将排在b前面
ZooKeeper数据模型
Zookeeper会维护一个具有层次关系的数据结构，它非常类似于一个标准的文件系统
数据结构的特点
每个子目录项如NameService都被称作为znode，这个znode是被它所在的路径唯一标识，如Server1这个znode的标识为/NameService/Server1
znode可以有子节点目录，并且每个znode可以存储数据，注意EPHEMERAL（临时的）类型的目录节点不能有子节点目录
znode是有版本的（version），每个znode中存储的数据可以有多个版本，也就是一个访问路径中可以存储多份数据，version号自动增加
znode的类型
Persistent 节点，一旦被创建，便不会意外丢失，即使服务器全部重启也依然存在。每个 Persist 节点即可包含数据，也可包含子节点
Ephemeral 节点，在创建它的客户端与服务器间的 Session 结束时自动被删除。服务器重启会导致 Session 结束，因此 Ephemeral 类型的 znode 此时也会自动删除
Non-sequence 节点，多个客户端同时创建同一 Non-sequence 节点时，只有一个可创建成功，其它匀失败。并且创建出的节点名称与创建时指定的节点名完全一样。
Sequence 节点，创建出的节点名在指定的名称之后带有10位10进制数的序号。多个客户端创建同一名称的节点时，都能创建成功，只是序号不同
znode可以被监控，包括这个目录节点中存储的数据的修改，子节点目录的变化等，一旦变化可以通知设置监控的客户端，这个是Zookeeper的核心特性，Zookeeper的很多功能都是基于这个特性实现的
ZXID：每次对Zookeeper的状态的改变都会产生一个zxid（ZooKeeper Transaction Id），zxid是全局有序的，如果zxid1小于zxid2，则zxid1在zxid2之前发生
ZooKeeper Session
如果Client因为Timeout和Zookeeper Server失去连接，client处在CONNECTING状态，会自动尝试再去连接Server，如果在session有效期内再次成功连接到某个Server，则回到CONNECTED状态。client不能宣称自己的session expired，session expired是由Zookeeper Server来决定的，client可以选择自己主动关闭session
分支主题
ZooKeeper的工作原理
三种角色
角色：leader,follower,observer
四种状态
状态：leading,following,observing,looking
Zookeeper的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议（ZooKeeper Atomic Broadcast protocol）。Zab协议有两种模式，它们分别是恢复模式（Recovery选主）和广播模式（Broadcast同步）
为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（zxid）来标识事务。所有的提议（proposal）都在被提出的时候加上了zxid
每个Server在工作过程中有4种状态
LOOKING：当前Server不知道leader是谁，正在搜寻。
LEADING：当前Server即为选举出来的leader。
FOLLOWING：leader已经选举出来，当前Server与之同步。
OBSERVING：observer的行为在大多数情况下与follower完全一致，但是他们不参加选举和投票，而仅仅接受(observing)选举和投票的结果。
ZooKeeper Watch
Zookeeper watch是一种监听通知机制。Zookeeper所有的读操作getData(), getChildren()和 exists()都可以设置监视(watch)，监视事件可以理解为一次性的触发器
（一次性触发）One-time trigger
（发送至客户端）Sent to the client
Consistency Guarantees
顺序一致性（Sequential Consistency）：从一个客户端来的更新请求会被顺序执行。
原子性（Atomicity）：更新要么成功要么失败，没有部分成功的情况。
可靠性（Reliability）：更新一旦有效，持续有效，直到被覆盖。
时间线（Timeliness）：保证在一定的时间内各个客户端看到的系统信息是一致的。
Leader Election
Zk的选举算法有两种：一种是基于basic paxos实现的，另外一种是基于fast paxos算法实现的。系统默认的选举算法为fast paxos
要使Leader获得多数Server的支持，则Server总数必须是奇数2n+1，且存活的Server的数目不得少于n+1
Leader工作流程
恢复数据；
维持与follower的心跳，接收follower请求并判断follower的请求消息类型；
题目
ZooKeeper提供了什么
四种类型的znode
Zookeeper文件系统
Zookeeper通知机制
Zookeeper做了什么
zk的命名服务
zk的配置管理（文件系统、通知机制）
Zookeeper集群管理（文件系统、通知机制）
Zookeeper分布式锁（文件系统、通知机制）
获取分布式锁的流程
基于BaseDistributedLock实现了基于Zookeeper实现分布式锁的细节
12.Zookeeper队列管理（文件系统、通知机制）
同步队列，当一个队列的成员都聚齐时，这个队列才可用，否则一直等待所有成员到达。
队列按照 FIFO 方式进行入队和出队操作。
13.Zookeeper数据复制
Zookeeper作为一个集群提供一致的数据服务，自然，它要在所有机器间做数据复制。数据复制的好处
14.Zookeeper工作原理
15.zookeeper是如何保证事务的顺序一致性的？
16.Zookeeper 下 Server工作状态
17.zookeeper是如何选取主leader的？
18.Zookeeper同步流程
19.分布式通知和协调
20.机器中为什么会有leader？
21.zk节点宕机如何处理？
22.zookeeper负载均衡和nginx负载均衡区别
23.zookeeper watch机制
一次性触发数据发生改变时，一个watcher event会被发送到client，但是client只会收到一次这样的信息
数据监视Zookeeper有数据监视和子数据监视getdata() and exists()设置数据监视，getchildren()设置了子节点监视
注册watcher getData、exists、getChildren
触发watcher create、delete、setData
Watch是轻量级的，其实就是本地JVM的Callback
节点属性
cZxid 当前数据结点创建时的事务ID
dataVersion：当前结点数据的发生更改的次数
ctime：当前数据结点创建时的时间
mZxid：当前数据结点最后一次更新时的事务ID
mtime：当前数据结点最后一次更新时的时间
