如何在集群中运行的节点中选出一个主节点？答案

【问题标题】：How to elect a master node among the nodes running in a cluster?如何在集群中运行的节点中选出一个主节点？
【发布时间】：2010-12-23 23:22:18
【问题描述】：

我正在编写一个托管云堆栈（在 EC2 等硬件级云提供商之上），我很快将面临的一个问题是：

几个相同的节点如何决定其中哪一个成为主节点？（即考虑在 EC2 上运行 5 台服务器。其中一台必须成为主服务器，而其他服务器必须成为从服务器。）

我阅读了the algorithm used by MongoDB 的描述，它看起来很复杂，并且还取决于投票的概念——即两个节点单独放置将无法决定任何事情。而且他们的方法在产生结果之前有很大的延迟。

这是How to elect new Master in Cluster?的重复，提供的细节较少，已经6个月没有回答了，所以我觉得开始一个新的问题是合适的。

（我正在开发的堆栈是开源的，但它处于开发的早期阶段，所以这里不提供链接。）

更新：根据答案，我设计了一个简单的共识算法，你可以在 GitHub 上找到一个 JavaScript (CoffeeScript) 实现：majority.js。

【问题讨论】：

【解决方案1】：

领导者选举算法通常将split brain 视为要支持的故障案例。如果您认为不是节点故障而是网络故障，您可能会遇到所有节点都已启动但无法相互通信的情况。那么，你最终可能会得到两个大师。

如果您可以从故障模型中排除“裂脑”（即，如果您只考虑节点故障），那么您的算法（领导者是地址最小的那个）就可以了。

【讨论】：

谢谢。但我认为当少于大多数节点在线时，MongoDB 完全拒绝运行。关于为什么它需要复杂的任何其他想法？
@Andrey：这是脑裂的原因。如果您将集群分成两部分，则较小的部分不得选举领导者。通过这样做，您可以保证只有较大的一半节点（假定在线，但无法访问）会有领导者，从而保证在任何时间点最多有一个领导者。
好的，对于 MongoDB，协议似乎需要复杂，因为他们希望将其基于 maxLocalOpOrdinal（以避免在主重选时丢失过多数据）。我可以选择任何节点，因此基于 IP 的选举似乎让事情变得更简单。是的，我明白你关于网络分裂的观点，我想最初我需要 3 个以上的节点，除非大多数节点在线，否则他们不会进行选举。谢谢。
也非常感谢“领导选举”关键字。这带来了一些有用的维基百科知识。
Martin，再次感谢您的回答，它帮助我实现了共识算法的第一个版本，请参阅 GitHub 上的 majority.js。我们将看看它在实践中的效果如何。

【解决方案2】：

使用Apache ZooKeeper。它完全解决了this problem（以及更多）。

【讨论】：

嘿，谢谢你的回答，但我决定我不想把任何怪物的东西带入我的堆栈。而且 omfg 它是用 Java 编写的，这绝不是一个好兆头。 :) 如果您有兴趣，请在 GitHub 上查看我的 impl 的第一个版本为 majority.js。我们将看看它在实践中的效果如何。
您的代码不处理并发投票。假设节点 1 运行协议并选举主节点 A。同时节点 2 运行协议，节点 A 从节点 2 中分裂出来。节点 2 选举节点 B 作为主节点。现在你有两个主人。您需要实现 en.wikipedia.org/wiki/Paxos_algorithm 。这比它第一次出现要难。让 ZooKeeper 运行（不考虑语言偏见）比实现 Paxos 容易得多。 ad-hoc 领导者选举算法将大部分工作，然后在你身上突然失败。
Spike，感谢您的评论（现在才看到，抱歉）。在我的例子中，我从受信任的第三方 (Amazon S3) 中提取了一个权威的节点列表，因此节点只是避免改变他们的投票，除非超过一半的节点都可以访问。我相信这可以处理网络分裂。对吗？
我同样实现了 Apache Zookeper（通过 Netflix Curator API）来管理全球分布（德国、维里吉纳 - 美国、俄勒冈 - 美国）的 9 节点 Kafka 集群的 write-leader，并且可以证明这一点运作良好。避免脑裂的关键是使用奇数个节点和多数选举算法。

【解决方案3】：

如果您的节点还需要就事物及其总顺序达成一致，您可能需要考虑Paxos。这很复杂，但没有人想出更简单的分布式共识解决方案。

【讨论】：

您好，谢谢您的回答。现在我已经实现了一个非常简单的库，在 GitHub 上可以使用 majority.js。我们很快就会看到，也许我需要更复杂的东西——但我希望尽可能简单。
自从您的回答以来，已经创建了一种称为 Raft 的新算法。在“寻找可理解的共识算法”一文中，它被证明具有与 multi-Paxos 相同的属性和保证，但用户研究表明它明显更容易学习。它也有许多开源实现。
@AndreyTarantsov 选择最小 ID 作为主控的任何具体原因？
@user269867 它不必是最小的，但它必须是所有节点都同意的（即所有节点将以完全相同的方式计算）。

【解决方案4】：

我喜欢这个算法：

并且在下面的链接中有一些集群中的选举主节点算法： https://www.elastic.co/blog/found-leader-election-in-general#the-zen-way

也可以看到Raft-algorithm：https://raft.github.io

【讨论】：