解释Apache ZooKeeper

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

它是如何工作的

您可以将ZooKeeper描述为具有最终一致性的复制同步服务。它是健壮的，因为持久化数据分布在多个节点之间(这组节点称为“集合”)，一个客户端连接到其中任何一个节点(即特定的“服务器”)，如果一个节点失败，就迁移;只要严格意义上的大多数节点都在工作，那么ZooKeeper节点的集合就是活的。特别是，主节点是在集成中通过协商一致动态选择的;如果主节点故障，主节点角色会迁移到其他节点。

如何处理写操作

master是写操作的权限:通过这种方式，写操作可以保证按顺序被持久化，也就是说，写操作是线性。每次客户端写入集成时，大多数节点都会保存信息:这些节点包括客户端的服务器，显然还有主服务器。这意味着每次写入都使服务器与主服务器保持最新。但是，这也意味着您不能进行并发写操作。

线性写的保证是ZooKeeper在以写为主的工作负载下表现不佳的原因。特别是不应用于媒体等大数据的交换。只要你的交流涉及共享数据，ZooKeeper就能帮助你。当数据可以并发写入时，ZooKeeper实际上是一个障碍，因为它强加了严格的操作顺序，即使从写入者的角度来看并不是严格必要的。它的理想用途是用于协调，即在客户机之间交换消息。

如何处理读取

这就是ZooKeeper的优势所在:读取是并发的，因为它们是由客户端连接到的特定服务器提供的。然而，这也是最终一致性的原因:客户端的“视图”可能过时了，因为主机以有限但未定义的延迟更新相应的服务器。

详细

ZooKeeper复制的数据库包含znodes树，这些树是大致表示文件系统节点的实体(可以将它们看作目录)。每个znode可以由一个存储数据的字节数组来充实。而且，每个znode下可能有其他znode，实际上形成了一个内部目录系统。

顺序znodes

有趣的是，znode的名称可以是顺序，这意味着客户端在创建znode时提供的名称只是一个前缀:全名也是由集成选择的一个连续数字给出的。例如，对于同步目的，这是很有用的:如果多个客户端希望获得一个资源的锁，它们可以各自并发地在一个位置上创建一个连续的znode:谁获得最少的数字，谁就有权获得锁。

短暂的znodes

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

手表

如果我们需要定期轮询znodes的状态，那么与客户端断开连接有关的示例可能会出现问题。幸运的是，ZooKeeper提供了一个事件系统，可以在znode上设置看。如果znode被特别更改或删除，或者在它下面创建了新的子节点，则可以将这些手表设置为触发事件。这显然与znodes的顺序和临时选项结合使用非常有用。

在哪里使用，如何使用

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

ZooKeeper提供了构造同步原语的库，同时运行分布式服务器的能力避免了使用集中式(类似代理)消息存储库时出现的单点故障问题。

ZooKeeper是轻特征的，这意味着像领导者选举、锁、障碍等机制还不存在，但可以写在ZooKeeper原语之上。 如果C/Java API对你的目的来说太笨拙了，你应该依赖于构建在ZooKeeper上的库，比如笼子里，尤其是策展人.

在哪里阅读更多

除了官方文档之外，这是非常好的，我建议阅读Hadoop:权威指南的第14章，其中有大约35页解释了ZooKeeper的基本功能，然后是一个配置服务的例子。

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

更多信息 .

Zookeeper是最好的开源服务器和服务之一，它有助于可靠地协调分布式进程。Zookeeper是一个CP系统(参考CAP定理)，提供一致性和分区容忍。在所有节点上复制Zookeeper状态使其最终成为一致的分布式服务。

此外，任何新当选的领导人都会更新其追随者丢失的提案，或者在追随者丢失了许多提案时，更新国家的快照。

Zookeeper还提供了一个非常易于使用的API。这篇博客文章Zookeeper Java API示例有一些例子，如果你正在寻找例子。

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

我大致理解ZooKeeper，但对“quorum”和“split brain”这两个术语有问题，所以也许我可以和你分享我的发现(我认为自己也是一个外行)。

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

• 这5个服务器构成了法定人数。法定人数仅仅意味着“这些服务器可以投票决定谁应该成为领导者”。

• 所以投票是基于多数决定的。多数仅仅意味着“超过一半”，所以必须有超过一半的服务器同意某个特定服务器成为领导者。

• 所以有一件坏事可能会发生，叫做“裂脑”。据我所知，分裂的大脑简单来说就是:5个服务器的集群分裂成两部分，或者让我们称之为“服务器团队”，可能一部分是2个服务器，另一部分是3个服务器。这真是一个糟糕的情况，如果两个“服务器团队”都必须执行一个特定的命令，你将如何决定哪个团队应该被优先考虑?他们可能从客户那里收到了不同的信息。因此，了解哪些“服务器团队”仍然是相关的，哪些可以/应该被忽略是非常重要的。

• 大多数也是您应该使用奇数个服务器的原因。如果你有4个服务器和一个分开的服务器，那么两个“服务器团队”都可以说“嘿，我们想决定谁是领导者!”但是你应该如何决定你应该选择哪2个服务器呢?对于5台服务器来说，这很简单:拥有3台服务器的服务器团队拥有多数，可以选择新的领导者。

