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