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 回答