top*_*ard 360 distributed-computing apache-zookeeper
我试图了解ZooKeeper,它是如何工作的以及它的作用.有没有可与ZooKeeper相媲美的应用程序？
如果你知道,那么你如何向外行描述ZooKeeper？
我已经尝试过apache wiki,zookeeper sourceforge ......但我仍然无法与之相关.
我只是通过http://zookeeper.sourceforge.net/index.sf.shtml阅读,所以不是有更多这样的服务吗？它只是复制服务器服务这么简单吗？
Luc*_*tti 424
简而言之,ZooKeeper可以帮助您构建分布式应用程序.
您可以将ZooKeeper描述为具有最终一致性的复制同步服务.它是健壮的,因为持久化数据分布在多个节点之间(这组节点称为"集合"),一个客户端连接到它们中的任何一个(即特定的"服务器"),如果一个节点发生故障则迁移; 只要严格的大多数节点正在工作,ZooKeeper节点的集合就会生效.特别地,在集合内通过一致动态地选择主节点; 如果主节点发生故障,主节点的角色将迁移到另一个节点.
主机是写入的权限:这样可以保证写入按顺序保持,即写入是线性的.每次客户端写入集合时,大多数节点都会保留信息:这些节点包括客户端的服务器,显然还包括主服务器.这意味着每次写入都会使服务器与主服务器保持同步.但是,这也意味着您不能进行并发写入.
线性写入的保证是ZooKeeper在写入占优势的工作负载上表现不佳的原因.特别是,它不应该用于交换大数据,例如媒体.只要您的通信涉及共享数据,ZooKeeper就会帮助您.当数据可以同时写入时,ZooKeeper实际上会阻碍,因为即使从编写者的角度来看并非严格必要,它也会强制执行严格的操作顺序.它的理想用途是协调,在客户端之间交换消息.
这是ZooKeeper擅长的地方:读取是并发的,因为它们由客户端连接到的特定服务器提供服务.但是,这也是最终一致性的原因:客户端的"视图"可能已过时,因为主服务器使用有界但未定义的延迟更新相应的服务器.
ZooKeeper的复制数据库包含一个znode树,它是粗略表示文件系统节点的实体(将它们视为目录).每个znode可以通过存储数据的字节数组来丰富.此外,每个znode可以在其下具有其他znode,实际上形成内部目录系统.
有趣的是,znode的名称可以是顺序的,这意味着客户端在创建znode时提供的名称只是一个前缀:全名也由整体选择的序列号给出.例如,这对于同步目的很有用:如果多个客户端想要锁定资源,则每个客户端可以同时在某个位置创建顺序znode:获得最低编号的人有权获得锁定.
此外,znode可能是短暂的:这意味着一旦创建它的客户端断开连接就会被销毁.这主要用于了解客户端何时发生故障,当客户端本身具有新客户端应承担的职责时,这可能是相关的.以锁的示例为例,一旦具有锁的客户端断开连接,其他客户端就可以检查他们是否有权获得锁.
如果我们需要定期轮询znode的状态,那么与客户端断开相关的示例可能会有问题.幸运的是,ZooKeeper提供了一个可以在znode上设置手表的事件系统.如果znode被特别更改或删除或在其下创建新子节点,则可以将这些手表设置为触发事件.这与znodes的顺序和短暂选项结合使用显然很有用.
Zookeeper使用的典型示例是分布式内存计算,其中一些数据在客户端节点之间共享,并且必须以非常小心的方式访问/更新以考虑同步.
ZooKeeper提供了构建同步原语的库,而运行分布式服务器的能力避免了使用集中式(类似代理)消息库时出现的单点故障问题.
ZooKeeper功能强大,意味着领导者选举,锁定,障碍等机制尚未出现,但可以在ZooKeeper原语之上编写.如果C/Java API对于您的目的来说太笨重,那么您应该依赖于构建在ZooKeeper上的库,例如cages,尤其是curator.
除了官方文档,这是非常好的,我建议阅读Hadoop:The Definitive Guide的第14章,其中有大约35页,主要解释ZooKeeper的功能,然后是配置服务的示例.
Bin*_*rge 10
Zookeeper是最好的开源服务器和服务之一,有助于可靠地协调分布式进程.Zookeeper是一个CP系统(参考CAP定理),它提供一致性和分区容差.在所有节点上复制Zookeeper状态使其成为最终一致的分布式服务.
此外,如果追随者遗失了许多提案,任何新当选的领导人都会更新其关注者的遗失提案或国家快照.
Zookeeper还提供了一个非常易于使用的API.这篇博文,Zookeeper Java API示例,如果您正在寻找示例,还有一些示例.
那么我们在哪里使用它？如果您的分布式服务需要集中,可靠和一致的配置管理,锁,队列等,您会发现Zookeeper是一个可靠的选择.
sha*_*359 10
它解决什么问题？
假设我们的文件存储中有 100 万个文件，并且文件数量每天每分钟都在不断增加。我们的任务是首先处理然后删除这些文件。我们能想到的方法之一是编写一个脚本来执行此任务并在多个服务器上并行运行多个实例。我们甚至可以根据需求增加或减少服务器数量。这基本上是一个分布式计算/数据处理应用程序。
这里，如何保证同一个文件不被多个服务器同时抓取和处理呢？为了解决这个问题，所有服务器应该共享有关当前正在处理哪个文件的信息。
这就是我们可以使用 ZooKeeper 之类的东西的地方。当第一个服务器想要读取文件时，它可以将要处理的文件名写入动物园管理员。现在，其余服务器可以查找 ZooKeeper 并知道该文件已被第一台服务器获取。
上面是一个粗略的例子，几乎不需要其他护栏，但我希望它能让你了解什么是动物园管理员。ZK 基本上是一个可以使用 ZK API 访问的数据存储。但它不应该用作数据库。只应存储少量数据（通常以 KB 为单位）。每个 znode 的上限为 1MB。ZK 是专门为分布式应用程序之间的通信而构建的。
ZK的应用
开箱即用，可用于
其他功能必须构建在 ZooKeeper API 之上。
下面的页面解释了如何实现这些功能 https://zookeeper.apache.org/doc/current/recipes.html
ZooKeeper 还可以有更多的应用程序。这些功能必须根据分布式系统的要求构建在 ZK API 之上。
注意：ZK 不应该用于存储大量数据。它不是缓存/数据库。使用它来交换分布式应用程序启动、操作和故障转移所需的一小段信息。
数据如何存储？
数据存储在分层树形数据结构中。树中的每个节点称为znode。znode 的最大大小为 1MB。znode 可以有数据和其他子 znode。将 znode 想象成计算机上的一个文件夹，其中文件夹可以包含包含数据的文件，但文件夹本身也可以像文件一样包含数据。
为什么使用ZK而不是我们自己的定制服务？
有没有可以与Zookeeper相媲美的应用程序？
etcd - https://etcd.io/docs/v3.3/learning/why/#zookeeper
我一般都了解ZooKeeper,但是术语"quorum"和"split brain"存在问题,所以也许我可以与你分享我的发现(我认为自己也是一个门外汉).
假设我们有一个由5台服务器组成的ZooKeeper集群.其中一台服务器将成为领导者,其他服务器将成为粉丝.
这5台服务器形成了法定人数.Quorum只是意味着"这些服务器可以投票决定谁应该成为领导者".
所以投票是基于多数票.多数意味着"超过一半",因此超过一半的服务器必须同意特定服务器成为领导者.
所以有一种可能发生的坏事叫做"裂脑".据我所知,分裂的大脑就是这样:5台服务器的集群分为两部分,或者称之为"服务器团队",可能是2部分的一部分,也是3部分服务器的另一部分.这真是一个糟糕的情况,好像两个"服务器团队"必须执行一个特定的命令,你如何决定哪个团队应该是首选？他们可能从客户那里收到了不同的信息.因此,了解"服务器团队"仍然相关以及哪些可以/应该被忽略非常重要.
多数也是您应该使用奇数个服务器的原因.如果你有4个服务器和一个分裂的大脑,其中2个服务器分开,那么两个"服务器团队"可以说"嘿,我们想决定谁是领导者!" 但是你应该如何决定应该选择哪两台服务器呢？使用5台服务器很简单:拥有3台服务器的服务器团队占大多数,并且可以选择新的领导者.
即使您只有3台服务器而其中一台服务器失败,另外两台服务器仍占大多数,并且可以同意其中一台将成为新的领导者.
我意识到,一旦你想到这一点,并理解它不再那么复杂的条款.我希望这也有助于任何人理解这些术语.