0

我的问题与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中都没有描述这些

4

1 回答 1

0

我承认，措辞有点令人困惑，但我已经广泛使用它。如果当前领导者失去连接，它不会阻塞任何超过会话超时的时间。LeaderLatch 为选举创建的节点是临时的。如果当前leader失去连接（你可以将行为配置为只在LOST时触发，而不是SUSPENDED），与之关联的leader节点将被服务器自动删除。这将在剩余的 LeaderLatch 参与者中触发新的选举，不同的服务器将成为新的领导者，恢复领导者的活动。您必须在连接和会话超时与快速故障转移的需求之间取得平衡。

我认为文档是指从断开连接的领导者的角度发生的事情。连接丢失后，LeaderLatch 将提醒所有本地侦听器它不再是领导者，因为在重新建立连接之前无法在本地确定它。一旦重新建立连接，它将重新加入领导池，但默认不会恢复领导。

于 2021-11-11T01:05:34.700 回答