解释Apache ZooKeeper

我试图了解ZooKeeper，其工作原理以及功能。有没有可以与ZooKeeper媲美的应用程序？

如果您知道，那么您将如何向外行描述ZooKeeper？

我已经尝试过Apache Wiki，Zookeeper Sourceforge ...，但是我仍然无法与之联系。

我只是通过http://zookeeper.sourceforge.net/index.sf.shtml阅读，所以没有更多这样的服务吗？它像复制服务器服务一样简单吗？

简而言之，ZooKeeper可帮助您构建分布式应用程序。

怎么运行的

您可以将ZooKeeper描述为具有最终一致性的复制同步服务。由于持久化的数据分布在多个节点之间（这组节点称为“集合”），并且一个客户端连接到其中的任何一个（即，特定的“服务器”），因此如果一个节点发生故障则迁移，因此它是可靠的。只要严格地说大多数节点都在工作，ZooKeeper节点的集合就是活的。特别是，在集合内通过协商一致来动态选择主节点。如果主节点发生故障，则主节点的角色将迁移到另一个节点。

如何处理写入

母版是写操作的权限：这样可以确保写操作按顺序保留，即写操作是线性的。每次客户端写入合奏时，大多数节点都会保留信息：这些节点包括客户端的服务器，当然也包括主机。这意味着每次写入都会使服务器与主服务器保持最新状态。但是，这也意味着您不能同时进行写入。

保证线性写入的原因是ZooKeeper对于以写入为主的工作负载性能不佳。特别是，不应将其用于交换大数据（例如媒体）。只要您的通信涉及共享数据，ZooKeeper就会为您提供帮助。当可以同时写入数据时，ZooKeeper实际上会妨碍您的工作，因为从编写者的角度来看，即使不是绝对必要的，它也会对操作进行严格的排序。它的理想用途是用于协调，即在客户端之间交换消息。

如何处理阅读

这就是ZooKeeper的优势：读取是并发的，因为它们由客户端连接到的特定服务器提供服务。但是，这也是最终保持一致性的原因：客户端的“视图”可能已过时，因为主服务器会以有限但不确定的延迟来更新相应的服务器。

详细

ZooKeeper的复制数据库包括znodes树，znodes是大致代表文件系统节点（将其视为目录）的实体。每个znode可以通过存储数据的字节数组来丰富。而且，每个znode之下可能都有其他znode，实际上形成了一个内部目录系统。

顺序znode

有趣的是，znode的名称可以是顺序的，这意味着客户端在创建znode时提供的名称只是一个前缀：全名也由集合选择的顺序号给出。例如，这对于同步目的很有用：如果多个客户端想要获得资源上的锁，则它们每个都可以在一个位置上并发地创建顺序znode：获得最低编号的人有权获得该锁。

短暂的znode

另外，znode可能是短暂的：这意味着一旦创建它的客户端断开连接，它就会被销毁。这主要用于了解客户端何时发生故障，这在客户端本身具有应由新客户端承担的责任时可能是相关的。以锁为例，一旦拥有该锁的客户端断开连接，其他客户端就可以检查他们是否有权使用该锁。

手表

如果我们需要定期轮询znode的状态，则与客户端断开连接有关的示例可能会出现问题。幸运的是，动物园管理员提供了一个事件系统，其中手表可以在Z序节点设置。如果专门更改或删除了znode或在其下创建了新的子代，则可以将这些手表设置为触发事件。与znode的顺序选项和临时选项结合使用时，这显然很有用。

在哪里以及如何使用它

Zookeeper使用的一个典型示例是分布式内存计算，其中一些数据在客户端节点之间共享，并且必须以非常谨慎的方式访问/更新这些数据以说明同步。

ZooKeeper提供了用于构建同步原语的库，而运行分布式服务器的能力则避免了使用集中式（类似经纪人）消息存储库时出现的单点故障问题。

ZooKeeper具有轻量级功能，这意味着诸如领导者选举，锁定，屏障等机制尚不存在，但可以在ZooKeeper原语之上编写。如果C / Java API对于您的用途而言过于笨拙，则应依赖ZooKeeper构建的库，例如笼子，尤其是curator。

在哪里阅读更多

除了非常好的官方文档外，我建议阅读Hadoop的第14章：权威指南，该指南共有35页，基本上解释了ZooKeeper的工作，后面是配置服务的示例。

Zookeeper是最好的开源服务器和服务之一，可帮助可靠地协调分布式过程。Zookeeper是一种CP系统（请参阅CAP定理），可提供一致性和分区容限。在所有节点上复制Zookeeper状态使其成为最终一致的分布式服务。

而且，如果新当选的领导人缺少许多提案，则将使用缺少的提案或状态快照来更新其跟随者。

Zookeeper还提供了非常易于使用的API。如果您正在寻找示例，则此博客文章Zookeeper Java API示例包含一些示例。

那么我们在哪里使用呢？如果您的分布式服务需要集中，可靠和一致的配置管理，锁，队列等，则您会发现Zookeeper是可靠的选择。

我总体上了解ZooKeeper，但对“仲裁”和“裂脑”一词有疑问，因此也许我可以与您分享我的发现（我认为自己也是外行）。

假设我们有一个由5个服务器组成的ZooKeeper集群。其中一台服务器将成为领导者，其他服务器将成为跟随者。

• 这5台服务器构成法定人数。仲裁仅表示“这些服务器可以投票决定谁应该成为领导者”。

• 因此，投票基于多数。多数简单地表示“超过一半”，因此必须有超过一半的服务器数量同意特定服务器才能成为领导者。

• 因此，可能会发生这种不好的事情，称为“裂脑”。据我所知，这只是一个裂脑：由5台服务器组成的集群分为两部分，或者我们称其为“服务器团队”，也许是2台的一部分，而3台服务器的另一部分。这真是一个糟糕的情况，好像两个“服务器团队”都必须执行特定命令一样，您将如何选择夹心团队呢？他们可能从客户那里收到了不同的信息。因此，重要的是要知道哪些“服务器团队”仍然有用，哪些可以/应该被忽略。

• 大多数情况也是您使用奇数个服务器的原因。如果您有4台服务器，并且大脑裂开，其中2台服务器分开，那么两个“服务器团队”都可以说“嘿，我们要确定谁是领导者！” 但是您应该如何决定应该选择哪两台服务器呢？拥有5台服务器很简单：拥有3台服务器的服务器团队拥有多数，并可以选择新的领导者。

• 即使您只有3台服务器，其中一台服务器出现故障，其他2台服务器仍然占据多数，并且可以同意其中一台将成为新的领导者。

我意识到一旦您考虑了一段时间并理解了术语，它就不再那么复杂了。我希望这也可以帮助任何人理解这些术语。

Zookeeper是集中式开源服务器，用于维护和管理分布式集群环境的配置信息，命名约定和同步。Zookeeper通过提供低延迟和高可用性来帮助分布式系统降低其管理复杂性。Zookeeper最初是Hadoop的子项目，但现在是Apache Software Foundation的顶级独立项目。

更多信息

我建议以下资源：

1. 论文：https：//pdos.csail.mit.edu/6.824/papers/zookeeper.pdf
2. 麻省理工学院6.824从36:00开始提供的演讲：https ://youtu.be/pbmyrNjzdDk ? t = 2198

我建议您观看视频，阅读论文，然后再次观看视频。如果您事先了解Raft，将会更容易理解。