Zookeeper节点工作流介绍

1、目标

在文章Zookeeper体系介绍中，我们讨论了ZooKeeper中的术语。在这篇Zookeeper文章中，我们将详细了解Zookeeper Workflow的完整概念。此外，我们将全面了解ZooKeeper集合中具有不同数量节点的效果，以便很好地理解ZooKeeper的工作流。

下面就让我们来了解一下ZooKeeper Workflow。

2、什么是Zookeeper工作流程？

基本上，就像Zookeeper集群启动时一样，Ensemble将等待客户端连接。因此，在ZooKeeper集群中，客户端将连接到其中一个节点。虽然该节点可以是领导者(leader)或追随者(follower)节点。但是，节点会将会话ID分配给特定客户端，并在连接客户端后向客户端发送确认。此外，如果客户端没有得到确认，客户端只会尝试连接到ZooKeeper集合中的另一个节点。此外，客户端将定期向节点发送心跳，以确保一旦连接到节点，连接不会丢失。

如上图纠正一下，应该是Atomic Broadcasts(原子广播)。

另外，存在这样的情况，例如当客户端想要读取特定的Znode时，它向具有Znode路径的节点发送读取请求，并且节点通过从其自己的数据库获取所请求的Znode来返回所请求的Znode。因此，我们可以说ZooKeeper集群中的读是很快。

此外，如果客户端想要将数据存储在ZooKeeper集合中，它会将Znode路径和数据发送到服务器。此外，领导者(leader)将在连接的服务器将请求转发给领导者(leader)之后立即向所有关注者重新发出写入请求。此外，如果只有大多数节点成功响应，写请求将成功并且将成功返回代码。否则，写请求将失败。而且，严格的大多数节点就是我们所说的Quorum。

a. Zookeeper集群中的节点

ZooKeeper集合中可以有不同数量的节点。那么，让我们分析一下在ZooKeeper工作流中更改节点的效果：

如果Zookeeper集群只有一个节点，那么当该节点失败时，ZooKeeper集群就会失效。这就是为什么不建议在生产环境中使用它，因为它会导致"单点故障"。

如果我们有两个节点且一个节点出现故障，我们就没有多数，因为两个节点中有一个不是多数节点。

如果我们有三个节点和一个节点失败，我们有大多数，所以，这是最低要求。 ZooKeeper集群在实际生产环境中必须至少有三个节点。

如果我们有四个节点和两个节点失败，它再次失败，它类似于有三个节点。 额外节点不用于任何目的，因此，最好添加奇数的节点，例如3,5,7。

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

i. 写入(Write)

基本上，leader节点处理写入过程。此外，对于所有的Znodes，leader负责转发写请求，然后等待来自znodes的答案。如果一半的Znodes回复，您可以确定写入过程已完成。

ii. 读取(Read)

读取由连接特定的znode在内部执行，因此不需要与集群交互。

iii. 数据库复制(Replicated Database)

在zookeeper中，为了存储数据，我们使用Replicated Database。但是，每个Znode在一致性的帮助下每次都有相同的数据，每个Znode都有自己的数据库。

iv. Leader

Leader是负责处理写入请求的Znode。

v. Follower

通常，它接收来自客户端的写请求，然后将它们转发给Learer(领导者)Znode。

vi 请求处理器(Request Processor)

只存在于Leader(领导)节点。 它管理来自从节点的写请求。

vii. 原子广播

负责将从领导节点到从节点的变化广播。