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

它是如何工作的

You may describe ZooKeeper as a replicated synchronization service with eventual consistency. It is robust, since the persisted data is distributed between multiple nodes (this set of nodes is called an "ensemble") and one client connects to any of them (i.e., a specific "server"), migrating if one node fails; as long as a strict majority of nodes are working, the ensemble of ZooKeeper nodes is alive. In particular, a master node is dynamically chosen by consensus within the ensemble; if the master node fails, the role of master migrates to another node.

如何处理写操作

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

The guarantee of linear writes is the reason for the fact that ZooKeeper does not perform well for write-dominant workloads. In particular, it should not be used for interchange of large data, such as media. As long as your communication involves shared data, ZooKeeper helps you. When data could be written concurrently, ZooKeeper actually gets in the way, because it imposes a strict ordering of operations even if not strictly necessary from the perspective of the writers. Its ideal use is for coordination, where messages are exchanged between the clients.

如何处理读取

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

详细

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

顺序znodes

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

Ephemeral znodes

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

手表

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

在哪里使用，如何使用

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

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

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

在哪里阅读更多

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

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

它是如何工作的

You may describe ZooKeeper as a replicated synchronization service with eventual consistency. It is robust, since the persisted data is distributed between multiple nodes (this set of nodes is called an "ensemble") and one client connects to any of them (i.e., a specific "server"), migrating if one node fails; as long as a strict majority of nodes are working, the ensemble of ZooKeeper nodes is alive. In particular, a master node is dynamically chosen by consensus within the ensemble; if the master node fails, the role of master migrates to another node.

如何处理写操作

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

The guarantee of linear writes is the reason for the fact that ZooKeeper does not perform well for write-dominant workloads. In particular, it should not be used for interchange of large data, such as media. As long as your communication involves shared data, ZooKeeper helps you. When data could be written concurrently, ZooKeeper actually gets in the way, because it imposes a strict ordering of operations even if not strictly necessary from the perspective of the writers. Its ideal use is for coordination, where messages are exchanged between the clients.

如何处理读取

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

详细

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

顺序znodes

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

Ephemeral znodes

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

手表

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

在哪里使用，如何使用

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

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

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

在哪里阅读更多

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

我建议使用以下资源:

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

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

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

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

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

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

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

These 5 servers form a quorum. Quorum simply means "these servers can vote upon who should be the leader". So the voting is based on majority. Majority simply means "more than half" so more than half of the number of servers must agree for a specific server to become the leader. So there is this bad thing that may happen called "split brain". A split brain is simply this, as far as I understand: The cluster of 5 servers splits into two parts, or let's call it "server teams", with maybe one part of 2 and the other of 3 servers. This is really a bad situation as if both "server teams" must execute a specific order how would you decide wich team should be preferred? They might have received different information from the clients. So it is really important to know what "server team" is still relevant and which one can/should be ignored. Majority is also the reason you should use an odd number of servers. If you have 4 servers and a split brain where 2 servers seperate then both "server teams" could say "hey, we want to decide who is the leader!" but how should you decide which 2 servers you should choose? With 5 servers it's simple: The server team with 3 servers has the majority and is allowed to select the new leader. Even if you just have 3 servers and one of them fails the other 2 still form the majority and can agree that one of them will become the new leader.

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

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

更多的信息