Zookeeper之功能篇章

一、集群角色

Leader：

• 事物请求的唯一调度和处理者，保证集群事物处理的顺序性
• 集群内部各服务器的调度者

Follower：

• 处理客户端非事物请求、转发事物请求给leader服务器
• 参与事物请求 Proposal 的投票（需要半数以上服务器 通过才能通知leader commit数据; Leader发起的提案， 要求Follower投票）
• 参与Leader选举的投票

Observer：是 zookeeper3.3 开始引入的一个全新的服务器角色。

• 观察zookeeper集群中的最新状态变化并将这些状态变化 同步到 observer 服务器上。Observer 的工作原理与 follower 角色基本一致，
• 只提供非事物请求服务，没有选举和投票的资格，通常在于不影响集群事物 处理能力的前提下提升集群非事物处理的能力 (例：选举时)

二、数据模型

Zookeeper 的视图结构和标准的文件系统非常类似，每一个节点称之为ZNode，是Zookeeper的最小单元。每个Znode 上都可以保存数据以及挂载子节点。构成一个层次化的树形结构。

1、持久节点（PERSISTENT）

创建后会一直存在 zookeeper 服务器上，直到主动删除

2、持久有序节点（PERSISTENT_SEQUENTIAL）

每个节点都会为它的一级子节点维护一个顺序

3、临时节点（EPHEMERAL）

临时的生命周期和客户端的回话绑定在一起，当客户端回话失效该节点自动清理

4、临时有序节点（EPHEMERAL）

在临时节点的基础上多了一个顺序性

三、会话

• Client 初始化连接，状态转化为 CONNECTING ①
• Client 与 Server 成功建立连接，状态转为 CONNECTED ②
• Client 丢失了与 Server 的连接或者没有接受到 Server 的响应， 状态转为 CONNECTING ③
• Client 连上另外的 Server 或连接上了之前的 Server ， 状态转为 CONNECTED ②
• 若会话过期（是Server 负责生命会话过期，而不是Client），状态转化为CLOSED ⑤
• Client 也可以主动关闭回话 ④ ，状态转化为 CLOSED

四、Stat状态信息

每个节点除了存储数据内容以外，还存储了数据节点本身的一些状态信息，通过 get 命令可以获得状态信息的详细内容

状态属性		说明
cZxid	0x0	即Created ZXID，表示该数据节点被创建时的事务ID
ctime	Wed Dec 31 19:00:00 EST 1969	即Created Time，表示节点被创建的时间