Curator提供了两种选举方案：Leader Latch和Leader Election
Leader Latch
随机从候选着中选出一台作为leader，选中之后除非调用close()释放leadship，否则其他的后选择无法成为leader。其中Spark使用的就是这种方法。
Leader Election
通过LeaderSelectorListener可以对领导权进行控制， 在适当的时候释放领导权，这样每个节点都有可能获得领导权。 而LeaderLatch则一直持有leadership， 除非调用close方法，否则它不会释放领导权。
通过Leader选举可以选举出一台机器来执行定时任务。这里有两种选择：
- 选出Leader之后，以后所有的定时任务都由此台机器执行。
- 每次到执行Job的时候重新进行一次竞选，成为Leader者进行执行。
针对以上两种情况就需要考虑一下问题：
- 第一种方案如果Leader选出之后，Leader在执行定时任务宕机，后面如何进行重新Leader选举；
- 第二种方案如果服务器的时间不一致如何处理？如果每台机器Job执行的时间不一致如何处理？如果任务执行的时间很短暂，Leader执行之后马上释放，后面因网络延迟等原因又获得Leader权限重新执行了任务，如何处理？
- 定时任务的幂等性保证。
以上问题在不同的业务场景下需要有不同的处理，在使用的过程中需要因场景而进行变通。
