解释Apache ZooKeeper

我试图了解ZooKeeper,它是如何工作的以及它的作用.有没有可与ZooKeeper相媲美的应用程序？

如果你知道,那么你如何向外行描述ZooKeeper？

我已经尝试过apache wiki,zookeeper sourceforge ......但我仍然无法与之相关.

我只是通过http://zookeeper.sourceforge.net/index.sf.shtml阅读,所以不是有更多这样的服务吗？它只是复制服务器服务这么简单吗？

1> Luca Geretti..：

---

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

这个怎么运作

您可以将ZooKeeper描述为具有最终一致性的复制同步服务.它是健壮的,因为持久化数据分布在多个节点之间(这组节点称为"集合"),一个客户端连接到它们中的任何一个(即特定的"服务器"),如果一个节点发生故障则迁移; 只要严格的大多数节点正在工作,ZooKeeper节点的集合就会生效.特别地,在集合内通过一致动态地选择主节点; 如果主节点发生故障,主节点的角色将迁移到另一个节点.

如何处理写入

主机是写入的权限:这样可以保证写入按顺序保持,即写入是线性的.每次客户端写入集合时,大多数节点都会保留信息:这些节点包括客户端的服务器,显然还包括主服务器.这意味着每次写入都会使服务器与主服务器保持同步.但是,这也意味着您不能进行并发写入.

线性写入的保证是ZooKeeper在写入占优势的工作负载上表现不佳的原因.特别是,它不应该用于交换大数据,例如媒体.只要您的通信涉及共享数据,ZooKeeper就会帮助您.当数据可以同时写入时,ZooKeeper实际上会阻碍,因为即使从编写者的角度来看并非严格必要,它也会强制执行严格的操作顺序.它的理想用途是协调,在客户端之间交换消息.

如何处理读取

这是ZooKeeper擅长的地方:读取是并发的,因为它们由客户端连接到的特定服务器提供服务.但是,这也是最终一致性的原因:客户端的"视图"可能已过时,因为主服务器使用有界但未定义的延迟更新相应的服务器.

详细地

ZooKeeper的复制数据库包含一个znode树,它是粗略表示文件系统节点的实体(将它们视为目录).每个znode可以通过存储数据的字节数组来丰富.此外,每个znode可以在其下具有其他znode,实际上形成内部目录系统.

顺序znodes

有趣的是,znode的名称可以是顺序的,这意味着客户端在创建znode时提供的名称只是一个前缀:全名也由整体选择的序列号给出.例如,这对于同步目的很有用:如果多个客户端想要锁定资源,则每个客户端可以同时在某个位置创建顺序znode:获得最低编号的人有权获得锁定.

短暂的znodes

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

手表

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

在哪里以及如何使用它

Zookeeper使用的典型示例是分布式内存计算,其中一些数据在客户端节点之间共享,并且必须以非常小心的方式访问/更新以考虑同步.

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

ZooKeeper功能强大,意味着领导者选举,锁定,障碍等机制尚未出现,但可以在ZooKeeper原语之上编写.如果C/Java API对于您的目的来说太笨重,那么您应该依赖于构建在ZooKeeper上的库,例如cages,尤其是curator.

在哪里阅读更多

除了官方文档,这是非常好的,我建议阅读Hadoop:The Definitive Guide的第14章,其中有大约35页,主要解释ZooKeeper的功能,然后是配置服务的示例.

---

IMO无法解释ZooKeeper对外行人员的影响.我什么时候需要ZooKeeper？我会写什么？它解决了什么问题？它是一个键值商店吗？一个搜索引擎？分布式锁？为什么我会选择ZooKeeper,例如Redis或文件或JIRA或便利贴？你清楚地了解了很多关于ZooKeeper的知识 - 但是你可以在技术上解释它吗？

---

我不确定我是否理解您所建议的通信方案,但您可以使用ZooKeeper从生产者"发布"信息并让几个消费者阅读它.另一方面,如果每种服务器只存在一个实例,则使用ZK几乎没有任何好处.

2> Binu George..：

---

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

此外,如果追随者遗失了许多提案,任何新当选的领导人都会更新其关注者的遗失提案或国家快照.

Zookeeper还提供了一个非常易于使用的API.这篇博文,Zookeeper Java API示例,如果您正在寻找示例,还有一些示例.

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

---

就CAP定理而言,"C"实际上意味着线性化.ZooKeeper实际上提供了"顺序一致性",这意味着客户端的更新将按接收顺序应用.这比线性化要弱但仍然非常强大,比"最终一致性"强得多.Zookeeper不是A,这是因为如果领导者不能被选举(没有法定人数)那么zookeeper将失败请求.这就是它没有高度可用性的原因.

---

“ Zookeeper是提供一致性和分区容限的CP系统（请参阅CAP定理）”，我认为Zookeeper具有主控者和跟随者，当主控者掉下来时，将选择一名跟随者作为领导者，因此Zookeeper应该提供AP，但是C最终是一致的。

3> Invest..：

---

我一般都了解ZooKeeper,但是术语"quorum"和"split brain"存在问题,所以也许我可以与你分享我的发现(我认为自己也是一个门外汉).

假设我们有一个由5台服务器组成的ZooKeeper集群.其中一台服务器将成为领导者,其他服务器将成为粉丝.

这5台服务器形成了法定人数.Quorum只是意味着"这些服务器可以投票决定谁应该成为领导者".

所以投票是基于多数票.多数意味着"超过一半",因此超过一半的服务器必须同意特定服务器成为领导者.

所以有一种可能发生的坏事叫做"裂脑".据我所知,分裂的大脑就是这样:5台服务器的集群分为两部分,或者称之为"服务器团队",可能是2部分的一部分,也是3部分服务器的另一部分.这真是一个糟糕的情况,好像两个"服务器团队"必须执行一个特定的命令,你如何决定哪个团队应该是首选？他们可能从客户那里收到了不同的信息.因此,了解"服务器团队"仍然相关以及哪些可以/应该被忽略非常重要.

多数也是您应该使用奇数个服务器的原因.如果你有4个服务器和一个分裂的大脑,其中2个服务器分开,那么两个"服务器团队"可以说"嘿,我们想决定谁是领导者!" 但是你应该如何决定应该选择哪两台服务器呢？使用5台服务器很简单:拥有3台服务器的服务器团队占大多数,并且可以选择新的领导者.

即使您只有3台服务器而其中一台服务器失败,另外两台服务器仍占大多数,并且可以同意其中一台将成为新的领导者.

我意识到,一旦你想到这一点,并理解它不再那么复杂的条款.我希望这也有助于任何人理解这些术语.