简介

ZooKeeper 是一个开放源码的分布式协调服务，提供类似UNIX文件系统、通知机制

使用场景

分布式应用程序可以基于 Zookeeper 实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能，另一篇文章介绍

文件系统

Zookeeper 提供一个多层级的节点命名空间（节点称为 znode）。与文件系统不同的是，这些节点都可以设置关联的数据，而文件系统中只有文件节点可以存放数据而目录节点不行。

Zookeeper 为了保证高吞吐和低延迟，在内存中维护了这个树状的目录结构，这种特性使得 Zookeeper 不能用于存放大量的数据，每个节点的存放数据上限为1M。

ZNODE类型

（1）PERSISTENT-持久节点
除非手动删除，否则节点一直存在于 Zookeeper 上

（2）EPHEMERAL-临时节点
临时节点的生命周期与客户端会话绑定，一旦客户端会话失效（客户端与zookeeper 连接断开不一定会话失效），那么这个客户端创建的所有临时节点都会被移除。

（3）PERSISTENT_SEQUENTIAL-持久顺序节点
基本特性同持久节点，只是增加了顺序属性，节点名后边会追加一个由父节点维护的自增整型数字。

（4）EPHEMERAL_SEQUENTIAL-临时顺序节点
基本特性同临时节点，增加了顺序属性，节点名后边会追加一个由父节点维护的自增整型数字。

通知机制

Zookeeper 允许客户端向服务端的某个 Znode 注册一个 Watcher 监听，当服务端的一些指定事件触发了这个 Watcher，服务端会向指定客户端发送一个事件通知来实现分布式的通知功能，然后客户端根据 Watcher 通知状态和事件类型做出业务上的改变。

工作过程：

• 客户端注册 Watcher
• 服务器处理 Watcher
• 客户端回调 Watcher（网上都是这样说，但是感觉是服务端回调客户端的Watcher好理解一点）

watcher的特点：

• 轻量级：一个callback函数。
• 异步性：不会block正常的读写请求。
• 主动推送：Watch被触发时，由Zookeeper服务端主动将更新推送给客户端。
• 一次性：数据变化时，Watch只会被触发一次。如果客户端想得到后续更新的通知，必须要在 Watch 被触发后重新注册一个 Watch。原因：如果服务端变动频繁，而监听的客户端很多情况下，每次变动都要通知到所有的客户端，给网络和服务器造成很大压力。
• 仅通知：仅通知变更类型，不附带变更后的结果。
• 顺序性：如果多个更新触发了多个Watch，那 Watch 被触发的顺序与更新顺序一致。

注意事项：

• 由于watcher是一次性的，所以需要自己去实现永久watch
• 如果被watch的节点频繁更新，会出现“丢数据”的情况
• watcher数量过多会导致性能下降

CAP理论

Zookeeper选择了CAP理论中的CP

zookeeper在选举leader时，会停止服务，直到选举成功之后才会再次对外提供服务，这个时候就说明了服务不可用，但是在选举成功之后，因为一主多从的结构，zookeeper在这时还是一个高可用注册中心，只是在优先保证一致性的前提下，zookeeper才会顾及到可用性

服务器角色

• Leader
  （1）事务请求的唯一调度和处理者，保证集群事务处理的顺序性
  （2）集群内部各服务的调度者
• Follower
  （1）处理客户端的非事务请求，转发事务请求给 Leader 服务器
  （2）参与事务请求 Proposal 的投票
  （3）参与 Leader 选举投票
• Observer
  （1）3.0 版本以后引入的一个服务器角色，在不影响集群事务处理能力的基础上提升集群的非事务处理能力
  （2）处理客户端的非事务请求，转发事务请求给 Leader 服务器
  （3）不参与任何形式的投票

工作状态

服务器具有四种状态，分别是 LOOKING、FOLLOWING、LEADING、OBSERVING。
（1）LOOKING：寻 找 Leader 状态。当服务器处于该状态时，它会认为当前集群中没有 Leader，因此需要进入 Leader 选举状态。
（2）FOLLOWING：跟随者状态。表明当前服务器角色是 Follower。
（3）LEADING：领导者状态。表明当前服务器角色是 Leader。
（4）OBSERVING：观察者状态。表明当前服务器角色是 Observer。

ZAB 协议

ZAB 协议是为分布式协调服务ZooKeeper专门设计的一种支持崩溃恢复的一致性协议。基于该协议，ZooKeeper 实现了一种主从模式的系统架构来保持集群中各个副本之间的数据一致性。

ZAB 协议包括两种基本的模式：崩溃恢复和消息广播。

消息广播

消息广播主要用于集群之间的数据同步，采用类似分布式事务中的2PC协议：
（1）Leader将客户端的request转化成一个Proposal（提议）
（2）Leader为每一个Follower准备了一个FIFO队列，并把Proposal发送到队列上。‘
（3）leader若收到follower的半数以上ACK反馈
（4）Leader向所有的follower发送commit。

崩溃恢复模式

当整个 zookeeper 集群刚刚启动或者 Leader 服务器宕机、重启或者网络故障导致不存在过半的服务器与 Leader 服务器保持正常通信时，所有进程（服务器）进入崩溃恢复模式

ZXID

为了保证事务的顺序一致性,zookeeper 采用了全局递增的事务 Id 来标识，所有的 proposal（提议）都在被提出的时候加上了 zxid，zxid 实际上是一个 64 位的数字，高 32 位是 epoch（ 时期; 纪元; 世; 新时代）用来标识 leader 周期，如果有新的 leader 产生出来，epoch会自增，低 32 位用来递增计数事务。

选举

• 每个Follower节点都向所有其它节点广播Vote投票请求，即请求自己成为Leader；
• 如果Follower接受到的Vote请求中的ZXID比自身的大，则投票同意，并更新自身的Vote，否则拒绝；
• 每个Follower都维护着一个投票记录表，当某个Follower节点收到过半的选票时，结束投票并把该Follower选为Leader。

同步

当选举出Leader后，该Leader具有全局最大的ZXID，所以同步阶段的工作就是根据Leader的事务日志对Follower节点进行数据同步：

• Leader节点根据Follower节点发送过来的FOllOWERINFO请求（包含Follower节点的最大ZXID），响应NEWLEADER消息告知自己已经成为它的新Leader；
• Leader节点根据Follower的最大ZXID（lastZXID），向Follower发送更新指令：
  SNAP ：如果Follower的数据太老，Leader将发送快照SNAP指令给Follower同步数据；
  DIFF ：发送从Follolwer.lastZXID到Leader.lastZXID的DIFF指令给Follower同步数据；
  TRUNC ：当Follower.lastZXID比Leader.lastZXID大时，Leader发送从Leader.lastZXID到Follower.lastZXID的TRUNC指令让Follower丢弃该段数据，即回滚；
• Follower同步成功后回复ACKNETLEADER；
• Leader会把该Follower节点添加到自己的可用Follower列表中。