• 即使你只有3个服务器，其中一个失败了，其他2个仍然组成大多数，并且可以同意其中一个将成为新的领导者。

我意识到一旦你思考了一段时间，理解了这些术语，它就不再那么复杂了。我希望这也能帮助大家理解这些术语。

我建议使用以下资源:

1. 论文:https://pdos.csail.mit.edu/6.824/papers/zookeeper.pdf
2. 由MIT 6.824提供的讲座从36:00开始:https://youtu.be/pbmyrNjzdDk?t=2198

我建议先看视频，读一读报纸，然后再看一遍。如果您事先了解Raft，就会更容易理解。

我理解zookeeper的方法是，摆弄CLI客户端。如入门指南和命令行接口中所述

从这里我了解到zookeeper的表面看起来非常类似于文件系统，客户端可以创建和删除对象，读取或写入数据。

CLI命令示例

create /myfirstnode mydata
ls /
get /myfirstnode
delete /myfirstnode

试着自己

如何在windows, linux或mac的docker上在几分钟内启动一个zookeeper环境:

一次设置:

docker network create dn

在终端窗口运行服务器:

docker run --network dn --name zook -d zookeeper
docker logs -f zookeeper

在第二个终端窗口中运行客户端:

docker run -it --rm --network dn zookeeper zkCli.sh -server zook

另见dockerhub上的图像文档

Apache ZooKeeper是一种开源技术，用于协调和管理分布式应用程序中的配置。它简化了维护配置细节、启用分布式同步和管理命名注册中心等任务。

它的名字很贴切——想想一个动物园管理员是如何四处走动，照顾所有的动物，维护它们的围栏，喂它们等等。

Apache ZooKeeper可以与Apache Pinot或Apache Flink等Apache项目一起使用。Apache Kafka还使用ZooKeeper来管理代理、主题和分区信息。由于Apache ZooKeeper是开源的，你可以将它与任何你选择的技术/项目配对，而不仅仅是Apache Foundation项目。

它能解决什么问题?

在这里，我们如何确保同一文件不被多个服务器同时拾取和处理? 为了解决这个问题，所有的服务器都应该共享当前正在处理哪个文件的信息

这就是我们可以使用ZooKeeper之类的东西的地方。当第一个服务器想要读取一个文件时，它可以把它要处理的文件名写给zookeeper。现在其他服务器可以查询ZooKeeper并知道这个文件已经被第一个服务器拾取了。

ZK的应用

开箱即用即可

• stored configuration:存储被访问的配置
• 命名服务:将服务名称、IP地址映射等信息集中存储，使能 用户和应用程序通过网络进行通信
• 组成员:所有运行在分布式服务器上的应用程序都可以连接到ZK并发送心跳。如果任何一个服务器/应用程序宕机，ZK可以通知其他服务器/应用程序 有关此事件的服务器/应用程序

其他特性必须建立在ZooKeeper API的基础上。

• 锁和队列——对于分布式同步很有用。
• 两阶段提交-当我们必须跨提交/回滚时很有用 李服务器。< / >
• leader选举——您的分布式应用程序可以使用ZK来进行自动故障转移的leader选举。
• 共享的计数器

ZooKeeper可以有更多的应用。这些特性必须建立在基于分布式系统需求的ZK API之上。

注意:ZK不应用于存储大量数据。它不是一个缓存/数据库。使用它来交换分布式应用程序启动、操作和故障转移所需的一小部分信息。

数据是如何存储的?

数据存储在分层树数据结构中。树中的每个节点被称为znode。znode的最大大小为1MB。Znodes可以有数据和其他子Znodes。把znode想象成你电脑上的一个文件夹，其中文件夹可以包含数据文件，但文件夹本身也可以像文件一样包含数据。

为什么使用ZK而不是我们自己的定制服务?

• 原子性和持久性
• Zookeeper本身是分布式和容错的。该架构包括一个领导节点和多个跟随节点。如果ZK追随者节点发生故障，它将自动故障转移。客户端会话被复制，因此ZK可以自动将客户端移动到不同的节点。如果 Leader节点下降，然后使用ZK选出一个新的Leader 李共识算法。< / >
• 读取非常快，因为它来自内存存储。
• 写入操作按照它到达的顺序进行。因此维持秩序。
• 手表将发送通知给客户端谁设置手表的某些数据。这减少了轮询ZK的需要。注意，手表是一个时间触发器，如果您获得一个手表事件，并且希望获得未来更改的通知，则必须设置另一个手表。
• 持久的和临时的znode是可用的。两者都存储在ZK磁盘上。这里的持久化意味着一旦创建数据的客户端断开连接，数据将被持久化。Ephemeral意味着当客户端断开连接时数据将被自动删除。临时znode不允许有子节点。
• 还有持久的顺序znode和短暂的顺序znode。这里，znode的名称可以有一个后缀序列号。与DB自动递增ID类似，这些序号不断递增，由ZK管理。这对于实现队列、锁等很有用。

有没有什么应用程序可以与Zookeeper相媲美?

etcd - https://etcd.io/docs/v3.3/learning/why/#zookeeper