问题标签 [leader-election]

我按照这篇文章为我的应用程序的 HA 使用 k8s 领导者选举。但我遇到了一个问题。有没有人有同样的经历？例如，我有 4 个 pod 副本。其中一个 pod 已被选为领导者。当这个 leader pod 宕机时（例如手动杀死 pod），调度器将需要 30-40 秒来启动一个新的 pod，但旧的死亡 leader 会保持 10 秒或更长时间来更新。有没有办法在领导者 pod 死亡时立即更新领导者？还是我错过了任何设置？

在我所指的文章中，它提到了以下内容，这正是我所遇到的问题：

因为 Kubernetes 中的 pod 在终止前有一个宽限期，这可能需要 30-40 秒。

这是我正在使用的演示 yaml 文件。 https://gist.githubusercontent.com/ginkgoch/563d8d8caf9e4dd99a0c8de323e9211c/raw/f1abb94647c60874e4625b1b94f8fa125bd1a5ea/k8s-leader-election.yaml

为什么在论文Paxos for System Builders: An Overview中需要单独的领导选举阶段，而不是使用准备阶段进行领导选举？与使用隐式准备阶段相比，这个附加阶段提供了哪些优势？

在分布式环境中是否有任何公认的领导者选举方法，其中领导者可能会在每个固定的时间间隔（或轮次）之后发生变化，而当前领导者不会关闭/断开连接？

这听起来可能是一种非常错误的方式，但我确实需要实施它，但找不到任何研究/参考。

我正在开发一个系统，我需要随机选择一个领导者（从 n 个节点中）。领导者会在每一轮后更换（当前领导者完成任务后）。所有节点都将相互通信。

重选将在两种情况下进行：

1. 回合结束。
2. 领袖过早地死去。

有没有这个想法的实现可供参考。这样做是个好主意吗？为什么？是否应该以不同的方式处理这种情况？

我很难理解领导者、追随者机制是如何工作的，假设我正在构建一个分布式应用程序，其中包含 2 个主节点、6 个从节点和 3 个 Zookeeper 节点，其中一个 Zookeeper 节点作为领导者，其中 2 个主节点 1 处于活动状态并且连接到 zookeeper 领导者。

我的问题是

1. 我的主节点是否因为其连接的 Zookeeper 领导者而被称为主节点，（即）我的节点被称为主节点，因为它的 Znode 连接到 Zookeeper 领导者？

2. 领导者 Zookeeper 节点死亡时是否会发生领导者选举机制？and how it will impact our master , does our master would be connected to the newly elected leader ?

3. 如果我们的应用程序的主节点死了，如果备用主节点监听主节点的znode，是否会收到通知，如果是这样，我们的备用节点是否有足够的临时顺序节点或我们需要做的任何其他事情才能使其成为主节点积极的？

4. Zookeeper 文档说，写入仅通过领导者发生，它广播到其他跟随者节点，读取直接从跟随者节点提供服务。这是否与我对我的应用程序所做的读写设计有任何关系（即）我打算设计我的写入必须通过我的主人发生并且读取是通过我的奴隶，动物园管理员的广播能力与它有什么关系？或者 zookeeper 的写入与应用程序的写入完全不同。

对不起，如果我问什么没有意义，请帮助我理解。任何解释这些的资源都会对我很有帮助。

我已经使用 kubernetes/client-go 领导选举实现了领导选举。我有 2 个副本。第一次两个 pod 都被选为领导者，但在此之后同一个 pod 没有被选为领导者。一段时间后，领导人选举停止了。我尝试删除一个 pod，然后将创建的新 pod 选为领导者。再次，一旦 pod 停止领导，没有 pod 充当领导者。我正在使用 configmap 进行资源锁定。请帮我解决问题。

我不确定我是否正确理解 Raft 中的 RequestVote RPC 详细信息。

在论文中，它说

当接收方收到 RequestVote RPC 时，什么情况下会voteFor == candidateId成立？候选人不会在同一任期内发送另一个 RequestVote RPC。如果它开始另一次选举，则任期将增加，因此接收者应转换为追随者和voteFor is null。

在我之前的 Raft 实现中，我的逻辑如下：

虽然明显是错误的，但似乎工作正常，即leader选举和发送requestVotes可以稳定工作。

任何建议将不胜感激，并提前致谢

基于 FLP 结果，异步网络系统中无法解决任何共识问题，选择唯一的领导者是一种共识问题。因此，理论上，leader选举在异步网络系统中是一个无法解决的问题。

但是，当我了解了“可靠广播”的概念后，每个非故障节点都负责广播它们从其他节点接收到的任何值，因此可以实现“每个非故障节点都获得相同的消息集（忽略命令）”。那么，如果每个节点都使用可靠的广播将其节点 ID 发送给其他节点，是否意味着最终每个非故障节点都将获得相同的节点 ID 集，从而能够决定相同的领导者（简单地说，具有最大我是领导者）？

如果是这样，那为什么说领导人选举无法解决？还是我对某事感到困惑？

有几个关于分布式系统的资源，比如推荐集群中奇数节点的mongo db 文档。

拥有奇数个节点有什么好处？

我正在尝试使用 JBotSim lib 实现两个分布式领导者选举算法，但我不知道这个 lib 或者它如何操作有人可以帮助我或有任何关于它的例子吗？