简单的leader选举（无状态的leader选举）答案

【问题标题】：Simple leader election (Stateless leader election)简单的leader选举（无状态的leader选举）
【发布时间】：2020-08-02 14:39:30
【问题描述】：

我正在用 golang 构建一个应用程序，我希望它具有容错性。我查看了不同的算法，如 RAFT 和 Paxos 以及它们在 golang 中的实现（etcd 的 raft，hashicorp 的 raft），但我觉得它们对于我的特定用例来说可能是矫枉过正。

在我的应用程序中，节点只是在待机状态下等待，并在领导者失败时充当故障转移。我不需要在整个集群中复制任何状态。我只需要以下属性：

如果一个节点是领导者：

运行给定的代码

如果节点不是领导者：

等待领导失败
在现有领导失败后重新选举领导

有什么建议吗？

【问题讨论】：

骑在 etcd 的木筏上是个好主意。我想你可以看看leases。
这很吸引人，但是，我仍然有问题。没有会向该应用程序发出请求的“客户端”。因此，我并没有真正尝试跨应用程序实例复制任何日志（在我看来，RAFT 是在考虑这些假设的情况下构建的）。我要做的就是确保一次只运行一个实例，如果该实例失败，另一个实例将接手它。

标签： go failover etcd raft paxos

【解决方案1】：

既然您想要一个领导选举协议，听起来您想避免让多个节点同时充当领导者。答案实际上取决于您对该属性的要求有多严格。在某些情况下，偶尔有多个节点充当领导者是可以接受的；也许发生的最糟糕的事情是一些重复的工作。在其他情况下，如果有任何重复的领导者，整个系统可能会运行不正确，因此您必须更加小心。

如果您可以接受偶尔出现重复领导者的情况，那么更简单的协议可能适合您。但是，如果您绝对不能容忍同时拥有多个领导者，那么您将不得不将领导者选举协议与某种状态复制结合起来，而经过验证的 Paxos 或 Raft 或类似的实现是一种非常好的方法。 .有很多微妙不同的协议，但它们基本上都在做同样的事情。

这里的基本问题是确定“一次”在现实网络中的含义，其中有时可能会在很长的延迟后传递消息。通常假设网络是完全异步的，没有时间限制的交付，实际上 Paxos、Raft 等都被设计为在该假设下正常工作。这些算法通过定义自己的内部时间概念（Paxos 中的选票，Raft 中的术语）并将这个“内部时间”附加到它们控制下的所有状态转换来解决这个问题。这提供了一些非常强大的保证，特别是确保没有两个节点可以在同一“内部时间”作为领导者采取行动。

如果您不通过 Paxos 或 Raft 之类的工具复制任何状态，那么您将无法利用这种强大的内部时间概念。

【讨论】：

【解决方案2】：

如果您要针对特定用例将其部署在 Kubernetes 集群中，则可以使用客户端 go Kubernetes 库。 https://github.com/kubernetes-client/go

【讨论】：