博客

使用zookeeper实现分布式集群定时任务组件

在我们实现定时任务时，难以达到分布式集群的稳定和高可用。在使用集群方案时，如果触发器也采用单点部署，则在单点发生服务器或是网络故障的情况下，也不能够满足高可用的需要；如果采用多点部署，则会存在定时任务会被执行多次的问题，如果采用同步机智，实现逻辑会比较复杂。有没有一种两全其美的解决方案呢，下面我来介绍如何通过zookeeper实现分布式集群定时任务的。

实现原理

运用zookeeper选举leader的功能，将leader作为触发器，将任务加载到quartz中；slave节点则作为服务提供者，接受leader节点的调度。

当leader发生故障时，zookeeper会重新选举leader，前leader在失去领导位置时从quartz中删除任务，新的leader则将任务加载到quartz中，成为新的调度者。

LeaderLatch

运用LeaderLatch可完成节点的leader选举，监听leader关系变化的。使用如下代码，即可很方便地完成初始化。

CuratorFramework curatorFramework = CuratorFrameworkFactory.newClient("127.0.0.1:2181", new ExponentialBackoffRetry(1000, 3));
LeaderLatch leaderLatch = new LeaderLatch(curatorFramework , /leader);

–start()

启动选举方法，LeaderLatch会和其它使用相同latch path的其它LeaderLatch交涉，然后其中一个最终会被选举为leader

–await(long timeout,TimeUnit unit)

等待知道选举出结果，或是超时。返回true，则当前节点被选举为leader节点。

–hasLeadership()

可以通过hasLeadership方法查看LeaderLatch实例是否leader，返回true说明当前实例是leader

–addListener

添加leader变化的监听类，当注册到zk同一目录下的节点发生变化时，会触发该监听类的对应方法。详情见下问LeaderLatchListener的介绍。

LeaderLatchListener

此类的对象添加到LeaderLatch中，可对zk的leader变化进行监听，当leader发生变法时，会调用此类下的方法。

–notifyLeader（）

当节点被选举为leader时，会触发此方法。

–notifyNotLeader（）

当节点失去leader时，会触发此方法。

实现示例

CuratorFramework curatorFramework = CuratorFrameworkFactory.newClient("127.0.0.1:2181", new ExponentialBackoffRetry(1000, 3));
LeaderLatch leaderLatch = new LeaderLatch(curatorFramework , /leader);
leaderLatch.addListener(new LeaderLatchListener() {
         @Override
          public void isLeader() {
              addSchdule();//将定时任务添加到quartz
          }

          @Override
          public void notLeader() {
              deleteSchedule;//从quartz中移除定时任务
          }
});
leaderLatch.start();
if(leaderLatch.await(10, TimeUnit.SECONDS)){
	addSchdule();//将定时任务添加到quartz
}