第四十章：基于SpringBoot & Quartz完成定时任务分布式多节点负载持久化

最新推荐文章于 2023-08-02 15:17:22 发布
最新推荐文章于 2023-08-02 15:17:22 发布
阅读量1.1k 收藏 3
点赞数
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_42033269/article/details/101477925
版权

在上一章【第三十九章：基于SpringBoot & Quartz完成定时任务分布式单节点持久化】中我们已经完成了任务的持久化，当我们创建一个任务时任务会被quartz定时任务框架自动持久化到数据库，我们采用的是SpringBoot项目托管的dataSource来完成的数据源提供，当然也可以使用quartz内部配置数据源方式，我们的标题既然是提到了定时任务的分布式多节点，那么怎么才算是多节点呢？当有节点故障或者手动停止运行后是否可以自动漂移任务到可用的分布式节点呢？

本章目标

  1. 完成定时任务分布式多节点配置，当单个节点关闭时其他节点自动接管定时任务。
  2. 创建任务时传递自定义参数，方便任务处理后续业务逻辑。

SpringBoot 企业级核心技术学习专题

专题专题名称专题描述
001Spring Boot 核心技术讲解SpringBoot一些企业级层面的核心组件
002Spring Boot 核心技术章节源码Spring Boot 核心技术简书每一篇文章码云对应源码
003Spring Cloud 核心技术对Spring Cloud核心技术全面讲解
004Spring Cloud 核心技术章节源码Spring Cloud 核心技术简书每一篇文章对应源码
005QueryDSL 核心技术全面讲解QueryDSL核心技术以及基于SpringBoot整合SpringDataJPA
006SpringDataJPA 核心技术全面讲解SpringDataJPA核心技术
007SpringBoot核心技术学习目录SpringBoot系统的学习目录，敬请关注点赞！！!

构建项目

注意：我们本章项目需要结合上一章共同完成，有一点要注意的是任务在持久化到数据库内时会保存任务的全路径，如：com.hengyu.chapter39.timers.GoodStockCheckTimer ，quartz在运行任务时会根据任务全路径去执行，如果不一致则会提示找不到指定类，我们本章在创建项目时package需要跟上一章完全一致。

我们这里就不去直接创建新项目了，直接复制上一章项目的源码为新的项目命名为Chapter40

配置分布式

在上一章配置文件quartz.properties中我们其实已经为分布式做好了相关配置，下面我们就来看一下分布式相关的配置。
分布式相关配置：

1. org.quartz.scheduler.instanceId ： 定时任务的实例编号，如果手动指定需要保证每个节点的唯一性，因为quartz不允许出现两个相同instanceId的节点，我们这里指定为Auto就可以了，我们把生成编号的任务交给quartz。

2. org.quartz.jobStore.isClustered： 这个属性才是真正的开启了定时任务的分布式配置，当我们配置为true时quartz框架就会调用ClusterManager来初始化分布式节点。

3. org.quartz.jobStore.clusterCheckinInterval：配置了分布式节点的检查时间间隔，单位：毫秒。
下面是quartz.properties配置文件配置信息：

#调度器实例名称
org.quartz.scheduler.instanceName = quartzScheduler

#调度器实例编号自动生成
org.quartz.scheduler.instanceId = AUTO

#持久化方式配置
org.quartz.jobStore.class = org.quartz.impl.jdbcjobstore.JobStoreTX

#持久化方式配置数据驱动，MySQL数据库
org.quartz.jobStore.driverDelegateClass = org.quartz.impl.jdbcjobstore.StdJDBCDelegate

#quartz相关数据表前缀名
org.quartz.jobStore.tablePrefix = QRTZ_

#开启分布式部署
org.quartz.jobStore.isClustered = true
#配置是否使用
org.quartz.jobStore.useProperties = false

#分布式节点有效性检查时间间隔，单位：毫秒
org.quartz.jobStore.clusterCheckinInterval = 10000

#线程池实现类
org.quartz.threadPool.class = org.quartz.simpl.SimpleThreadPool

