Zookeeper数据类型、节点类型、角色、watcher监听机制

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在处理事务性请求时，比处理非事务性请求要复杂很多