我的问题与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来监视连接问题。如果报告挂起或丢失，则领导锁也就是说，领导将报告它不再是领导(即:在连接重新建立之前不会有leader)。如果当丢失的连接被重新连接时，LeaderLatch将删除它的连接创建一个新的ZNode。
LeaderLatch的用户必须考虑到连接问题可以导致领导力丧失。即hasLeadership()返回true，但是一段时间后，连接被挂起或丢失。在这一点上hasLeadership()将返回false。强烈建议LeaderLatch用户注册一个ConnectionStateListener。
如果我理解正确的话，如果leader I1(实例1)出现故障，那么其他实例将等待，直到I1重新联机并重新建立连接。但如果我再也起不来了怎么办?其他实例能够成为领导者吗?怎么做，什么时候?或者其他实例将永远被锁定?怎么才能解锁呢?
我的期望是，不知何故，在幕后，应该有一个超时的领导连接。这可能与如何配置策展人客户端有关。也许当失去连接时，会发生一些重新选举。但是在上面提到的错误处理部分和https://curator.apache.org/errors.html
中都没有描述这些。我承认，这种措辞有点令人困惑，但我经常使用这种方式。如果当前leader失去连接，它不会在会话超时时间之外阻止任何东西。由LeaderLatch为选举创建的节点是短暂的。如果当前的领导节点失去连接(您可以将该行为配置为只在LOST时触发，而不是SUSPENDED时触发)，与之关联的领导节点将被服务器自动删除。这将在剩余的LeaderLatch参与者中触发新的选举，并且不同的服务器将成为新的领导者，恢复领导者的活动。您必须在连接和会话超时与快速故障转移之间取得平衡。
我认为文档是指从断开连接的Leader的角度所发生的事情。在连接丢失后，LeaderLatch将提醒任何本地侦听器它不再是leader，因为在连接重新建立之前无法在本地确定它。一旦连接重新建立，它将重新加入领导池，但默认情况下它不会恢复领导。