Zookeeper架构-图表和示例

in 互联网技术 with 0 comment  访问: 117 次

1、Zookeeper架构介绍

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

2、Zookeeper架构

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

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

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

3、Zookeeper架构的设计目标

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

4、 ZooKeeper中的数据模型

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

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

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

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

  1. 对于表示系统中可用的工作程序的所有ZNode,/workers ZNode是父ZNode。因此,如果工作人员不可用,则应从/workers中删除其ZNode。
  2. 由于等待工作人员执行任务,因此/tasks ZNode是创建的所有任务的父级。为了表示新任务并等待表示任务状态的ZNode,master-worker应用程序的客户端添加新的ZNode作为/tasks的子节点。
  3. 通过向工作者表示任务的分配,/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集合中的更改的通知,ZooKeeper Watches是客户端的一种简单机制。此外,我们可以说手表是一次性操作,意味着它会触发一个通知。但是,客户端可以在收到每个通知时设置新手表,以便随时间接收多个通知。

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次崩溃。但是,偶数的服务器数量实际上会使系统更加脆弱,因此整体中的服务器数量并非强制奇怪。所以,假设我们有四个服务器用于整体。而且,大多数服务器由三台服务器组成。

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

英文原文: http://t.cn/EznjcoD

WeZan
Responses