我最近了解了 ZooKeeper 及其设计。我了解一个 ZooKeeper 服务由多个 ZooKeeper 服务器支持，但是，有必要选择其中一个服务器作为组的领导者。
接下来，我开始浏览 LeaderLatch 和 LeaderElection 的 Apache Curator 配方，而不是谈论选择领导者，他们谈论选择一个流程作为领导者（组织者）。
我对此感到困惑。有人可以帮我澄清一下为什么 Curator recipe 和 ZooKeeper 都在谈论两种不同的 Leader 吗？
如果他们确实不同，那么这些领导者如何相互关联？
ZooKeeper 的用户并不关心 ZooKeeper 集群是否有领导者。它是一个实现细节。ZooKeeper 服务器在它们自己之间选举一个领导者，作为一种强制执行 ZooKeeper 作为服务提供的一些一致性保证的方式。
作为 ZooKeeper 的用户（或 Curator 作为更好的 API 的用户），你并不真正关心这一点。事实上，ZK 并没有公开这个实现细节——你不知道你是在与领导者还是追随者交谈。
ZK 内部的领导人选举与 ZooKeeper 作为服务提供的用例无关 - ZooKeeper 用户的领导人选举。
如果您使用 ZK，您可能正在自己构建分布式服务，您的服务分布在多台机器上。与任何其他分布式系统一样，您可能会在某些时候遇到问题（例如任务协调），这通常由领导者选举模式解决：
在这种情况下，您可以继续自己实现列出的算法之一。更好的是——你可以使用像 ZooKeeper 这样的协调服务。在 ZK api 中，您可以使用顺序节点和临时节点来实现领导者选举。看看这个食谱：
如您所见，使用裸 ZK api 实现该配方并非易事，因此 Curator 提供了一个更好的包装器以使您更轻松。
综上所述，在谈到 ZooKeeper 中的 Leader Election 时，有两点不同：