我的问题与Leader Latch配方有关。
我想使用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，则作为前导的LeaderLatch将报告它不再是前导（即，在重新建立连接之前不会有前导）。如果重新连接了LOST连接，则LeaderLatch将删除其以前的ZNode并创建一个新的ZNode。
LeaderLatch的用户必须考虑到连接问题可能导致失去领导。例如，hasLeadership（）返回true，但一段时间后连接被挂起或丢失。此时hasLeadership（）将返回false。强烈建议LeaderLatch用户注册ConnectionStateListener。
如果我没理解错的话，如果领导者I1（示例1）出现故障，那么其他示例将等待I1重新上线并重新建立连接。但如果I1再也没有恢复，会发生什么？其他示例是否能够成为领导者？如何以及何时？或者其他示例是否会被永远锁定？如何才能解锁？
我的期望是，不知何故，在幕后，应该有一个leader连接的超时。也许它可能与如何配置Curator客户端有关。也许当连接丢失时，会发生一些重新选择。但这些都没有在上面提到的错误处理部分或https://curator.apache.org/errors.html中描述
1条答案
按热度按时间4ioopgfo1#
我承认，措辞有点混乱，但我已经做过大量的工作。如果当前领导者失去连接，它不会阻塞任何东西超过会话超时。由LeaderLatch为选举创建的节点是短暂的。如果当前领导者失去连接（您可以将行为配置为仅在LOST而非SUSPENDED时触发），该服务器将自动删除与其关联的领导节点。这将在剩余的LeaderLatch参与者中触发新的选举，并且不同的服务器将成为新的领导者，恢复领导者的活动。您必须平衡连接和会话超时与快速故障转移的需要。
我认为文档是从断开连接的领导者的Angular 来看的。在连接丢失后，LeaderLatch会提醒任何本地监听者它不再是领导者，因为在连接重新建立之前，它无法在本地确定。一旦连接重新建立，它将重新加入领导池，但默认情况下它不会恢复领导。