解释Apache ZooKeeper
我正在尝试了解ZooKeeper，它是如何工作的以及它是如何工作的。 而我完全困惑。 有什么可以和ZooKeeper相媲美的应用吗？
如果你知道，那么你会如何描述ZooKeeper的外行？ （考虑到我是一个）
我已经尝试过Apache维基，zookeeper sourceforge …但我仍然无法与之联系。 任何帮助，将不胜感激！
我只是阅读通过http://zookeeper.sourceforge.net/index.sf.shtml ，所以没有更多的这样的服务？ 这只是简单的复制服务器服务？
简而言之，ZooKeeper可以帮助您构build分布式应用程序。
怎么运行的
您可以将ZooKeeper描述为具有最终一致性的复制同步服务。 它是健壮的，因为持久数据分布在多个节点之间（这一组节点被称为“集合”），一个客户端连接到它们中的任何一个（即特定的“服务器”），如果一个节点失败则迁移; 只要绝大多数节点正在工作，ZooKeeper节点的集合仍然存在。 具体来说，主节点是在集合内通过共识dynamicselect的; 如果主节点失败，则主节点的angular色将迁移到另一个节点。
如何处理写入
主机是写入的权限：以这种方式写入可以保证按顺序保持，即写入是线性的 。 每次客户端写入集合时，大多数节点都会保存这些信息：这些节点包括客户端的服务器，显然是主服务器。 这意味着每次写入都会使服务器与主服务器保持最新状态。 这也意味着，但是，你不能并发写入。
线性写入的保证是ZooKeeper在写入主导工作负载中performance不佳的原因。 特别是不能用于媒体等大数据的交换。 只要您的通信涉及共享数据，ZooKeeper就可以帮助您。 当数据可以同时写入时，ZooKeeper实际上是挡道的，因为即使从编写者的angular度来看，ZooKeeper并不是严格必要的，但它强加了严格的操作顺序。 它的理想用途是协调，在客户之间交换消息。
如何处理读取
这是ZooKeeper擅长的地方：读取是并发的，因为它们是由客户端连接的特定服务器提供的。 但是，这也是最终一致性的原因：客户端的“视图”可能已经过时，因为主服务器以有限但未定义的延迟更新相应的服务器。
详细
ZooKeeper的复制数据库包含一个znode树，它是粗略表示文件系统节点的实体（将它们视为目录）。 每个znode可以通过存储数据的字节数组来丰富。 另外，每个znode可以在其下面具有其他znode，实际上形成一个内部目录系统。
顺序znodes
有趣的是，znode的名称可以是顺序的 ，这意味着客户端在创buildznode时提供的名称只是一个前缀：全名也由集合select的序号给出。 例如，为了同步的目的，这是很有用的：如果多个客户端想要获取一个资源的锁，他们可以同时在一个位置上创build一个顺序的znode：获取最小编号的人有权获得锁。
短暂的znodes
另外，znode可能是短暂的 ：这意味着一旦创build它的客户端断开连接就会被销毁。 这对于了解客户何时失败是非常有用的，当客户自己负责新客户时，这可能是相关的。 以锁的例子来说，只要有锁的客户端断开，其他客户端可以检查他们是否有权获得锁。
手表
如果我们需要定期轮询znode的状态，与客户端断开有关的例子可能会有问题。 幸运的是，ZooKeeper提供了一个可以在znode上设置手表的事件系统。 这些手表可能被设置为触发一个事件，如果该znode是特别改变或删除或新的儿童下创build。 这与znodes的顺序和短暂选项组合显然是有用的。
在哪里以及如何使用它
Zookeeper使用的一个典型例子是分布式内存计算，其中一些数据在客户机节点之间共享，并且必须以非常小心的方式访问/更新以解释同步。
ZooKeeper提供了构build同步原语的库，而运行分布式服务器的能力避免了使用集中式（代理类）消息库时的单点故障问题。
ZooKeeper是一个function强大的function，这意味着诸如领导者选举，locking，屏障等机制并不存在，但可以写在ZooKeeper基元之上。 如果C / Java API对于您的目的来说太笨重，那么您应该依靠ZooKeeper上构build的库，例如笼子 ，尤其是curator 。
在哪里阅读更多
除了相当不错的官方文档，我build议阅读Hadoop的第14章：权威指南 ，它有35页的内容，基本上解释了ZooKeeper的function，然后是一个configuration服务的例子。
这是一个技术讲座，是 RentTheRunway首席技术官Camille Fournier 对Apache ZooKeeper的介绍 。 我希望这是有帮助的。
你可以阅读这篇文章
ZooKeeper：对Internet规模系统的无等待协调
由两个Yahoo! 工程师
Zookeeper是最好的开源服务器和服务之一，有助于可靠地协调分布式进程。 Zookeeper是一个CP系统（参考CAP定理），它提供了一致性和分区容错性。 Zookeeper状态在所有节点中的复制使其成为最终一致的分布式服务。
此外，任何新当选的领导人都会更新其追随者失踪的build议或国家的快照，如果追随者有很多失踪的build议。
Zookeeper还提供了一个非常易于使用的API。 这个博客文章， Zookeeper Java API的例子 ，有一些例子，如果你正在寻找的例子。
那么我们在哪里使用这个？ 如果您的分布式服务需要集中，可靠和一致的configurationpipe理，locking，队列等，您会发现Zookeeper是一个可靠的select。
下面是我在Zookeeper上find的一本好书： Apache ZooKeeper Essentials
Zookeeper是一个集中的开源服务器，用于维护和pipe理分布式集群环境的configuration信息，命名约定和同步。 Zookeeper通过提供低延迟和高可用性帮助分布式系统降低pipe理复杂性。 Zookeeper最初是Hadoop的子项目，但现在它是Apache Software Foundation的顶级独立项目。
更多信息
对于SpringBoot，在function上，Zookeeper = Spring Cloud Config + Eureka + Ribbon + Zuul
configuration：分布式configuration
尤里卡：服务发现，实例可以注册到Zookeeper，客户端可以使用Springpipe理的bean发现实例
function区：通过Spring Cloud Netflix的客户端负载均衡器
Zuul：通过Spring Cloud Netflix的dynamic路由器和filter
我对ZooKeeper有一般的理解，但对于“法定人数”和“分裂大脑”这两个术语有问题，所以也许我可以把你的发现分享给我（我自己也是一个外行人）。
假设我们有一个由5台服务器组成的ZooKeeper集群。 其中一个服务器将成为领导者，其他服务器将成为追随者。
-
这5台服务器构成法定人数。 法定人数仅仅意味着“这些服务器可以投票选举谁是领导者”。
-
所以投票是基于多数。 多数意味着“超过一半”，所以超过一半的服务器必须同意特定的服务器成为领导者。
-
所以有可能发生的这个不好的事情叫“裂脑”。 据我所知，分裂的大脑就是这样：5个服务器的集群分成两部分，或者称之为“服务器团队”，也许一部分是2，另一部分是3个服务器。 这真是一个糟糕的情况，就好像“服务器团队”必须执行特定的命令一样，你会如何决定哪个团队应该是首选？ 他们可能会收到来自客户的不同信息。 所以了解“服务器团队”的相关性以及哪一个可以被忽略是非常重要的。
-
多数也是你应该使用奇数个服务器的原因。 如果你有4台服务器和2台服务器分离的脑袋，那么“服务器团队”都可以说“嘿，我们要决定谁是领导者！” 但你应该如何决定你应该select哪两台服务器呢？ 使用5台服务器很简单：拥有3台服务器的服务器团队占多数，可以select新的领导者。
-
即使你只有3个服务器，其中一个失败了，另外2个仍然占多数，可以同意其中一个将成为新的领导者。
我意识到一旦你考虑了一段时间，理解这些条款已经不复杂了。 我希望这也能帮助任何人理解这些条款。