#执行最大并发线程数量
org.quartz.threadPool.threadCount = 10

#线程优先级
org.quartz.threadPool.threadPriority = 5

#配置为守护线程，设置后任务将不会执行
#org.quartz.threadPool.makeThreadsDaemons=true

#配置是否启动自动加载数据库内的定时任务，默认true
org.quartz.threadPool.threadsInheritContextClassLoaderOfInitializingThread = true

当我们启动任务节点时，会根据org.quartz.threadPool.threadsInheritContextClassLoaderOfInitializingThread属性配置进行是否自动加载任务，默认true自动加载数据库内的任务到节点。

测试分布式

上一章项目节点名称：quartz-cluster-node-first
本章项目节点名称：quartz-cluster-node-second

由于我们quartz-cluster-node-first的商品库存检查定时任务是每隔30秒执行一次，所以任务除非手动清除否则是不会被清空的，在运行项目测试之前需要将application.yml配置文件的端口号、项目名称修改下，保证quartz-cluster-node-second与quartz-cluster-node-first端口号不一致，可以同时运行，修改后为：

spring:
    application:
        name: quzrtz-cluster-node-second
server:
  port: 8082

然后修改相应控制台输出，为了能够区分任务执行者是具体的节点。

Chapter40Application启动类修改日志输出：
logger.info("【【【【【【定时任务分布式节点 - quartz-cluster-node-second 已启动】】】】】】");

GoodAddTimer商品添加任务类修改日志输出：
logger.info("分布式节点quartz-cluster-node-second，商品添加完成后执行任务，任务时间：{}",new Date());

GoodStockCheckTimer商品库存检查任务类修改日志输出：
logger.info("分布式节点quartz-cluster-node-second，执行库存检查定时任务，执行时间：{}",new Date());

下面我们启动本章项目，查看控制台输出内容，如下所示：

2017-11-12 10:28:39.969  INFO 11048 --- [           main] c.hengyu.chapter39.Chapter40Application  : 【【【【【【定时任务分布式节点 - quartz-cluster-node-second 已启动】】】】】】
2017-11-12 10:28:41.930  INFO 11048 --- [lerFactoryBean]] o.s.s.quartz.SchedulerFactoryBean        : Starting Quartz Scheduler now, after delay of 2 seconds
2017-11-12 10:28:41.959  INFO 11048 --- [lerFactoryBean]] org.quartz.core.QuartzScheduler          : Scheduler schedulerFactoryBean_$_yuqiyu1510453719308 started.
2017-11-12 10:28:51.963  INFO 11048 --- [_ClusterManager] o.s.s.quartz.LocalDataSourceJobStore     : ClusterManager: detected 1 failed or restarted instances.
2017-11-12 10:28:51.963  INFO 11048 --- [_ClusterManager] o.s.s.quartz.LocalDataSourceJobStore     : ClusterManager: Scanning for instance "yuqiyu1510450938654"'s failed in-progress jobs.
2017-11-12 10:28:51.967  INFO 11048 --- [_ClusterManager] o.s.s.quartz.LocalDataSourceJobStore     : ClusterManager: ......Freed 1 acquired trigger(s).
2017-11-12 10:29:00.024  INFO 11048 --- [ryBean_Worker-1] c.h.c.timers.GoodStockCheckTimer         : 分布式节点quartz-cluster-node-second，执行库存检查定时任务，执行时间：Sun Nov 12 10:29:00 CST 2017

可以看到项目启动完成后自动分配的instanceId为yuqiyu1510450938654，生成的规则是当前用户的名称+时间戳。然后ClusterManager分布式管理者自动介入进行扫描是否存在匹配的触发器任务，如果存在则会自动执行任务逻辑，而商品库存检查定时任务确实由quartz-cluster-node-second进行输出的。

测试任务自动漂移

下面我们也需要把quartz-cluster-node-first的输出进行修改，如下所示：

Chapter39Application启动类修改日志输出：
logger.info("【【【【【【定时任务分布式节点 - quartz-cluster-node-first 已启动】】】】】】");

