2

我最近了解了 ZooKeeper 及其设计。我了解一个 ZooKeeper 服务由多个 ZooKeeper 服务器支持,但是,有必要选择其中一个服务器作为组的领导者。

接下来,我开始浏览 LeaderLatch 和 LeaderElection 的 Apache Curator 配方,而不是谈论选择领导者,他们谈论选择一个流程作为领导者(组织者)。

我对此感到困惑。有人可以帮我澄清一下为什么 Curator recipe 和 ZooKeeper 都在谈论两种不同的 Leader 吗?

如果他们确实不同,那么这些领导者如何相互关联?

4

1 回答 1

3

ZooKeeper 的用户并不关心 ZooKeeper 集群是否有领导者。它是一个实现细节。ZooKeeper 服务器在它们自己之间选举一个领导者,作为一种强制执行 ZooKeeper 作为服务提供的一些一致性保证的方式。

作为 ZooKeeper 的用户(或 Curator 作为更好的 API 的用户),你并不真正关心这一点。事实上,ZK 并没有公开这个实现细节——你不知道你是在与领导者还是追随者交谈。

ZK 内部的领导人选举与 ZooKeeper 作为服务提供的用例无关 - ZooKeeper 用户的领导人选举。

如果您使用 ZK,您可能正在自己构建分布式服务,您的服务分布在多台机器上。与任何其他分布式系统一样,您可能会在某些时候遇到问题(例如任务协调),这通常由领导者选举模式解决:

在这种情况下,您可以继续自己实现列出的算法之一。更好的是——你可以使用像 ZooKeeper 这样的协调服务。在 ZK api 中,您可以使用顺序节点和临时节点来实现领导者选举。看看这个食谱:

如您所见,使用裸 ZK api 实现该配方并非易事,因此 Curator 提供了一个更好的包装器以使您更轻松。

综上所述,在谈到 ZooKeeper 中的 Leader Election 时,有两点不同:

  • 领导者选举由 ZK 服务器内部完成,作为实现强一致性的一种机制
  • 领导者选举作为提供给 ZooKeeper 用户的功能,需要使用 ZK 原语手动实现,或者用作 Curator 库中的可用配方
于 2016-05-06T10:09:02.703 回答