当ZooKeeper集合启动时，它会等待客户端连接。客户端将连接到ZooKeeper的集合的其中一个节点。它可能是一个领导者或跟随者节点。当客户机连接时，该节点分配会话ID给特定的客户端，并发送一个确认消息给客户端。如果客户端没有得到确认，它会尝试连接ZooKeeper集合的另一个节点。当连接到一个节点后，客户端将以规则的间隔发送心跳到节点，以确保连接不会丢失。
-
如果客户想要读取特定的znode，它发送一个读请求使用znode路径的节点，所述节点从其自己的数据库中获取它返回所请求的znode。出于这个原因，读取在动物园管理员集合中速度非常快。
-
如果客户希望将数据存储在ZooKeeper 集合，它发送znode路径和数据到服务器。连接的服务器将请求转发到领导者，那么领导者将重新发出书面请求到所有的追随者。如果只有一个数节点成功响应，接着写请求将成功及一个成功的返回代码将被发送到客户端。否则，写请求将失败。严格大部分节点被称为定额。
ZooKeeper集合的节点
让我们来分析ZooKeeper集合不同数量的节点的作用。
-
如果我们有一个节点，那么当该节点出现故障时ZooKeeper集合失败。它有利于“单一失败教程”，它不建议用在生产环境中。
-
如果我们有两个节点，一个节点出现故障，我们也没有“多数”，因为二分之一并不是一个大多数。
-
如果我们有三个节点及其一个节点发生故障，我们有大多数，因此它是最低要求。它强制 ZooKeeper 集合在实际生产环境中至少有三个节点。
-
如果我们有四个节点及其有当两个节点失败，它类似于有三个节点。额外的节点没有任何作用，因此，最好是单数增加节点，例如，3, 5, 7.
我们知道，写处理它比在 ZooKeeper 集合读过程是昂贵的，由于所有的节点需要写相同的数据在其数据库中。因此，最好是具有节点（3，5或7）比具有大量节点的一个平衡的环境的数量少。
下图描述了ZooKeeper 的工作流程以及在随后的表说明了其不同的组件。
| 组件 | 描述 |
|---|---|
| 写入 | 写过程是由领导节点处理。领导者转发写请求到所有znodes及其等待来自znodes应答。如果一半的znodes的回复，那么写入过程就完成了。 |
| 读取 | 读取在内部由特定连接znode进行的，所以没有必要与集群交互。 |
| 复制数据库 | 它是用来将数据存储在zookeeper。每个znode都有自己的数据库及其每个znode 在一致性的作用下，每次有相同的数据。 |
| 领导者（节点） | 领导者是由Znode负责处理写请求。 |
| 追随者（节点） | 追随者收到来自客户端的写请求，并将其转发到领导znode。 |
| 请求处理器 | 目前仅在领导节点。它从跟随节点的请求支配写入。 |
| 原子广播 | 负责从领导节点到从节点广播更改。 |