GoodAddTimer商品添加任务类修改日志输出：
logger.info("分布式节点quartz-cluster-node-first，商品添加完成后执行任务，任务时间：{}",new Date());

GoodStockCheckTimer商品库存检查任务类修改日志输出：
logger.info("分布式节点quartz-cluster-node-first，执行库存检查定时任务，执行时间：{}",new Date());

接下来我们启动quartz-cluster-node-first，并查看控制台的输出内容：

2017-11-12 10:34:09.750  INFO 192 --- [           main] c.hengyu.chapter39.Chapter39Application  : 【【【【【【定时任务分布式节点 - quartz-cluster-node-first 已启动】】】】】】
2017-11-12 10:34:11.690  INFO 192 --- [lerFactoryBean]] o.s.s.quartz.SchedulerFactoryBean        : Starting Quartz Scheduler now, after delay of 2 seconds
2017-11-12 10:34:11.714  INFO 192 --- [lerFactoryBean]] org.quartz.core.QuartzScheduler          : Scheduler schedulerFactoryBean_$_yuqiyu1510454049066 started.

项目启动完成后，定时节点并没有实例化ClusterManager来完成分布式节点的初始化，因为quartz检测到有其他的节点正在处理任务，这样也是保证了任务执行的唯一性。

关闭quartz-cluster-node-second

我们关闭quartz-cluster-node-second运行的项目，预计的目的可以达到quartz-cluster-node-first会自动接管数据库内的任务，完成任务执行的自动漂移，我们来查看quartz-cluster-node-first的控制台输出内容：

2017-11-12 10:34:09.750  INFO 192 --- [           main] c.hengyu.chapter39.Chapter39Application  : 【【【【【【定时任务分布式节点 - quartz-cluster-node-first 已启动】】】】】】
2017-11-12 10:34:11.690  INFO 192 --- [lerFactoryBean]] o.s.s.quartz.SchedulerFactoryBean        : Starting Quartz Scheduler now, after delay of 2 seconds
2017-11-12 10:34:11.714  INFO 192 --- [lerFactoryBean]] org.quartz.core.QuartzScheduler          : Scheduler schedulerFactoryBean_$_yuqiyu1510454049066 started.
2017-11-12 10:41:11.793  INFO 192 --- [_ClusterManager] o.s.s.quartz.LocalDataSourceJobStore     : ClusterManager: detected 1 failed or restarted instances.
2017-11-12 10:41:11.793  INFO 192 --- [_ClusterManager] o.s.s.quartz.LocalDataSourceJobStore     : ClusterManager: Scanning for instance "yuqiyu1510453719308"'s failed in-progress jobs.
2017-11-12 10:41:11.797  INFO 192 --- [_ClusterManager] o.s.s.quartz.LocalDataSourceJobStore     : ClusterManager: ......Freed 1 acquired trigger(s).
2017-11-12 10:41:11.834  INFO 192 --- [ryBean_Worker-1] c.h.c.timers.GoodStockCheckTimer         : 分布式节点quartz-cluster-node-first，执行库存检查定时任务，执行时间：Sun Nov 12 10:41:11 CST 2017

控制台已经输出了持久的定时任务，输出节点是quartz-cluster-node-first，跟我们预计的一样，节点quartz-cluster-node-first完成了自动接管quartz-cluster-node-second的工作，而这个过程肯定有一段时间间隔，而这个间隔可以修改quartz.properties配置文件内的属性org.quartz.jobStore.clusterCheckinInterval进行调节。

关闭quartz-cluster-node-first

我们同样可以测试启动任务节点quartz-cluster-node-second后，再关闭quartz-cluster-node-first任务节点，查看quartz-cluster-node-second控制台的输出内容：

