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

更多的信息

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

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

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

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

我大致理解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.

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

我建议使用以下资源:

论文:https://pdos.csail.mit.edu/6.824/papers/zookeeper.pdf 由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上的image文档

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

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

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

它能解决什么问题?

让我们想象一下，在文件存储中有一百万个文件，并且文件数量每分钟都在增加。 我们的任务是先处理，然后删除这些文件。我们可以想到的一种方法是编写一个脚本来完成这个任务，并在多个服务器上并行运行多个实例。我们甚至可以根据需求增加或减少服务器数量。这基本上是一个分布式计算/数据处理应用程序。

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

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

上面是一个粗略的例子，需要一些其他的护栏，但我希望它能让你了解什么是zookeeper。 ZK基本上是一个可以使用ZK API访问的数据存储。但它不应该被用作数据库。应该只存储少量数据(通常以KB为单位)。上限为每个znode 1MB。 ZK是专门构建的，这样分布式应用程序就可以相互通信。

ZK的应用

开箱即用即可

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

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

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

下面的页面解释了如何实现这些特性 https://zookeeper.apache.org/doc/current/recipes.html

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

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

数据是如何存储的?

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

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

Atomicity and Durability Zookeeper itself is distributed and Fault tolerant. The architecture involves one leader node and multiple follower nodes. In case a ZK follower node goes down, it will automatically failover. The client sessions are replicated hence ZK can automatically move clients to a different node. If the Leader node goes down then a new leader is elected using the ZK consensus algorithm. Reads are very fast since its served from in-memory store. Writes are written in the sequence in which it arrived. Hence maintains ordering. Watches will send out notification to the client who set the watch on some data. This reduces the need to poll ZK. Note that watches are one time triggers and if you get a watch event and you want to get notified of future changes, you must set another watch. Persistent and ephemeral znodes are available. Both are stored on ZK disks. Persistent here means that the data will be persisted once the client who created it disconnects. Ephemeral means the data will be removed automatically when the client disconnects. Ephemeral znodes are not allowed to have children. There is also persistent sequential and ephemeral sequential znodes. Here the names of the znodes can have a suffix sequence number. similar to DB auto increment ID's, these sequence number keeps increasing and managed by ZK. This can be useful to implement queues, locks etc.

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

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