Zookeeper 工作流程
一旦 ZooKeeper 集成启动，它将等待客户端连接。客户端将连接到 ZooKeeper 集合中的节点之一。它可能是领导者或跟随者节点。一旦连接了客户端，节点就会为特定客户端分配一个会话 ID，并向客户端发送确认。如果客户端没有得到确认，它只是尝试连接 ZooKeeper 集合中的另一个节点。一旦连接到某个节点，客户端会定期向该节点发送心跳，以确保连接不会丢失。
如果客户端想要读取特定的 znode， 它会向具有 znode 路径的节点发送 读取请求，并且该节点通过从以下位置获取它来返回请求的 znode自己的数据库。因此，ZooKeeper 集成中的读取速度很快。
如果客户端想要在 ZooKeeper 集合中存储数据，它会将 znode 路径和数据发送到服务器。连接的服务器将请求转发给领导者，然后领导者将重新向所有追随者发出写入请求。如果只有大多数节点成功响应，则写入请求将成功，并向客户端发送成功的返回码。否则，写请求将失败。严格多数节点称为法定人数。
ZooKeeper 集合中的节点
让我们分析一下在 ZooKeeper 集合中具有不同数量的节点的影响。
如果我们有单个节点，那么当该节点发生故障时，ZooKeeper 集成也会发生故障。它会导致"单点故障"，不建议在生产环境中使用。
如果我们有两个节点并且一个节点出现故障，那么我们也没有多数，因为二分之一不是多数。
如果我们有三个节点并且一个节点出现故障，我们有多数，因此，这是最低要求。 ZooKeeper 集成必须在实时生产环境中至少拥有三个节点。
如果我们有四个节点并且两个节点失败，它会再次失败，类似于有三个节点。额外的节点没有任何用途，因此最好添加奇数节点，例如 3、5、7、
我们知道在 ZooKeeper 集成中写入过程比读取过程昂贵，因为所有节点都需要在其数据库中写入相同的数据。因此，对于平衡的环境，拥有较少数量的节点（3、5 或 7 个）比拥有大量节点更好。
下图描述了 ZooKeeper 工作流，随后的表格解释了它的不同组件。
| 组件 |
说明 |
| Write |
写入过程由领导节点处理。领导者将写请求转发到所有 znode 并等待 znode 的答复。如果有一半的 znodes 回复，则写入过程完成。 |
| Read |
读取由特定连接的 znode 在内部执行，因此无需与集群交互。 |
| Replicated Database |
用于在zookeeper中存储数据。每个znode都有自己的数据库，在一致性的帮助下，每个znode每次都有相同的数据。 |
| Leader |
Leader 是负责处理写请求的 Znode。 |
| Follower |
Followers 接收来自客户端的写请求并将它们转发给 leader znode。 |
| Request Processor |
仅在领导节点中出现。它管理来自跟随者节点的写入请求。 |
| Atomic broadcasts |
负责将leader节点的变化广播到follower节点。 |
