ZooKeeper集合中的节点
让我们分析一下ZooKeeper集合中具有不同数量节点的影响。
- 如果我们只有一个节点,则当该节点发生故障时,ZooKeeper集合也会失败。它会导致“单点故障”,不建议在生产环境中使用它。
- 如果我们有两个节点,并且一个节点发生故障,那么我们也不会拥有多数,因为两个之中的一个不是多数。
- 如果我们有三个节点,而一个节点发生故障,则我们占多数,因此这是最低要求。ZooKeeper集成必须在实时生产环境中至少具有三个节点。
- 如果我们有四个节点,而两个节点发生故障,那么它将再次失败,这类似于具有三个节点。多余的节点没有任何作用,因此最好以奇数(例如3、5、7)添加节点。
我们知道,在ZooKeeper集合中,写入过程比读取过程昂贵,因为所有节点都需要在其数据库中写入相同的数据。因此,对于负载均衡的环境,拥有较少数量的节点(3、5或7)比拥有大量节点更好。
下图描述了ZooKeeper 工作流程,随后的表格解释了其不同的组件。
下表说明了ZooKeeper工作流程中的每个组件。
组件 |
说明 |
写 |
写入过程由领导者(Leader)节点处理。领导者(Leader)将写请求转发到所有znode,并等待来自znode的回复。如果一半的znodes回复,则写入过程已完成。 |
读 |
读取是由特定的已连接znode在内部执行的,因此无需与集群进行交互。 |
复制数据库 |
它用于在Zookeeper中存储数据。在一致性的帮助下,每个znode都有自己的数据库,每个znode每次都具有相同的数据。 |
领导Leader |
Leader是负责处理写请求的Znode。 |
追随者Follower |
追随者Follower从客户端接收写请求,并将其转发给领导者(Leader)znode。 |
请求处理器 |
仅在领导节点中存在。它控制来自跟随者(Follower)节点的写请求。 |
原子广播 |
负责将更改从领导者(Leader)节点传播到跟随者(Follower)节点。 |