说明： 该篇文章是我18年在公司给团队分享的一个ZooKeeper技术应用主题， 仅做为大家参考。
ZooKeeper是一个开源的高可用、高性能且一致的分布式协调服务，其基本工作原理为分布式锁服务，由雅虎公司创建和开源，是类似于Google Chubby的开源实现版本。
ZooKeeper的设计目标是将那些复杂且容易出错的分布式一致性服务进行封装，构建一个高效可靠的原语集， 并以一系列简单易用的接口提供给用户使用。ZooKeep是一个典型的分布式数据一致性的解决方案。分布式应用程序可以基于它实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master选举、分布式锁和分布式队列等功能；
ZooKeeper性能上的特点决定了它能够在大型的、分布式的系统当中起着重要的作用，从可靠性方面来说，它并不会因为一个节点的错误而崩溃。
ZooKeeper常用于以下应用场景：
- 命名服务
- 配置管理
- 集群管理
- 选举算法
- 锁定与同步服务
- 数据注册中心
ZooKeeper架构中包括四个角色：
- Leader（领导者）， 它负责进行集群投票的发起和决议，并更新系统状态；
- Follower（跟随者）， 用于接收客户请求并向客户端返回结果，并在选举Leader节点过程中参与投票；
- Observer（观察者），它可以接收客户端连接，将写请求转发给Leader节点。它不参与Leader选举的投票过程，只用于同步Leader的状态；
- Client（客户端），它用于发起请求连接分布式应用集群中的一个节点，从服务器访问信息。
为了解决分布式场景下数据一致性的问题， ZooKeeper支持Paxos、ZAB和RAFT的分布式数据一致性算法，构建一个去中心化的分布式应用。
ZooKeeper数据模型中的每一个ZNode节点都维护着一个stat结构， 用于存储节点的状态信息。一个stat信息仅提供一个ZNode的元数据信息，该元数据信息由版本号、访问控制列表、时间戳和数据长度组成。
ZooKeeper的节点包括以下三种类型：
- 持久节点
- 顺序节点
- 临时节点
ZooKeeper采用层级的命名空间， 这个与标准的文件系统比较相似。
会话对于ZooKeeper的操作非常重要，会话中的请求按FIFO（先进先出）顺序执行。一旦客户端连接到服务器，将建立会话并向客户端分配会话ID。
ZooKeeper允许用户在指定节点上注册一些监视器(Watcher)，并且在一些特定事件触发的时候，ZooKeeper会通过事件通知到感兴趣的客户端上。
ZooKeeper的目标是基于自身去构建更为复杂的分布式应用场景，例如分布式数据库、分布式消息系统和分布式搜索引擎这类实时性要求很高的系统，所以自身被设计得非常快速 、简单， 同时，为了能支撑分布式场景下事务的一致性。
一旦ZooKeeper集群启动之后，它将等客户端进行连接。客户端连接到ZooKeeper集群中的某一个节点，它可以是Leader或Follower节点。 一旦客户端连接成功， 节点将向特定客户端分配会话ID并向客户端发送连接确认。如果客户端没有收到确认信息， 它将尝试连接至ZooKeeper集群中的其他节点。一旦连接到ZooKeeper集群节点，客户端将有规律的时间间隔向ZNode节点发送心跳信息， 以确保连接不会丢失。
ZooKeeper提供一些常用的查询命令，用于获取ZooKeeper服务的当前状态等相关信息。
