我知道这对兵马俑是不公平的，但有人尝试过使用Hazelcast来在集群环境中使用定时任务吗？
我可以想象最简单的实现方式如下：
1.使用全局Hazelcast锁确保只有一个服务器启动Quartz配置。 2.将实际任务作为DistributedTask运行。（这可以之后再做，目前需要处理触发DistributedTask的重型定时任务） 3.当持有锁的服务器关闭时，另一个服务器获取锁。
我相信这将是对已经拥有Hazelcast的人们的巨大优势，因为他们不需要一直打开terracotta东西来避免整个dev-environment麻烦。
目前我编写了最简单的解决方案，使只有一个节点负责执行Quartz触发器。由于我只使用类似于Cron的触发器，如果我注意创建重型触发任务的DistributedTasks，则这可能是可接受的解决方案。
以下是我的org.springframework.scheduling.quartz.SchedulerFactoryBean扩展程序，让它成为现实：
请告诉我是否有遗漏，是否可以完成此操作。 我已将这两个文件添加到github。这是RAMJobStore扩展：
我可以想象最简单的实现方式如下：
1.使用全局Hazelcast锁确保只有一个服务器启动Quartz配置。 2.将实际任务作为DistributedTask运行。（这可以之后再做，目前需要处理触发DistributedTask的重型定时任务） 3.当持有锁的服务器关闭时，另一个服务器获取锁。
我相信这将是对已经拥有Hazelcast的人们的巨大优势，因为他们不需要一直打开terracotta东西来避免整个dev-environment麻烦。
目前我编写了最简单的解决方案，使只有一个节点负责执行Quartz触发器。由于我只使用类似于Cron的触发器，如果我注意创建重型触发任务的DistributedTasks，则这可能是可接受的解决方案。
以下是我的org.springframework.scheduling.quartz.SchedulerFactoryBean扩展程序，让它成为现实：
@Override
public void start() throws SchedulingException {
new Thread(new Runnable() {
@Override
public void run() {
final Lock lock = getLock();
lock.lock();
log.warn("This node is the master Quartz");
SchedulerFactoryBean.super.start();
}
}).start();
log.info("Starting..");
}
@Override
public void destroy() throws SchedulerException {
super.destroy();
getLock().unlock();
}
请告诉我是否有遗漏，是否可以完成此操作。 我已将这两个文件添加到github。这是RAMJobStore扩展：
这里是Spring SchedulerFactoryBean的扩展：