Go Webapp Cluster Leader选举

Question

我正在编写一个相当复杂的 Go webapp，我想让它高度可用。我计划让多个 VM 运行该应用程序，并使用负载平衡器根据我的需要在它们之间引导流量。

它变得复杂的地方在于 webapp 有一种数据库簿记例程在运行，我只想要（最多）任何时候的一个实例。因此，如果我有三个 webapp 虚拟机，那么只有其中一个应该进行簿记。

（是的，我知道我可以将簿记完全拆分为一个单独的 VM 实例，但代码已与 web 应用程序的其余部分高度集成。）

我花了几个小时研究etcd、raft、bully、memberlist、Pacemaker等等。这些似乎都需要吸收很多信息来完成我所追求的目标，或者我看不到使用它们的明确方法。

在这个特定用例中，我想要的是一个系统，让 Go webapp 节点自动检测彼此并选举一个“领导者”来进行簿记。理想情况下，这可以扩展到 2 到 10 个节点，并且不需要手动将 IP 地址添加到配置文件（但可能，如有必要）。

我在想在网络分区或其他节点无法看到其他节点的情况下，我不希望它选举自己作为领导者，因为有可能有两个节点试图在同时。这也意味着，如果我将集群精简为单个 VM，则不会发生簿记，但在维护期间可以容忍一小段时间，或者我可以在某处设置某种标志。

我想知道是否有人可以为我指出正确的方向，希望我如何能够以低复杂度实现这一目标，同时尽可能地利用现有的代码库。

Answer 1

根据您的容错和一致性要求 - 特别是防止分区中的脑裂 - 像 Raft 这样的共识算法是您最想要的。但是即使 Raft 是为可理解性而设计的，它仍然需要大量的专业知识才能正确实施。因此，正如其他人所提到的，您应该研究现有的服务或实现。ZooKeeper (ZAB)、etcd (Raft) 和Consul (Raft) 是用于执行此类操作的最广泛使用的系统。考虑到您希望虚拟机从 2 个节点扩展到 10 个节点，这很可能是您想要的方式。Raft 和其他共识算法有仲裁要求，如果算法直接嵌入到您的 VM 中，则以这种方式进行扩展可能不太实用。通过使用外部服务，您的 VM 只需成为共识服务的客户端，并且可以独立于它进行扩展。或者，如果您不想依赖外部服务进行协调，Raft 网站提供了各种语言的详尽实现列表，其中一些是共识服务，一些可以嵌入。但是，请注意其中许多是不完整的。至少，任何适用于生产的 Raft 实现都必须实现日志压缩。如果没有日志压缩，服务器实际上只能运行有限的时间 - 直到磁盘填满日志。