分布式的、开源的，应用程序协调服务，是Hadoop和Hbase的重要组件
提供通用的分布式锁服务，用以协调分布式应用
zookeeper=文件系统+监听通知机制
应用场景
- 担任生产者和服务消费者的注册中心
- 分布式应用配置管理
- 统一命名服务
- 状态同步服务
- 集群管理
容错：宕掉节点个数必须小于剩下的。用2n-1台和2n台效果一样
重要基础概念
-
Session
指Zookeeper服务器与客户端会话，客户端与服务器连接使用TCP协议。客户端能够通过心跳检测与服务器保持有效的会话，也能够向Zookeeper服务器发送请求并接受响应，同时还能够来自服务器的Watch事件通知。
sessionTimeout会话的超时时间，只要在sessionTimeout规定的时间内能够重新连接上集群中任意一台服务器，那么之前创建的会话仍然有效；sessionID，全局唯一 -
Znode
Zookeeper维护一个类似文件系统的数据结构，Znode 即数据模型（树状）中的数据单元。能够自由的增加、删除znode，在一个znode下增加、删除子znode。（与文件系统不同的是，znode可以存储数据）
有四种类型的znode：
（1）persistent——持久化目录节点：客户端与zookeeper断开连接后，该节点依旧存在。
（2）persistent-sequential ——持久化顺序编号目录节点：客户端与zookeeper断开连接后，该节点依旧存在，只是Zookeeper给该节点名称进行顺序编号。
（3）ephemeral——临时目录节点：客户端与zookeeper断开连接后，该节点被删除。
（4）ephemeral-sequential——临时顺序编号目录节点：客户端与zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称进行顺序编号。 -
版本信息Version
对于每个ZNode，Zookeeper都会为其维护一个State数据结构，Stat中记录了这个ZNode的三个数据版本，分别是Version——当前ZNode的版本，cversion——当前ZNode子节点的版本，aversion——当前ZNode的ACL版本。 -
Watcher
可以在指定节点上注册watcher，当事件发生时，zookeeper会通知感兴趣的客户端
客户端注册监听它，关心的是目录节点，当目录节点发生变化（数据改变、被删除、子目录节点增加删除） -
权限控制ACL
（1）CREATE：创建子节点的权限。
（2）READ：获取节点数据和子节点列表的权限。
（3）WRITE：更新节点数据的权限。
（4）DELETE：删除子节点的权限。
（5）ADMIN：设置节点的ACL权限。
其中CREATE和DELETE这两种权限都是针对子节点的控制权限。
执行流程
zookeeper分为Leader，Follower，Observer三种角色
（1）Leader election-选举阶段，节点在一开始都处于选举节点，只要有一个节点得到超半数节点的票数，它就可以当选准leader。
（2）Discovery-发现阶段，follower和准Leader进行通信，同步follower最近接受的事务提议。
（3）Synchronization-同步阶段，利用Leader在前一阶段获取到的最新提议历史，同步集群中所有副本，同步完成后，准Leader才成为真正的Leader。
（4）Broadcast-广播阶段，Zookeeper集群正式对外提供事务服务，并且Leader可以进行消息广播，同时如果有新节点加入，还需要对新节点进行同步。
Observer不参与选举和写操作
算法
Paxos算法，ZAB协议——作为其保证数据一致性的核心算法
参考资料：
https://www.cnblogs.com/jasonboren/p/13339144.html