我正在用 golang 构建一个应用程序，我希望它具有容错能力。我研究了不同的算法，如 RAFT 和 Paxos 以及它们在 golang 中的实现(etcd 的 raft，hashicorp 的 raft)，但我觉得它们对于我的特定用例来说可能有点矫枉过正。
在我的应用程序中，节点只是处于待机状态，并在领导者出现故障时充当故障转移。我不需要在整个集群中复制任何状态。我只需要以下属性:
如果一个节点是领导者:
- 运行给定的代码
如果一个节点不是领导者:
- 等待领导失败
- 一旦现有领导者失败，重新选举领导者
有什么建议吗？
最佳答案
既然你想要一个领导者选举协议(protocol)，听起来你想要避免让多个节点同时充当领导者。答案实际上取决于您对该属性的要求有多严格。在某些情况下，偶尔有多个节点充当领导者是可以接受的；也许最糟糕的情况是重复工作。在其他情况下，如果存在任何重复的领导者，整个系统可能无法正常运行，因此您必须更加小心。
如果您可以接受偶尔出现重复领导者的情况，那么更简单的协议(protocol)可能适合您。然而，如果你绝对不能容忍同时拥有多个领导者，那么你将不得不将你的领导者选举协议(protocol)与某种状态复制结合起来，并且经过验证的 Paxos 或 Raft 或类似的实现是一个很好的方法来做到这一点.对此有许多细微不同的协议(protocol)，但它们基本上都在做同样的事情。
这里的根本问题是确定“立即”在现实网络中的含义，在现实网络中，消息有时可能会在很长的延迟后才能传递。通常，人们假设网络是完全异步的，并且在交付时没有时间限制，实际上 Paxos、Raft 等都被设计为在该假设下正常工作。这些算法通过定义它们自己的内部时间概念(Paxos 中的选票，Raft 中的术语)并将这个“内部时间”附加到它们控制下的所有状态转换来解决这个问题。这提供了一些非常强大的保证，特别是确保没有两个节点可以在同一“内部时间”作为领导者采取行动。
如果您不通过类似 Paxos 或 Raft 的东西复制任何状态，那么您将无法利用这种强大的内部时间概念。
关于go - 简单的领导人选举(Stateless leader election)，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/61316620/