Zookeeper 简介

Zookeeper 架构

• 客户端随机连接集群中的任何一台 server

• 集群内所有的 server 基于 Zab(ZooKeeper Atomic Broadcast)协议通信

• 集群内部根据算法自动选举出 leader, 负责向 follower 广播所有变化消息

• 集群中每个follower 都和 leader 通信

• follower 接收来自 leader 的所有变化消息,保存在自己的内存中

• follower 转发来自客户端的写请求给 leader（再由leader广播给各个follower，当半数以上follower将修改持久化后，leader才会提交这个更新，接下来客户端才会收到一个更新成功的响应）

• 客户端的读请求会在 follower 端直接处理,无需转发给 leader

 

server状态（只有server参与选举）：

• Looking（选举状态）
• Leading（领导者状态，表明当前server是leader）
• Following（跟随者状态，表明当前server是Follower）
• Observing（观察者状态、表明当前server是Observer）。

Zookeeper选举原理 https://www.cnblogs.com/scuwangjun/p/9063149.html

Zookeeper 数据模型

• 基于树形结构的命名空间,与文件系统类似

• 节点(znode)都可以存储数据,可以有子节点

• 节点不支持重命名

• 数据大小不超过1MB(可配置)

• 数据读写保持完整性

Znode 节点类型

PERSISTENT                               持久化节点
PERSISTENT_SEQUENTIAL      顺序自动编号持久化节点，这种节点会根据当前已存在的节点数自动加 1
EPHEMERAL                               临时节点， 客户端session超时这类节点就会被自动删除
EPHEMERAL_SEQUENTIAL      临时自动编号节点

自动编号节点 实际生成节点名末尾自动添加一个10位长度,左边以0填充的单递增数字，eg：address0000000442

临时节点  在客户端session结束或超时后自动删除

ZooKeeper Session

• 客户端和 server 间采用长连接

• 连接建立后, server生成 session id(64位)返还给客户端

• 客户端定期发送 ping 包来检查和保存和 server 的连接

• 一旦 session 结束或超时,所有 ephemeral节点会被删除

• 客户端可根据情况设置合适的 session 超时时间

Zookeeper Watcher

• Watch 是客户端安装在 server 的事件监听方法

• 当监听的节点发生变化, server 将通知所有注册的客户端

• 客户端使用单线程对所有事件按顺序同步回调

• 触发回调条件:

• 客户端连接,断开连接

• 节点数据发生变化

• 节点本身发生变化

注意:

1. Watch 是单次的,每次触发后会被自动删除

2. 如果需要再次监听时间,必须重新安装 Watch（Zookeeper客户端Curator可以不用每次重新安装监听）

Watch 的创建和触发规则

• 在读操作 exists、getChildren和getData上可以设置观察，这些观察可以被写操作create、delete和setData触发

参考如下：

https://www.cnblogs.com/skying555/p/6016530.html