Zookeeper - 工作流程

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

  • 如果客户端想要读取特定的 znode, 它会向带有 znode 路径的节点发送一个读取请求,并且该节点通过从自己的数据库中获取所请求的 znode 来返回所请求的 znode。 出于这个原因,ZooKeeper ensemble 中的读取速度很快。

  • 如果客户端想要在 ZooKeeper ensemble 中存储数据,它会将 znode 路径和数据发送到服务器。 连接的服务器会将请求转发给 leader,然后 leader 将重新向所有从属节点发出写入请求。 如果只有大多数节点响应成功,那么写请求就会成功,并且会向客户端发送一个成功的返回码。 否则,写请求将失败。 严格的大多数节点称为Quorum


ZooKeeper Ensemble 中的节点

让我们分析一下 ZooKeeper ensemble 中节点数量不同的影响。

  • 如果我们有单个节点,那么当该节点发生故障时,ZooKeeper ensemble 就会失败。 它会导致"单点故障",不建议在生产环境中使用。

  • 如果我们有两个节点并且一个节点失败了,我们也没有多数,因为二分之一不是多数。

  • 如果我们有 三个节点并且一个节点出现故障,则我们拥有多数,因此这是最低要求。 ZooKeeper ensemble 在实时生产环境中必须具有至少三个节点。

  • 如果我们有四个节点并且两个节点失败了,它会再次失败,它类似于拥有三个节点。 额外的节点没有任何用途,因此最好以奇数添加节点,例如 3、5、7。

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

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

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