问题标签 [leader-election]

我有两个程序，fc(failoverController) 和 web(webServer)。我使用zookeeper来确保高可靠性。

fc会部署在两台服务器上，两台fc使用apache-curator LeaderSelector选举master，master会启动一个web进程，web进程提供服务。为了不放弃领导，我在函数 takeLeadership() 的末尾使用了 while(true)。

但是在某种情况下，我们自定义部署zookeeper在三个vmware esxi虚拟机上。他们每天都会对三个虚拟机（快照虚拟机内存）进行快照。

有一天，出现了一个奇怪的现象，fc1成为master，几毫秒，fc2成为master，前后的时间差很短。这在我们的程序中触发了一个错误，我们有两个 master。

为了解决这个问题，我们使用了一个 AtomBoolean var，声明 zk 状态是 LOST 还是 SUSPEND，并使用这个 var 标记是否退出 takeLeadership。

现在我想测试这两个master case，如何构建一个zookeeper jitter导致多次快速选举的场景。

我已经测试了以下操作，但无法重现：

1. zk 服务频繁重启。
2. 使用 tcpkill 杀死 fc 到 zk 端口之一。

我的问题与Leader Latch 配方有关。

我想使用领导者闩锁来为计划的作业实现互斥锁。还有另一个要求：如果计划的作业从下午 1:00:00.005 开始并在下午 1:00:00.015 结束，那么在下午 1:00:30.000 之前没有其他作业/实例应该开始相同的任务（为此我正在考虑在作业中实现异步发布）。

来自文档：https ://curator.apache.org/curator-recipes/leader-latch.html

错误处理

LeaderLatch 实例添加一个 ConnectionStateListener 来监视连接问题。如果报告了SUSPENDED或LOST，则作为leader的LeaderLatch会报告它不再是leader（即在重新建立连接之前不会有leader）。如果 LOST 连接被重新连接，LeaderLatch 将删除其先前的 ZNode 并创建一个新的。

LeaderLatch 的用户必须考虑到连接问题可能导致失去领导力。即 hasLeadership() 返回 true 但一段时间后连接被挂起或丢失。那时 hasLeadership() 将返回 false。强烈建议 LeaderLatch 用户注册 ConnectionStateListener。

如果我理解正确，如果领导者 I1（实例 1）出现故障，那么其他实例将等到 I1 重新联机并重新建立连接。但是如果 I1 不再起床会怎样？其他实例能否成为领导者？如何以及何时？或者其他实例会被永远锁定吗？它们如何被解锁？

我的期望是，不知何故，在幕后，领导者连接应该有一个超时。也许这可能与 Curator 客户端的配置方式有关。也许当连接丢失时，会发生一些重新选举。但是上面提到的错误处理部分和https://curator.apache.org/errors.html中都没有描述这些

ConfigMap 存在于正确的命名空间中，但收到无法构造对 configmap 的引用的错误，并且没有得到已成功要求领导者选举的确认。任何意见，将不胜感激

错误日志片段

我有一个带有 2 个容器的 pod

1. 默认调度程序

2. 扩展器控制器基于 kube builder

我希望领导者选举将针对同一个 pod 中的相同容器。我看到当部署为 2 时，我得到了 2 个 pod，但领导者选举在不同的 pod 中我如何将它们同步到同一个 pod 中？

我特别指的是 [Garcia-Molina 1982] 中描述的同步系统的欺凌算法。其中，故障检测超时具体定义为往返时间和消息处理时间之和。此外，如果它从更高的进程得到响应，但没有得到领导者通知，则在重新启动选举进程之前进程必须等待一个单独的超时。这个单独的超时是否有任何有效值？它可以是任意有限数并且仍然保证正确性吗？

似乎一个进程应该能够随时安全地开始选举，但我想知道是否存在某种启发式方法来获得比仅选择任意正有限值更优化的超时。

我有一个 .Net 核心应用程序，它由一些后台任务（托管服务）和 WEB API（控制和获取这些后台任务的状态）组成。其他应用程序（例如客户端）通过这些 WEB API 端点与该服务进行通信。我们希望该服务具有高可用性，即如果一个服务崩溃，那么另一个实例应该自动开始工作。此外，客户端应用程序应该能够自动切换到下一个服务（客户端应该调用新实例的 API，而不是旧实例）。

另一个重要要求是该服务在后台执行的任务（计算）不能在两个实例之间共享。我们必须确保在给定时间只有一个实例执行此任务。

到目前为止我所做的是，我运行了同一服务的两个实例，并使用基于 SQL 服务器的分布式锁定机制 ( SqlDistributedLock ) 来获取锁。如果服务可以获取锁，则在其他节点等待获取锁时继续执行操作。如果一个服务崩溃，下一个节点可以获取锁。在客户端，我使用基于Polly的重试机制将调用 URL 切换到下一个节点以找到工作节点。
但是这种设计有一个问题，如果获得锁的节点失去了与 SQL 服务器的连接，那么第二个服务设法获得锁并开始工作，而第一个服务也在做同样的事情。

我想我需要一些寻求领导人选举（似乎做错了），谁能帮助我更好地解决这类问题？

背景

部署系统使用最少 2 个实例来部署作业。但只需要 1 个。因此计划使用 Apache Curator 进行领导人选举。所以只有 1 个实例将启动作业，其他实例将被阻止

问题

1. 默认行为是当原始领导者重新启动时，追随者成为领导者。
2. 现在，之前被阻塞的追随者被解除阻塞并再次重新启动/重新部署作业
3. 这不是预期的，只有 1 个实例应该控制该作业。
4. 有什么方法可以在 ZK 本身中存储状态数据并在开始作业之前检索，这样如果之前的状态为空白，则当前主机是真正的领导者，如果它之前具有跟随者状态，则可以跳过执行。

有什么其他的建议来实现这个吗？

编辑 1

能够加入Apache Curator库并进行领导者选举。但这个问题与leader选举并不完全相同。

它应该通过避免多次重新启动来处理重新启动和重新部署方案。

编辑 2

详细说明场景和可能的解决方案

前提

• 主机 A 和主机 B
• A : 领导者，启动了工作并拥有领导者闩锁（策展人库）
• B : 跟随者阻塞

重启/重新部署

• Case 1 --> A 先重启

  • A 松开前导闩锁
  • B 是领导者并且被解除阻塞<--重新启动/当前。版本
  • A 出现并充当跟随者
  • B现在重新开始失去领导权
  • A 作为领导者被畅通无阻 <--重新启动/新版本 = B 出现并充当跟随者

• 案例 2 --> B 先重启

  • B 出现并充当追随者 = A 重新开始现在失去领导权
  • B 是领导者并且被解除阻塞<--重启/新版本
  • A 出现并充当跟随者

笔记

这个问题虽然提到了 Java，但这是我想要实现的。该方法是预期的，解决方案不必专门在 Java 中。

我试图了解 etcd 选举 api 提供的各种功能以及它们在语义上的含义。

在他们的官方文档中非常简要地提到了每个函数的作用，并且没有提供示例。例如我们有方法：

根据我的理解，活动用于在选举中注册节点以担任领导，并且在实现这一目标或发生某些错误之前会被阻止。

这个我不确定为什么我们需要恢复选举，假设节点已经是领导者。也许我缺乏理解是由于这里使用的语义。

既然我们必须使用一个通用的选举标识符，为什么单次选举就不够了？

最后，我的用例是运行多个节点，只允许领导者进行一些计算/更新，在什么情况下，如果单次选举不够，我必须创建新的选举。