App实例和Zookeeper服务器的数量应该相同吗？答案

【问题标题】：Does the number of App instances and Zookeeper servers should be the same?App实例和Zookeeper服务器的数量应该相同吗？
【发布时间】：2017-01-26 04:33:26
【问题描述】：

App实例和Zookeeper服务器的数量应该相同吗？我理解 2F+1 的要求来容忍 F 失败，但这是为了容忍 Zookeeper 实例本身的失败。但是 App 实例的数量呢？例如，假设我有 3 个 zookeeper 服务器，我有 2 个由 zookeeper 管理的正在运行的 APP 实例，并且在任何给定时间，只有一个我的应用程序实例将在主模式下运行，另一个在待机模式下运行。现在，我希望能够容忍我的 APP 本身（而不是 zookeeper 实例）的一个实例故障，以便我的 APP 在待机模式下运行的另一个实例应该被选为新的领导者。那行得通吗？或者我必须有 3 个我的 App 实例和 3 个 Zookeeper 服务器？

App 实例和 Zookeeper 服务器数量的正确配置是什么？

【问题讨论】：

标签： apache-zookeeper

【解决方案1】：

从 ZooKeeper 的角度来看，没有要求运行任何特定数量的应用程序实例。应用程序实例是 ZooKeeper 客户端。它们不是 ZooKeeper ensemble（服务器端）的成员，因此不受 2F+1 容错要求的约束。

但应用程序实例的数量可能会影响应用程序的整体可用性，具体取决于其设计。（正如您在示例中所说，您可以运行 2 个实例，并且可以容忍 1 个失败。）

请注意，您的应用程序的领导者选举不同于 ZooKeeper 集成的内部领导者选举。在 ZooKeeper 集成中，需要一定数量的服务器 (2F+1) 来选举领导者，然后该 ZooKeeper 集成领导者处理来自客户端的事务提议。在应用层，您的代码充当 ZooKeeper 客户端，并使用 Leader Election 配方或 Apache Curator Leader Election API 之类的东西执行自己的领导者选举。 ZooKeeper 集成节点不会对您的哪个应用程序节点成为领导者进行投票。取而代之的是，您的应用程序节点投票决定其中一个成为领导者，并且它们通过与已经有自己的领导者的 ZooKeeper 集成进行协调来投票。

【讨论】：

它如何容忍一个应用实例失败？因为我的应用程序实例中只有一个需要作为主实例运行，而其他应用实例需要作为备用实例运行。当我的一个应用程序实例失败时，领导者选举应该运行，所以在我的情况下，我将只剩下一个应用程序实例，因此领导者选举将无法正常工作？
不，您的应用程序的领导者选举仍然可以成功。其实你描述的架构和HDFS NameNode如何实现高可用是一样的：一个master和一个standby通过ZooKeeper协调领导。您可能会想到 ZooKeeper ensemble 自己的内部领导选举，它确实需要一个仲裁（2F+1 个实例），但这与您应用的领导选举不同。
@user1870400 在ZK recipes docs 中阅读有关应用程序级别领导选举实施的更多信息。
@Chris Nauroth 所以说我总共有 3 个 ZK 服务器，这意味着我可以容忍一个故障并说我有 2 个应用程序实例正在运行。如果一个 ZK 实例失败，我将剩下 2 个 ZK 服务器，现在说 ZK server1 为 App 实例 1 投票，ZK server2 为 App 实例 2 投票。在这种情况下，Zookeeper 将如何为我的应用程序选举领导者？
@user1870400 ZooKeeper ensemble 节点实际上并不投票给应用程序实例 1 或实例 2。相反，您的应用程序实例正在投票给哪个应用程序实例成为领导者，并且它们的领导者选举是通过协调事务来实现的ZooKeeper 合奏。 ZooKeeper ensemble 已经在内部选举了自己的领导者，但这与您的应用程序决定哪个实例成为领导者不同。我已经编辑了答案以澄清这一点。我也赞同阅读领导选举秘诀并考虑使用 Apache Curator 的建议。