2017-11-12 10:53:31.010  INFO 3268 --- [           main] c.hengyu.chapter39.Chapter40Application  : 【【【【【【定时任务分布式节点 - quartz-cluster-node-second 已启动】】】】】】
2017-11-12 10:53:32.967  INFO 3268 --- [lerFactoryBean]] o.s.s.quartz.SchedulerFactoryBean        : Starting Quartz Scheduler now, after delay of 2 seconds
2017-11-12 10:53:32.992  INFO 3268 --- [lerFactoryBean]] org.quartz.core.QuartzScheduler          : Scheduler schedulerFactoryBean_$_yuqiyu1510455210493 started.
2017-11-12 10:53:52.999  INFO 3268 --- [_ClusterManager] o.s.s.quartz.LocalDataSourceJobStore     : ClusterManager: detected 1 failed or restarted instances.
2017-11-12 10:53:52.999  INFO 3268 --- [_ClusterManager] o.s.s.quartz.LocalDataSourceJobStore     : ClusterManager: Scanning for instance "yuqiyu1510454049066"'s failed in-progress jobs.
2017-11-12 10:53:53.003  INFO 3268 --- [_ClusterManager] o.s.s.quartz.LocalDataSourceJobStore     : ClusterManager: ......Freed 1 acquired trigger(s).
2017-11-12 10:54:00.020  INFO 3268 --- [ryBean_Worker-1] c.h.c.timers.GoodStockCheckTimer         : 分布式节点quartz-cluster-node-second，执行库存检查定时任务，执行时间：Sun Nov 12 10:54:00 CST 2017

得到的结果是同样可以完成任务的自动漂移。

如果两个节点同时启动，哪个节点先把节点信息注册到数据库就获得了优先执行权。

传递参数到任务

我们平时在使用任务时，如果是针对性比较强的业务逻辑，肯定需要特定的参数来完成业务逻辑的实现。

下面我们来模拟商品秒杀的场景，当我们添加商品后自动添加一个商品提前五分钟的秒杀提醒，为关注该商品的用户发送提醒消息。
我们在节点quartz-cluster-node-first中添加秒杀提醒任务，如下所示：

package com.hengyu.chapter39.timers;

import org.quartz.JobDataMap;
import org.quartz.JobExecutionContext;
import org.quartz.JobExecutionException;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.scheduling.quartz.QuartzJobBean;

/**
 * 商品秒杀提醒定时器
 * 为关注该秒杀商品的用户进行推送提醒
 * ========================
 *
 * @author 恒宇少年
 * Created with IntelliJ IDEA.
 * Date：2017/11/12
 * Time：9:23
 * 码云：http://git.oschina.net/jnyqy
 * ========================
 */
public class GoodSecKillRemindTimer
extends QuartzJobBean
{
    /**
     * logback
     */
    private Logger logger = LoggerFactory.getLogger(GoodSecKillRemindTimer.class);

    /**
     * 任务指定逻辑
     * @param jobExecutionContext
     * @throws JobExecutionException
     */
    @Override
    protected void executeInternal(JobExecutionContext jobExecutionContext) throws JobExecutionException {
        //获取任务详情内的数据集合
        JobDataMap dataMap = jobExecutionContext.getJobDetail().getJobDataMap();
        //获取商品编号
        Long goodId = dataMap.getLong("goodId");
        
        logger.info("分布式节点quartz-cluster-node-first，开始处理秒杀商品：{}，关注用户推送消息.",goodId);

        //.../
    }
}

在秒杀提醒任务逻辑中，我们通过获取JobDetail的JobDataMap集合来获取在创建任务的时候传递的参数集合，我们这里约定了goodId为商品的编号，在创建任务的时候传递到JobDataMap内，这样quartz在执行该任务的时候就会自动将参数传递到任务逻辑中，我们也就可以通过JobDataMap获取到对应的参数值。

设置秒杀提醒任务

我们找到节点项目quartz-cluster-node-first中的GoodInfoService，编写方法buildGoodSecKillRemindTimer设置秒杀提醒任务，如下所示：

