Zookeeper 工作流程

ZooKeeper ensemble 启动后,它将等待客户端连接。 客户端将连接到 ZooKeeper 集合中的节点之一。 它可能是领导者或追随者节点。 连接客户端后,节点会为特定客户端分配会话 ID,并向客户端发送确认。 如果客户端没有得到确认,它只是尝试连接 ZooKeeper 集合体中的另一个节点。 一旦连接到某个节点,客户端会定期向该节点发送心跳,以确保连接不丢失。

  • 如果客户端想要读取特定的 znode,它会向具有 znode 路径的节点发送读取请求,并且该节点通过从自己的数据库中获取它来返回请求的 znode。 因此,ZooKeeper 集成中的读取速度很快。
  • 如果客户端想要将数据存储在 ZooKeeper 集合体中,它会将 znode 路径和数据发送到服务器。 连接的服务器将请求转发给领导者,然后领导者重新向所有跟随者发出写入请求。 如果只有大多数节点响应成功,则写入请求成功,并向客户端发送成功的返回码。 否则,写入请求将失败。 严格多数节点称为法定人数。

ZooKeeper Ensemble 中的节点

让我们分析一下 ZooKeeper 集合体中具有不同数量节点的影响。

  • 如果我们只有一个节点,那么当该节点出现故障时 ZooKeeper 整体也会失败。 它会导致“单点故障”,不建议在生产环境中使用。
  • 如果我们有两个节点并且一个节点发生故障,我们也没有多数,因为二分之一不是多数。
  • 如果我们有三个节点和一个节点失败,我们有多数,所以这是最低要求。 ZooKeeper 集成在实时生产环境中必须至少具有三个节点。
  • 如果我们有四个节点,两个节点失败,它会再次失败,这类似于三个节点。 额外的节点没有任何作用,因此最好添加奇数个节点,例如 3、5、7。

我们知道在 ZooKeeper 集成中写入过程比读取过程昂贵,因为所有节点都需要在其数据库中写入相同的数据。 因此,对于平衡的环境而言,拥有较少数量的节点(3、5 或 7)比拥有大量节点更好。

下图描述了 ZooKeeper 工作流程,随后的表格解释了它的不同组件。

zookeeper ensemble
zookeeper ensemble

组件 描述
Write 写入过程由领导节点处理。 leader 将写请求转发给所有的 znode,并等待 znode 的应答。 如果有一半的 znode 回复,那么写过程就完成了。
Read 读取由特定连接的 znode 在内部执行,因此无需与集群交互。
Replicated 数据库 在zookeeper中用于存储数据。 每个 znode 都有自己的数据库,每个 znode 在一致性的帮助下每次都有相同的数据。
Leader Leader是负责处理写请求的Znode。
Follower Follower 接收来自客户端的写入请求并将它们转发给领导者 znode。
Request 处理器 仅存在于领导节点中。 它管理来自跟随者节点的写请求。
Atomic 广播 负责将变化从leader节点广播到follower节点。

查看笔记

扫码一下
查看教程更方便