ZooKeeper是一个开源的分布式协调服务，由雅虎创建，是Google Chubby的开源实现。ZooKeeper的设计目标是将那些复杂且容易出错的分布式一致性服务封装起来，构成一个高效可靠的原语集，并以一系列简单易用的接口提供给用户使用。分布式应用程序可以基于它实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master选举、分布式锁和分布式队列等功能。
简单来说ZooKeeper 实现了支持订阅通知机制的文件系统。

整体结构

image.png

• 节点个数：奇数
• 集群角色：Leader、Follower、Observer
• 正常工作条件：超过半数以上节点存活且通信正常
• 数据备份：各个节点存储全量数据，读性能高
• 数据存储：内存数据库，性能高
• 会话保持：超时时间内重连，上下文可恢复
• 一致性保证：ZAB分布式一致性协议

工作特性

• CP，保证一致性及分区容错性
• 高可靠
  一半以上节点正常即可正常工作；leader挂掉可再选主接管
• 高性能
  Observer不参与选主及写入投票；所有节点有全量数据支持读操作
• 操作保证原子性
• 同一个客户端的请求严格保证顺序
• 一旦收到ZK响应，便一定生效
• 数据修改并发控制采用乐观锁
• 支持订阅，变化时有异步事件通知，且保证顺序
• 支持权限控制

数据模型

简单来说维护了由节点（Znode）组成的文件系统。

image.png

1. 节点类型
   永久节点、永久顺序节点、临时节点、临时顺序节点

2. 节点结构
   节点属性（stat）、节点内容（data）、子节点（children）

   
   image.png

3. 节点操作
   增、删、改、查、是否存在

   
   image.png

WATCH机制

一个事件包含KeeperState和EventType两部分，分别表示通知状态和事件类型。主要有以下几种组合：

image.png

KeeperState

有以下几种状态：

• KeeperState.Expired 客户端和服务器在ticktime的时间周期内，是要发送心跳通知的。这是租约协议的一个实现。客户端发送request，告诉服务器其上一个租约时间，服务器收到这个请求后，告诉客户端其下一个租约时间是哪个时间点。当客户端时间戳达到最后一个租约时间，而没有收到服务器发来的任何新租约时间，即认为自己下线（此后客户端会废弃这次连接，并试图重新建立连接）。这个过期状态就是Expired状态
• KeeperState.Disconnected 就像上面那个状态所述，当客户端断开一个连接（可能是租约期满，也可能是客户端主动断开）这是客户端和服务器的连接就是Disconnected状态
• KeeperState.SyncConnected 一旦客户端和服务器的某一个节点建立连接（注意，虽然集群有多个节点，但是客户端一次连接到一个节点就行了），并完成一次version、zxid的同步，这时的客户端和服务器的连接状态就是SyncConnected
• KeeperState.AuthFailed zookeeper客户端进行连接认证失败时，发生该状态

EventType

主要有以下几种：

• EventType.NodeCreated 当node-x这个节点被创建时，该事件被触发
• EventType.NodeChildrenChanged 当node-x这个节点的直接子节点被创建、被删除、子节点数据发生变更时，该事件被触发。
• EventType.NodeDataChanged 当node-x这个节点的数据发生变更时，该事件被触发
• EventType.NodeDeleted 当node-x这个节点被删除时，该事件被触发。
• EventType.None 当zookeeper客户端的连接状态发生变更时，即KeeperState.Expired、KeeperState.Disconnected、KeeperState.SyncConnected、KeeperState.AuthFailed状态切换时，描述的事件类型为EventType.None

EventType与操作的对应关系如下：

image.png

WATCH机制特点

• 推拉结合
  服务端只告诉你有事件产生，具体内容需要客户端再查询，降低服务端压力
• 异步通知
  需要考虑事件处理过程中，又有事件产生
• 注册一次性
  处理完成后需要再次注册
• 保证收到事件顺序正确性
• 支持会话保持，超时时间内断线重连，监测点保持

集群运行方式

单机模式、集群模式、伪集群模式
伪集群模式配置文件如下：

image.png