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

Question

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

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

如果一个节点是领导者：

• 运行给定的代码

如果节点不是领导者：

• 等待领导者失败

• 一旦现有领导者失败，重新选举领导者

有什么建议么？

Answer 1

由于您想要一个领导者选举协议，因此听起来您希望避免让多个节点同时充当领导者。答案实际上取决于您对该属性的要求有多严格。在某些情况下，偶尔有多个节点充当领导者是可以接受的；也许发生的最糟糕的事情是一些重复的工作。在其他情况下，如果有任何重复的领导者，整个系统可能会运行不正确，因此您必须更加小心。如果您可以接受偶尔出现重复领导者的情况，那么更简单的协议可能适合您。但是，如果您绝对不能容忍同时拥有多个领导者，那么您将不得不将领导者选举协议与某种状态复制结合起来，而经过验证的 Paxos 或 Raft 或类似的实现是一种非常好的方法。 . 有很多微妙不同的协议，但它们基本上都在做同样的事情。这里的基本问题是确定“一次”在现实网络中的含义，其中有时可能会在很长的延迟后传递消息。通常假设网络是完全异步的，没有时间限制的交付，实际上 Paxos、Raft 等都被设计为在该假设下正常工作。这些算法通过定义自己的内部时间概念（Paxos 中的选票，Raft 中的术语）并将这个“内部时间”附加到它们控制下的所有状态转换来解决这个问题。这提供了一些非常强大的保证，特别是确保没有两个节点可以在同一“内部时间”作为领导者采取行动。如果你不通过 Paxos 或 Raft 之类的东西复制任何状态，那么你将无法利用这种强大的内部时间概念。

Answer 2

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