/**
     * 构建商品秒杀提醒定时任务
     * 设置五分钟后执行
     * @throws Exception
     */
    public void buildGoodSecKillRemindTimer(Long goodId) throws Exception
    {
        //任务名称
        String name = UUID.randomUUID().toString();
        //任务所属分组
        String group = GoodSecKillRemindTimer.class.getName();
        //秒杀开始时间
        long startTime = System.currentTimeMillis() + 1000 * 5 * 60;
        JobDetail jobDetail = JobBuilder
                .newJob(GoodSecKillRemindTimer.class)
                .withIdentity(name,group)
                .build();

        //设置任务传递商品编号参数
        jobDetail.getJobDataMap().put("goodId",goodId);

        //创建任务触发器
        Trigger trigger = TriggerBuilder.newTrigger().withIdentity(name,group).startAt(new Date(startTime)).build();
        //将触发器与任务绑定到调度器内
        scheduler.scheduleJob(jobDetail,trigger);
    }

我们模拟秒杀提醒时间是添加商品后的5分钟，我们通过调用jobDetail实例的getJobDataMap方法就可以获取该任务数据集合，直接调用put方法就可以进行设置指定key的值，该集合继承了StringKeyDirtyFlagMap并且实现了Serializable序列化，因为需要将数据序列化到数据库的qrtz_job_details表内。
修改保存商品方法，添加调用秒杀提醒任务：

    /**
     * 保存商品基本信息
     * @param good 商品实例
     * @return
     */
    public Long saveGood(GoodInfoEntity good) throws Exception
    {
        goodInfoRepository.save(good);
        //构建创建商品定时任务
        buildCreateGoodTimer();
        //构建商品库存定时任务
        buildGoodStockTimer();
        //构建商品描述提醒定时任务
        buildGoodSecKillRemindTimer(good.getId());
        return good.getId();
    }
添加测试商品

下面我们调用节点quartz-cluster-node-first的测试Chapter39ApplicationTests.addGood方法完成商品的添加，由于我们的quartz-cluster-node-second项目并没有停止，所以我们在quartz-cluster-node-second项目的控制台查看输出内容：

2017-11-12 11:45:00.008  INFO 11652 --- [ryBean_Worker-5] c.h.c.timers.GoodStockCheckTimer         : 分布式节点quartz-cluster-node-second，执行库存检查定时任务，执行时间：Sun Nov 12 11:45:00 CST 2017
2017-11-12 11:45:30.013  INFO 11652 --- [ryBean_Worker-6] c.h.c.timers.GoodStockCheckTimer         : 分布式节点quartz-cluster-node-second，执行库存检查定时任务，执行时间：Sun Nov 12 11:45:30 CST 2017
2017-11-12 11:45:48.230  INFO 11652 --- [ryBean_Worker-7] c.hengyu.chapter39.timers.GoodAddTimer   : 分布式节点quartz-cluster-node-second，商品添加完成后执行任务，任务时间：Sun Nov 12 11:45:48 CST 2017
2017-11-12 11:46:00.008  INFO 11652 --- [ryBean_Worker-8] c.h.c.timers.GoodStockCheckTimer         : 分布式节点quartz-cluster-node-second，执行库存检查定时任务，执行时间：Sun Nov 12 11:46:00 CST 2017
2017-11-12 11:46:30.016  INFO 11652 --- [ryBean_Worker-9] c.h.c.timers.GoodStockCheckTimer         : 分布式节点quartz-cluster-node-second，执行库存检查定时任务，执行时间：Sun Nov 12 11:46:30 CST 2017
2017-11-12 11:47:00.011  INFO 11652 --- [yBean_Worker-10] c.h.c.timers.GoodStockCheckTimer         : 分布式节点quartz-cluster-node-second，执行库存检查定时任务，执行时间：Sun Nov 12 11:47:00 CST 2017
2017-11-12 11:47:30.028  INFO 11652 --- [ryBean_Worker-1] c.h.c.timers.GoodStockCheckTimer         : 分布式节点quartz-cluster-node-second，执行库存检查定时任务，执行时间：Sun Nov 12 11:47:30 CST 2017
2017-11-12 11:48:00.014  INFO 11652 --- [ryBean_Worker-2] c.h.c.timers.GoodStockCheckTimer         : 分布式节点quartz-cluster-node-second，执行库存检查定时任务，执行时间：Sun Nov 12 11:48:00 CST 2017
2017-11-12 11:48:30.013  INFO 11652 --- [ryBean_Worker-3] c.h.c.timers.GoodStockCheckTimer         : 分布式节点quartz-cluster-node-second，执行库存检查定时任务，执行时间：Sun Nov 12 11:48:30 CST 2017
2017-11-12 11:49:00.010  INFO 11652 --- [ryBean_Worker-4] c.h.c.timers.GoodStockCheckTimer         : 分布式节点quartz-cluster-node-second，执行库存检查定时任务，执行时间：Sun Nov 12 11:49:00 CST 2017
2017-11-12 11:49:30.028  INFO 11652 --- [ryBean_Worker-5] c.h.c.timers.GoodStockCheckTimer         : 分布式节点quartz-cluster-node-second，执行库存检查定时任务，执行时间：Sun Nov 12 11:49:30 CST 2017
2017-11-12 11:49:48.290  INFO 11652 --- [ryBean_Worker-6] c.h.c.timers.GoodSecKillRemindTimer      : 分布式节点quartz-cluster-node-second，开始处理秒杀商品：15，关注用户推送消息.
2017-11-12 11:50:00.008  INFO 11652 --- [ryBean_Worker-7] c.h.c.timers.GoodStockCheckTimer         : 分布式节点quartz-cluster-node-second，执行库存检查定时任务，执行时间：Sun Nov 12 11:50:00 CST 2017

