Zookeeper架构-图表和示例

1、Zookeeper架构介绍

ZooKeeper体系结构包括ZooKeeper与图表和不同数据模型的工作。此外，我们将在ZooKeeper中学习ZooKeeper架构，模式和版本的设计目标。我们还将看到ZooKeeper Watches 和ZooKeeper Quorums。

2、Zookeeper架构

ZooKeeper本身就是一个分布式应用程序，同时也是分布式系统的协调服务。基本上，它有一个简单的客户端 - 服务器模型，其中客户端是节点（即机器），服务器是节点。作为一项功能，ZooKeper客户端利用服务和服务器提供服务。应用程序通过客户端库调用ZooKeeper。但是，客户端库在此处理与ZooKeeper服务器的交互。现在，下图显示了客户端和服务器之间的关系。在这里，您可以看到每个客户端导入客户端库，然后进一步与任何ZooKeeper节点进行通信。

你知道ZooKeeper用于什么吗？

此外，Zookeeper还有两种运行模式：独立模式和仲裁模式。在定义独立模式时，它具有单个服务器，并且此处不复制ZooKeeper状态。并且，在定义仲裁模式时，在这种模式下有一组ZooKeeper服务器，我们称之为ZooKeeper集群，它复制状态，进而一起服务客户端请求。

但是，在任何给定时间，一个ZooKeeper客户端连接到一个ZooKeeper服务器。作为最佳功能，每个服务器同时处理大量客户端连接。并且，以周期性方式，每个客户端将ping连接发送到它连接的ZooKeeper服务器，以确保它处于活动状态并连接到服务器。此外，通过确认ping，表明服务器也处于活动状态，ZooKeeper服务器响应。但是，当客户端在指定时间内未收到来自服务器的确认时，客户端将连接到集合中的另一个服务器。因此，客户端会话将透明地传输到新的ZooKeeper服务器。

3、Zookeeper架构的设计目标

Zookeeper机构设计背后有一些动机：

ZooKeeper架构必须能够容忍失败。

此外，它必须能够从相关的可恢复故障（停电）中恢复。

最重要的是，它必须正确或易于正确实施。

此外，它必须快速，高吞吐量和低延迟。

4、 ZooKeeper中的数据模型

与标准文件系统一样，ZooKeeper提供的命名空间。基本上，用斜杠（/）分隔的一系列路径元素就是我们所说的名字。在ZooKeeper的命名空间中，路径标识每个节点。此外，在ZooKeeper命名空间中，每个节点都可以拥有与之关联的数据及其子节点。与允许文件也是目录的文件系统相同。

在命名空间中的每个ZNode上，自动读取和写入数据。也就是说，这里Reads获取与ZNode对应的所有数据字节，而write则替换所有数据。此外，还有一个访问控制列表（ACL），每个节点限制每个人的工作。

此外，在每个ZooKeeper服务器中，ZNode层次结构存储在内存中。基本上，这有助于快速响应来自客户端的读取。这种层次结构可以为我们的应用程序提供可靠性，可用性和协调性，这就是为什么我们必须将它用作少量数据的存储机制。

缺少数据通常会传达有关ZooKeeper架构中ZNode的重要信息。

对于表示系统中可用的工作程序的所有ZNode，/workers ZNode是父ZNode。因此，如果工作人员不可用，则应从/workers中删除其ZNode。

由于等待工作人员执行任务，因此/tasks ZNode是创建的所有任务的父级。为了表示新任务并等待表示任务状态的ZNode，master-worker应用程序的客户端添加新的ZNode作为/tasks的子节点。

通过向工作者表示任务的分配，/assign ZNode是所有ZNode的父级。此外，当主服务器将任务分配给工作者时，它会将子ZNode添加到/分配。

5、ZooKeeper架构-ZNode的模式

在ZooKeeper架构中创建新的ZNode时，我们还需要指定一种模式。因为不同的模式解释了ZNode的行为：

a. 持久和短暂的znodes

一个znode可以是任何类型: 无论是持久的Z序节点或短暂的Z序节点。基本上，只有通过调用delete，我们才能删除持久的ZNode /path。而且，相反，如果创建它的客户端崩溃或只是关闭其与ZooKeeper的连接，则短暂的ZNode会删除。

通常，ZNode代表应用程序存储一些数据。即使它的创建者不再是系统的一部分，并且需要保留其数据，在这种情况下，持久性ZNode也很有用。然而，当应用程序的某些方面仅在其创建者的会话有效时必须存在时，短暂的ZNode传达有关该信息的信息。

b. 有序的ZNodes

这些ZNode具有唯一的，单调递增的整数，我们进一步使用它来创建ZNode。换句话说，这些提供了一种简单的方法来创建具有唯一名称的ZNode。此外，提供一种方法来轻松查看ZNode的创建顺序。

6、ZooKeeper架构-版本

有一个版本号与每个ZNode相关联。此外，每次数据更改时，该数字都会增加。特别是，当多个ZooKeeper客户端尝试在同一个ZNode上执行操作时，版本的使用很重要。

7、ZooKeeper Watches

为了获得有关ZooKeeper集合中的更改的通知，是客户端的一种简单机制。此外，我们可以说手表是一次性操作，意味着它会触发一个通知。但是，客户端可以在收到每个通知时设置新手表，以便随时间接收多个通知。

8、ZooKeeper Quorums

基本上，ZooKeeper以仲裁模式将其数据复制到整体中所有服务器上的树。然而，如果客户端在继续之前必须等待每个服务器存储其数据，则延迟可能是不可接受的。一般而言，法定人数是在公共行政中投票所需的最少立法者人数。在Zookeeper中，为了使Zookeeper工作，它是必须按顺序运行和可用的最小服务器数量。

a. 如何为ZooKeeper Quorum选择合适的大小

在ZooKeeper中为仲裁选择足够的大小是非常重要的一步。我们必须在一个名为ensemble的ZooKeeper集群中部署ZooKeeper，以实现可靠的ZooKeeper服务。虽然，只要大多数乐团都在使用，该服务将可用。因此，最好使用奇数个机器，因为Zookeeper需要多数。

现在，让我们看一下IN ZooKeeper Architecture的一个例子来理解它，这个例子解释说，如果法定人数太小，那么事情就会出错。假设有五个服务器，还有一个由两台服务器组成的仲裁。

此外，假设这样的服务器s1和s2都承认它们都复制了请求以便创建ZNode / z。然后，为了说明创建了Znode，服务返回到客户端。此外，假设任意长时间服务器s1和s2都与其他服务器以及客户端分开。甚至在他们有机会将新的ZNode复制到其他服务器之前。

由于有三个服务器可用，并且根据我们的假设它实际上只需要两个，因此处于此状态的服务能够取得进展。但是，这三个服务器是新ZNode / z的新功能。因此，创建/ z的请求是不可忍受的。

因此，为了解决这个问题，仲裁的大小必须至少为3，这是整体中五个服务器中的大多数。此外，整体需要至少三台服务器才能取得进展。因此，我们能够通过使用这样的多数方案来容忍服务器崩溃，确保此处f小于集合中服务器的一半。例如，如果我们有五台服务器，我们可以容忍最多f = 2次崩溃。但是，偶数的服务器数量实际上会使系统更加脆弱，因此整体中的服务器数量并非强制奇怪。所以，假设我们有四个服务器用于整体。而且，大多数服务器由三台服务器组成。

由于两次崩溃会使系统失去多数，因此该系统只能容忍一次崩溃。因此，我们必须总是获取奇数个服务器。