1 什么是 Zookeeper ？
在学习一样东西之前，我们总得知道这样东西是什么吧。下面我们来看一下百度百科对 Zookeeper 的简介：
ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。
好吧，上面的解释有点难懂，实际上我们可以这样理解，Zookeeper 是一个添加了监听通知机制的文件处理系统。
2 为什么我们要学 Zookeeper ？
或者说，Zookeeper 有什么作用？要知道，我们学习新知识，一般有两种情况，要么就是我们很闲很无聊，纯属消磨时间，要么就是我们现有的知识无法解决现有的问题。若连"为什么要学"都不清楚，是很难获得正反馈的。
问：我们为什么要学习 Zookeeper ？
答：在分布式系统中，如果各个节点间信息不能及时共享和同步，那么就会在协作过程中产生各种问题。ZooKeeper 的出现就是为了解决分布式系统信息的一致性问题。
3 znode
我们之前说过，Zookeeper 是一个添加了监听通知机制的文件处理系统。那么，这个文件系统的数据保存在哪里呢？
事实上，Zookeeper 的数据保存在被称为 znode 的数据节点上，而且数据形式为字节数组。
3.1 znode 的结构
znode 采用了层级树状结构来进行管理。例子如下：
我们可以发现，根节点 / 拥有4个子节点，其中除了 /master 之外都拥有下一级节点。
3.2 数据节点的介绍
- /master：存储主节点的信息，若在主从模式中其没有数据，代表分布式应用的主节点还没有被选举出来。
- /workers：下面的每个子 znode 代表一个从节点。
- /tasks：下面的每个子 znode 代表一个任务，znode 上存储的信息代表着任务内容。
- /assign：下面每个子 znode 代表一个从节点的任务集合。/assign/worker-1 代表从节点 worker-1 的任务集合，其下面的子 znode 都是分配给 worker-1 的任务。
3.3 znode 的分类
- PERSISTENT（持久化目录节点）：即使客户端与 Zookeeper 断开连接，该节点依然存在。
- PERSISTENT_SEQUENTIAL（持久化顺序编号目录节点）：即使客户端与 Zookeeper 断开连接，该节点依然存在，与 PERSISTENT 不同的是，Zookeeper 会对该节点名称进行顺序编号。
- EPHEMERAL（临时目录节点）：客户端与 Zookeeper 断开连接后，该节点将被删除。
- EPHEMERAL_SEQUENTIAL（临时顺序编号目录节点）：客户端与 Zookeeper 断开连接后，该节点将被删除，与 EPHEMERAL 不同的是，Zookeeper 会对该节点名称进行顺序编号。
需要注意，/master 应该使用临时节点，这样当主节点失效或者退出时，其他节点会知道主节点已崩溃，开始进行选举。
4 事件监听器
我们之前已经介绍过 Zookeeper 的文件处理，现在我们来讲讲它的监听通知机制，事实上，这是通过事件监听器实现的。
用户可以在 Zookeeper 的一些节点上注册一些事件监听器，在特定事件触发时，ZooKeeper 服务端会将事件通知到客户端上。其中，事件监听器又被称为 Watcher。
5 Zookeeper 的角色
- leader：领导者。leader 作为整个 ZooKeeper 集群的主节点，负责响应所有对 ZooKeeper
状态变更的请求。它会将每个状态更新请求进行排序和编号，以便保证整个集群内部消息处理的 FIFO 。leader 为客户端提供读和写服务。 - follower：追随者。follower 除了需要响应本服务器上的读请求外，还要处理 leader 的提议，并在 leader 提交提议时在本地也进行提交。需要注意的是，leader 和 follower 共同构成了 ZooKeeper 集群的法定人数，也就是说，只有他们才参与新 leader 的选举、响应 leader 的提议。
- observer：观察者。若 ZooKeeper 集群的读取负载很高，可以设置一些 observer 服务器，以提高读取的吞吐量。observer 和 follower 比较相似，但还是具有两个区别：一是 observer 不属于法定人数，即不参加选举也不响应提议；二是 observer 不需要将事务持久化到磁盘，一旦 observer 被重启，需要从 leader 重新同步整个名字空间。
需要注意，一个 ZooKeeper 集群同一时刻只会有一个 Leader，其他都是 Follower 或 Observer。
6 客户端会话
客户端会话，即 Session。客户端启动时，首先会与服务器建立一个TCP 连接，从第一次连接建立开始，客户端会话的生命周期也开始了，通过这个连接，客户端能够通过心跳检测和服务器保持有效的会话，也能够向 ZooKeeper 服务器发送请求并接受响应，同时还能通过该连接接收来自服务器的 Watch 事件通知。
如果由于服务器压力太大、网络故障或是客户端主动断开连接等各种原因导致客户端连接断开时，只要在客户端会话超时时间内能够重新连接上集群中任意一台服务器，那么之前创建的会话仍然有效。
7 Zookeeper 的最终的一致性
在分布式应用中，客户端需要及时知道 Zookeeper 中 znode 的变化，为了减少资源的支出，Zookeeper 采用了通知的机制。客户端会在特定的 znode 设立观察点，若 znode 发生变化，会触发 Zookeeper 的通知，将信息传递给客户端。我们需要注意，观察点在触发后会失效，故我们需要在观察点失效之后重新设置观察点。
我们现在想象如下情景，客户端在某任务处设置了一个观察点。在观察点触发后，客户端开始处理自己的业务逻辑，但不巧的是，在该客户端设立新的观察点之前，另一个客户端更新了该任务 。所以，等到客户端设立新的观察点，它已经错过了一次更新，相当于客户端以一次更新读取了两次更新之后的数据。总的来说，客户端虽然错过了第二次更新，但它还是获得了最新的数据。
所以我们说，Zookeeper 无法保持强一致性，只能保持最终一致性。
8 版本号
每个 znode 都具有一个版本号，每次数据变化都会进行一次自增操作。在多个客户端对同一个 znode 进行操作的时候，版本号将起到至关重要的作用。我们可以想象这样一个场景，客户端1与客户端2同时修改一个 znode 的数据，客户端1先完成同时 znode 的版本号也发生了升级，但客户端2修改的时候会携带原来的版本号，这会导致修改失败。
9 事务操作
事务操作即改变 ZooKeeper 服务器状态的操作，如数据节点的创建与删除、数据内容的更新和客户端会话创建与失效都属于事务操作。ZooKeeper 会为每一个事务请求分配一个全局唯一的事务 ID，用 ZXID 表示，通常是一个64位的数字。每一个 ZXID 对应一次更新操作，从这些 ZXID 中可以间接地识别出 ZooKeeper 处理这些事务操作请求的全局顺序。
参考：原创ZooKeeper入门实战教程（一）-介绍与核心概念
ZooKeeper的三种角色
5分钟让你了解 ZooKeeper 的功能和原理