秒杀任务在添加完成商品后的五分钟开始执行的，而我们也正常的输出了传递过去的goodId商品编号的参数，而秒杀提醒任务执行一次后也被自动释放了。

总结

本章主要是结合上一章完成了分布式任务的讲解，完成了测试持久化的定时任务自动漂移，以及如何向定时任务传递参数。当然在实际的开发过程中，任务创建是需要进行封装的，目的也是为了减少一些冗余代码以及方面后期统一维护定时任务。

本章源码已经上传到码云：
SpringBoot配套源码地址：https://gitee.com/hengboy/spring-boot-chapter
SpringCloud配套源码地址：https://gitee.com/hengboy/spring-cloud-chapter
SpringBoot相关系列文章请访问：目录：SpringBoot学习目录
QueryDSL相关系列文章请访问：QueryDSL通用查询框架学习目录
SpringDataJPA相关系列文章请访问：目录：SpringDataJPA学习目录
SpringBoot相关文章请访问：目录：SpringBoot学习目录，感谢阅读！

4461954-86f6a13000597ffb.png
微信扫码关注 - 专注分享
加入知识星球，恒宇少年带你走以后的技术道路！！！
4461954-a56b71bb85d168f9.JPG
微信扫码加入
恒宇少年
关注
5.Quartz应用场景之配置化定时任务（多节点）
Martian158的博客
02-29 1235
要解决的问题 接上文,多节点情况下，加载jobDetail和Trigger会偶发性出现并发错误1 解决思路 加锁控制只有一个节点加载定时任务 额外库表 CREATE TABLE `my_job_load_ctrl` ( `ID` int unsigned NOT NULL, `SERVER_KEY` varchar(200) DEFAULT NULL, `IS_LOCKED` varc...
Spring结合Quartz实现多任务定时调用
cfhgcvb的博客
11-09 155
Spring结合Quartz实现多任务定时调用
基于SpringBoot & Quartz完成定时任务分布式多节点负载持久化
qq_37547408的博客
02-27 1205
参考文章： https://www.jianshu.com/p/d52d62fb2ac6 https://www.jianshu.com/p/49133c107143 https://www.jianshu.com/p/056281e057b3 可以使用的框架 tbschedule、elastic job、redisson 分布式锁、xxl-job。...
基于Springboot分布式quartz定时任务介绍
weixin_42308167的博客
06-10 1494
当使用分布式进行部署程序的时候，就会出现所有的服务器都在跑同一个定时任务，一个定时任务被执行多次的情况。分布式定时任务就是要避免这种情况，通过分布式定时任务重构，达到的效果就是，起多个工程，同一个定时任务某一时刻只会在一个工程上执行，就比如A定时任务，每天三点运行，如果有两个节点A、B，每天三点，只有一个节点会运行A定时任务。......
定时任务之Springboot整合Quartz详解
qq_45087487的博客
08-02 8202
Springboot整合Quartz详解
SpringBoot集成Quartz分布式定时任务
11-01
要实现分布式，Quartz需要配置为使用可持久化的Job存储，如数据库，这样多台服务器上的Quartz实例可以共享任务信息。此外，还需要配置集群策略，如`org.quartz.impl.jdbcjobstore.ClusterManager`，确保任务不被多...
基于spring+quartz的分布式定时任务框架实现
08-31
【基于spring+quartz的分布式定时任务框架实现】 在企业级应用中，定时任务是必不可少的，用于执行一些定期的任务，如数据同步、报表生成、邮件发送等。Spring框架提供了强大的定时任务支持，但要实现分布式环境下...
使用Spring Boot + Quartz 实现分布式定时任务平台
HongYu012的博客
03-23 4342
本文将从项目实战出发来介绍分布式定时任务的实现。在某些应用场景下要求任务必须具备高可用性和可扩展性，单台服务器不能满足业务需求，这时就需要使用Quartz实现分布式定时任务。 一、分布式任务应用场景 定时任务系统在应用平台中的重要性不言而喻，特别是互联网电商、金融等行业更是离不开定时任务。在任务数量不多、执行频率不高时，单台服务器完全能够满足。 但是随着业务逐渐增加，定时任务系统必须具备高可用和水平扩展的能力，单台服务器已经不能满足需求。因此需要把定时任务系统部署到集群中，实现分布式定时任务系统集群。
分布式quartz定时任务学习
最新发布
06-05
分布式Quartz定时任务学习是现代企业级应用中一个重要的技术领域，尤其是在大数据处理、系统维护、数据同步等场景下，其重要性不言而喻。Quartz是一个开源的作业调度框架，它允许开发者定义和执行复杂的任务调度策略...
Quartz架构篇 - 分布式任务调度Quartz
The Secret
01-15 2602
本文介绍分布式任务调度 Quartz
记录一个多节点下quartz定时任务的一个重复执行的bug
放码过来
07-21 1960
业务初期只有一台服务器运行时并未发现异常。直到业务扩展，使用到多个服务时，quartz在默认配置的情况下出现了，多台服务同时执行同一个任务的情况。有时候发生，有时候又是正常的。理论上应该是支持分布式集群的情况下定时任务执行的。...
Quartz集群调度出现的WARN警告问题
yarcl的程序之家
08-04 1万+
1、报错内容如下： This scheduler instance xxxx is still active but was recovered by another instance in the cluster. This may cause inconsistent behavior. ClusterManager detected 1 failed or restarted instances. 这个问题主要是由于系统服务器时间不同步导致的，同步集群当中服务的时间即可解决该问题。 ...
Quartz分布式集群遇到的问题
热门推荐
nightrainljh的专栏
05-14 1万+
Quartz分布式集群遇到的问题背景描述遇到的问题 背景描述 最近给部门进行基础服务建设选型，在分布式调度任务这块考虑了3个热门框架 XXL-JOB 倒是挺满足，可惜开源协议GPL3，不符合公司要求 Elastic-job lite 使用的注册中心zookeeper， 但是对于我们这种公司面向TOB业务，非互联网企业，基本高可用都采用主备，zookeeper高可用必须三台机器（过半选举机制）,研究了半天源码，官方也把redis列入了注册中心，但是一直未有实现，看了下源码，发现注册中心替换上作者在解耦上做的不
log4j定义某个类的日志级别
weixin_30568715的博客
06-29 628
log4j定义某个类的日志级别 项目引入了定时任务后，当我把已有的定时任务删除后，控制台一直会打出类似于 [org.springframework.scheduling.quartz.LocalDataSourceJobStore]ClusterManager: detected 1 failed or restarted instan...
springboot 2.0.7支持quartz多节点分布式任务调度
xiaogg3678的专栏
04-07 1016
springboot 2.0.7支持quartz2.0.7多节点分布式任务调度,多个节点不重复执行，单个节点故障自动转移任务到其他节点
Quartz recovery 及misfired机制的源码分析
冷风
05-26 8679
quartz作为成熟的任务调度系统对系统的异常及崩溃后处理机制有很好的设计，以保证整个调度过程是一个逻辑闭环，任何阶段出现的问题都可以通过框架中的机制尽最大限度的弥补，并将系统的状态引向正轨。 首先要明确的是：quartz如果在执行具体任务时，在任务执行过程中抛出异常，那么不作任何处理，这是使用者程序本身的问题，不需要框架处理。 下面介绍quartz中的两大类异常情况：
【开发经验】quartz框架集群执行原理——故障转移机制（源码解析）
叁滴水 的博客
01-06 2445
上一篇说了一大堆的源码，总结的也是乱七八糟，开始最不解的就是qrtz_fired_triggers为何要存在，直接通过悲观锁锁住qrtz_triggers表不行吗？作者这样做肯定有其道理，通过fired表更好的实现了故障转义，此重点阐述下quartz的故障转义机制。请大家参考。
Quartz通过配置来优化并发能力
菜菜程序员
07-17 5962
先上官网地址：http://www.quartz-scheduler.org/documentation/quartz-2.1.x/configuration/ Quartz 在线上出现并发瓶颈问题，造成延时触发或者不触发，可以通过他的配置文件 quartz.properties 文件来优化 Quartz-Job的quartz.properties配置文件说明，此文件在quartz的jar包有...
使用HutoolUtil之全局定时任务CronUtil工具类实现动态定时任务，很好很强大！
小米吃辣椒的博客
12-11 5740
全局定时任务-CronUtil 介绍 CronUtil通过一个全局的定时任务配置文件，实现统一的定时任务调度。 使用 1、配置文件 对于Maven项目，首先在src/main/resources/config下放入cron.setting文件（默认是这个路径的这个文件），然后在文件中放入定时规则，规则如下： # 我是注释 [com.company.aaa.job] TestJob.run = */10 * * * * TestJob2.run = */10 * * * *Copy to .
ClusterManager: Scanning for instance "sx-aefc-app31688627458267"'s failed in-progress jobs.是什么原因
07-11
"ClusterManager: Scanning for instance 'sx-aefc-app31688627458267' failed in-progress jobs" 这个错误信息通常是指集群管理器在扫描实例 'sx-aefc-app31688627458267' 的失败任务时遇到了问题。这可能是由于多种原因引起的，以下是一些可能的原因： 1. 实例不可用：可能是因为该实例已经停止、故障或被移除。在这种情况下，集群管理器无法访问该实例的任务信息，导致出现错误。 2. 网络问题：如果实例与集群管理器之间存在网络连接问题，集群管理器可能无法成功扫描该实例的任务信息。这可能是由于网络故障、防火墙配置等原因引起的。 3. 权限问题：集群管理器可能没有足够的权限来访问该实例的任务信息。这可能是由于配置错误、访问控制策略等原因引起的。 4. 配置错误：集群管理器的配置可能存在问题，导致无法正确扫描该实例的任务信息。这可能是由于配置文件错误、参数设置错误等原因引起的。 要解决此问题，您可以尝试以下步骤： 1. 检查实例状态：确保该实例处于运行状态，并且可以正常访问。 2. 检查网络连接：确保实例和集群管理器之间的网络连接正常，没有阻止通信的问题。 3. 检查权限设置：确保集群管理器具有足够的权限来访问该实例的任务信息。 4. 检查配置文件：确保集群管理器的配置文件正确，并且参数设置正确。如果有必要，可以尝试重新配置集群管理器。 如果上述步骤都没有解决问题，您可能需要进一步分析错误日志或联系系统管理员或开发人员以获取更多帮助。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值