1、Zookeeper数据类型：
层次化目录结构+少量数据
Zookeeper包含层次化的目录结构，每个Znode都有唯一的路径标识，Znode可以包含数据和子节点。
其中Znode数据可以有多个版本，若该路径下包含多个数据版本，查询这个路径下的数据时，需要带上版本。
2、Zookeeper节点类型：
临时节点（ephemeral）、持久节点（persistent）、顺序节点（sequence）。节点类型在创建时确定，之后不可修改。
（1）临时节点在客户端会话结束后，zookeeper会将该临时节点删除，且临时节点不可有子节点。
（2）持久节点不依赖于客户端的会话，只有客户端明确要删除该持久节点，才会将其删除。
也可以说是四种：
（1）PERSISTENT-持久节点除非手动删除，否则节点一直存在于 Zookeeper 上
（2）EPHEMERAL-临时节点临时节点的生命周期与客户端会话绑定，一旦客户端会话失效（客户端与zookeeper 连接断开不一定会话失效），那么这个客户端创建的所有临时节点都会被移除。
（3）PERSISTENT_SEQUENTIAL-持久顺序节点基本特性同持久节点，只是增加了顺序属性，节点名后边会追加一个由父节点维护的自增整型数字。
（4）EPHEMERAL_SEQUENTIAL-临时顺序节点基本特性同临时节点，增加了顺序属性，节点名后边会追加一个由父节点维护的自增整型数字。
3、Zookeeper角色：
leader领导者、follower跟随者、observer观察者、client客户端
（1）leader：负责投票的发起和决议，更新系统状态，处理事务请求。
（2）follower跟随者：参与投票，接收客户端请求，处理非事务请求并返回结果，转发事务请求给leader。
（3）observer观察者：不参与投票过程，只同步leader状态，为了扩展系统，提高读写速度。也接收客户端请求，处理非事务请求并返回结果，转发事务请求给leader。
（4）client客户端：请求发起方。
4、Watcher监听机制：
（1）监控目录节点数据变化
（2）监控子目录变化
（3）一旦这些节点发生变化，服务器就会通知所有设置在这个目录节点上的Watcher，使得每个客户端都很快知道其关注的目录节点的状态发生变化，从而做出相应反应。
节点类型和Watcher监听机制，是解决所有应用场景问题的出发点和落脚点。
补充：
1、事务性请求
Zookeeper通常都是以集群模式运行的，也就是Zookeeper集群中各个节点的数据需要保持一致的。但是和Mysql集群不一样的是：
-
Mysql集群中，从服务器是异步从主服务器同步数据的，这中间的间隔时间可以比较长。
-
Zookeeper集群中，当某一个集群节点接收到一个写请求操作时，该节点需要将这个写请求操作发送给其他节点，以使其他节点同步执行这个写请求操作，从而达到各个节点上的数据保持一致，也就是数据一致性。我们通常说Zookeeper保证CAP理论中的CP就只这个意思。
Zookeeper集群底层是怎么保证数据一致性的，其实是用的两阶段提交+过半机制来保证的。
事务性请求包括：更新操作、新增操作、删除操作，结合上面的分析，因为这些操作是会影响数据的，所以要保证这些操作在整个集群内的事务性，所以这些操作就是事务性请求。
2、非事务性请求
那么非事务性请求就好理解的，像查询操作、exist操作这些不影响数据的操场，就不需要集群来保持事务性，所以这些操场就是非事务性请求。
Zookeeper在处理事务性请求时，比处理非事务性请求要复杂很多