一旦ZooKeeper整体启动，它将等待客户端连接.客户端将连接到ZooKeeper集合中的一个节点.它可能是领导者或追随者节点.连接客户端后，节点会将会话ID分配给特定客户端，并向客户端发送确认.如果客户端没有得到确认，它只是尝试连接ZooKeeper集合中的另一个节点.连接到节点后，客户端将定期向节点发送心跳，以确保连接不会丢失.
如果客户端想要读取特定的znode，它会向具有znode路径的节点发送读取请求，并且节点通过获取它来返回请求的znode来自自己的数据库.因此，ZooKeeper集合中的读取速度很快.
如果客户端想要在ZooKeeper集合中存储数据，它会发送znode路径和服务器的数据.连接的服务器将请求转发给领导者，然后领导者将向所有关注者重新发出写入请求.如果只有大多数节点成功响应，则写请求将成功，并且将成功返回代码发送给客户端.否则，写请求将失败.绝大多数节点被称为 Quorum .
ZooKeeper Ensemble中的节点
让我们分析ZooKeeper集合中不同节点数的影响.
如果我们如果单个节点，则当该节点发生故障时，ZooKeeper集合将失败.它会导致"单点故障"，并且不建议在生产环境中使用.
如果我们有两个节点并且一个节点失败，我们也没有多数，因为两个中的一个不是多数.
如果我们有三个节点并且一个节点失败，我们占多数，因此，这是最低要求. ZooKeeper集合必须在实时生产环境中至少有三个节点.
如果我们有四个节点并且两个节点发生故障，它再次失败，类似于有三个节点.额外节点不用于任何目的，因此，最好添加奇数的节点，例如3,5,7.
<我们知道写入过程比ZooKeeper集合中的读取过程昂贵，因为所有节点都需要在其数据库中写入相同的数据.因此，与平衡环境中拥有大量节点相比，拥有更少数量的节点(3,5或7)更好.
下图描绘了ZooKeeper WorkFlow和后续表解释了它的不同组件.
| 组件 | 描述 |
|---|---|
| 写 | 写入过程由领导节点处理.领导者将写请求转发给所有znode并等待来自znode的答案.如果一半的znodes回复，则写入过程完成. |
| 读取 | 读取由特定连接的znode在内部执行，因此无需与群集交互. |
| 复制数据库 | 它用于在zookeeper中存储数据.每个znode都有自己的数据库，并且每个znode在一致性的帮助下每次都有相同的数据. |
| Leader | Leader是负责处理写请求的Znode. |
| 关注者 | 关注者从客户端接收写入请求并将其转发给领导者znode. |
| 请求处理器 | 仅在领导节点中出现.它管理来自跟随节点的写请求. |
| 原子广播 | 负责广播从领导节点到跟随节点的变化. |