定时任务方案实现与对比

定时任务

   定时任务通常用来处理,在某个特定的时间去做某个事情, 并由对应的重试策略来应对部分异常场景。

   定时任务分为分布式定时任务和单机定时任务两个大的方向,他们的适用场景不同。

任务类型特点优点缺点
单机定时任务在单台计算机上运行,其执行结果和单台机器上的数据有关,如对本地机器的缓存做核对、清理日志等。1. 简单易用,无需依赖外部组件;任务一般没有持久化机制,重启后有任务丢失的问题。
分布式定时任务将任务交由集群中的某个机器来执行,常用于需要在分布式环境下协同执行的任务,例如处理耗时较长的任务、数据同步、消息处理、超时关单等场景高可靠性、高可扩展性和分布式特性视具体的组件而定

应用场景

  1. 超时关单场景:每笔订单创建后,10min未推进支付状态,即执行关单操作

    • 生成订单时,提交一个10min后的分布式关单任务,完成关闭内部订单和其他相关通知操作。可对该任务指定不同的执行间隔时间。
    • 使用MQ,将消息投递到延迟消息队列中,指定时间间隔后,再将消息投递给消费者。
  2. 资金回退(FundBack)场景:支付回调接口中,内部订单1已经由钱包B通知支付成功了,但此时收到A钱包通知订单1支付成功,此时需要告知A支付失败且通知A进行 FundBack 操作。

    • 生成 FundBack 任务,指定不同间隔时间来通知A,避免因钱包A发布期间无法收到FundBack信息的问题。
  3. 核对本地缓存数据:分布式多级缓存中,需要扫描缓存和DB中的数据是否一致。

    • 建设本地定时任务,完成每台应用的核对

本地定时任务框架

   单机定时任务有 Timer、ScheduledExecutorService、SpringTask、SpringQuartz 等。Timer、ScheduledExecutorService 都无法使用 Cron 表达式指定任务执行的具体时间,灵活性不够,本文不做展开。

SpringTask

org.springframework.scheduling.annotation.Scheduled提供的属性如下:

/**
	 * A cron-like expression, extending the usual UN*X definition to include triggers
	 * on the second, minute, hour, day of month, month, and day of week.
	 * <p>For example, {@code "0 * * * * MON-FRI"} means once per minute on weekdays
	 * (at the top of the minute - the 0th second).
	 * <p>The fields read from left to right are interpreted as follows.
	 * <ul>
	 * <li>second</li>
	 * <li>minute</li>
	 * <li>hour</li>
	 * <li>day of month</li>
	 * <li>month</li>
	 * <li>day of week</li>
	 * </ul>
	 * <p>The special value {@link #CRON_DISABLED "-"} indicates a disabled cron
	 * trigger, primarily meant for externally specified values resolved by a
	 * <code>${...}</code> placeholder.
	 * @return an expression that can be parsed to a cron schedule
	 * @see org.springframework.scheduling.support.CronSequenceGenerator
	 */
	String cron() default "";

	/**
	 * A time zone for which the cron expression will be resolved. By default, this
	 * attribute is the empty String (i.e. the server's local time zone will be used).
	 * @return a zone id accepted by {@link java.util.TimeZone#getTimeZone(String)},
	 * or an empty String to indicate the server's default time zone
	 * @since 4.0
	 * @see org.springframework.scheduling.support.CronTrigger#CronTrigger(String, java.util.TimeZone)
	 * @see java.util.TimeZone
	 */
	String zone() default "";

	/**
	 * Execute the annotated method with a fixed period in milliseconds between the
	 * end of the last invocation and the start of the next.
	 * @return the delay in milliseconds
	 */
	long fixedDelay() default -1;

	/**
	 * Execute the annotated method with a fixed period in milliseconds between the
	 * end of the last invocation and the start of the next.
	 * @return the delay in milliseconds as a String value, e.g. a placeholder
	 * or a {@link java.time.Duration#parse java.time.Duration} compliant value
	 * @since 3.2.2
	 */
	String fixedDelayString() default "";

	/**
	 * Execute the annotated method with a fixed period in milliseconds between
	 * invocations.
	 * @return the period in milliseconds
	 */
	long fixedRate() default -1;

	/**
	 * Execute the annotated method with a fixed period in milliseconds between
	 * invocations.
	 * @return the period in milliseconds as a String value, e.g. a placeholder
	 * or a {@link java.time.Duration#parse java.time.Duration} compliant value
	 * @since 3.2.2
	 */
	String fixedRateString() default "";

	/**
	 * Number of milliseconds to delay before the first execution of a
	 * {@link #fixedRate} or {@link #fixedDelay} task.
	 * @return the initial delay in milliseconds
	 * @since 3.2
	 */
	long initialDelay() default -1;

	/**
	 * Number of milliseconds to delay before the first execution of a
	 * {@link #fixedRate} or {@link #fixedDelay} task.
	 * @return the initial delay in milliseconds as a String value, e.g. a placeholder
	 * or a {@link java.time.Duration#parse java.time.Duration} compliant value
	 * @since 3.2.2
	 */
	String initialDelayString() default "";

执行原理:

   ScheduledTaskRegistrar#afterPropertiesSet 方法中,默认初始化一个单线程的 ScheduledExecutorService 来执行任务。

   SpringTask 在 ScheduledAnnotationBeanPostProcessor#processScheduled 中解析和收集 Scheduled 注解中的参数;然后向 ScheduledTaskRegistrar 中添加对应类型的任务。

ScheduledExecutorService:

   总结起来就是通过线程池来执行任务;DelayedWorkQueue 作为阻塞队列,并排序任务定时执行;ScheduledFutureTask 记录任务定时信息,。

   ScheduledExecutorService 继承线程池,也是把任务提交给线程池执行,只不过它的任务类进行了扩展。
在这里插入图片描述

   ScheduledExecutorService 自定义了阻塞队列 DelayedWorkQueue 给线程池使用,它可以根据 ScheduledFutureTask 的下次执行时间来阻塞 take 方法,并且新进来的 ScheduledFutureTask 会根据这个时间来进行排序,最小的最前面。

   任务类 ScheduledFutureTask 继承 FutureTask 并扩展了一些属性来记录任务下次执行时间和每次执行间隔。同时重写了run方法重新计算任务下次执行时间,并把任务放到线程池队列中。
在这里插入图片描述

spring task 的优缺点:
优点:

  • spring框架自带的定时功能,开启和定义定时任务非常容易,支持复杂的 cron 表达式,可以满足绝大多数单机版的业务场景。单线程执行任务时,当前次的调度完成后,再执行下一次任务调度。

缺点:

  • 默认单线程,如果前面的任务执行时间太长,对后面任务的执行有影响。
  • 不支持集群方式部署,提交的任务在单机内存中,可能出现任务丢失的情况

SpringQuartz

优点:

  • 默认是多线程异步执行,单个任务时,在上一个调度未完成时,下一个调度时间到时,会另起一个线程开始新的调度,多个任务之间互不影响。
  • 支持复杂的 cron 表达式
  • 它能被集群实例化,支持分布式部署。

缺点:

  • 相对于spring task实现定时任务成本更高,需要手动配置 QuartzJobBean 、 JobDetail和 Trigger 等。需要引入了第三方的 quartz 包,有一定的学习成本。
  • 没有内置 UI 管理控制台。
  • 不支持并行调度,不支持失败处理策略和动态分片的策略等。

代码案例

分布式定时任务框架

XXL-Job

在这里插入图片描述
   将调度行为抽象形成“调度中心”公共平台,而平台自身并不承担业务逻辑,“调度中心”负责发起调度请求。

   将任务抽象成分散的JobHandler,交由“执行器”统一管理,“执行器”负责接收调度请求并执行对应的JobHandler中业务逻辑。

调度中心:

   自研调度组件(早期调度组件基于Quartz);一方面是为了精简系统降低冗余依赖,另一方面是为了提供系统的可控度与稳定性;

执行器:

   执行器实际上是一个内嵌的Server,在项目启动时,执行器会通过 “@JobHandler” 识别Spring容器中“Bean模式任务”,以注解的value属性为key管理起来。

   “执行器”接收到“调度中心”的调度请求时,如果任务类型为“Bean模式”,将会匹配Spring容器中的“Bean模式任务”,然后调用其execute方法,执行任务逻辑。如果任务类型为“GLUE模式”,将会加载GLue代码,实例化Java对象,注入依赖的Spring服务(注意:Glue代码中注入的Spring服务,必须存在与该“执行器”项目的Spring容器中),然后调用execute方法,执行任务逻辑。

任务注册与发现

   任务注册以 “执行器” 为最小粒度进行注册。

   基于 HTTP 协议的 REST接口(未使用ZK),将执行器注册到 调度中心 DB 的注册表中,再通过对应的 Beat 完成任务注册、执行器注册、动态任务发现、注册信息失效等动作。

优缺点:

优点:

  • 有界面管理定时任务,支持弹性扩容缩容、动态分片、故障转移、失败报警等功能。
  • 支持在运行时动态创建任务( XxlJobHelper#submitCronTask),参见:xxl-job issue277

缺点:

  • 一致性:“调度中心”通过DB锁保证集群分布式调度的一致性, 一次任务调度只会触发一次执行。和 quartz 一样,通过数据库分布式锁,来控制任务不能重复执行
  • 调度中心HA(中心式):调度采用中心式设计,“调度中心”自研调度组件并支持集群部署,可保证调度中心HA。不同于 Elastic-Job 的去中心化设计, XXL-JOB 的这种设计也被称为中心化设计

官网-架构


其他资料

JavaGuide-task

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
继保点检系统数据接口设计方案 1. 应用场景 系统在总部及各单位分别部署,版本相同; 各单位之间不能通讯,各单位与总部之前可互相通讯。 2. 接口目的 实现集团内各单位数据共享,A单位可查看集团内任一单位的部分数据(主要是标准 、台账、人员和统计分析,具体业务数据不需要)。 3. 实现方法 (1)数据同步:定时自动同步。各单位的数据加单位标识、时间戳、操作标识(CMD ),首次进行全表同步,之后定期进行增量同步; (2)文件同步:手动同步。总部收到请求后在本地查找或去目标单位下载目标文件 ,再发送给请求单位。 1. 数据同步 发送方式:定时自动同步。 同步方向:各单位数据同步至总部后,由总部统一进行下发操作。如:A、B、C……单 位将数据同步至总部,总部再将B、C……单位的数据下发给A单位,把A、C……单位的数据下 发给B单位。 同步数据列表:所有表(总部与各单位的数据表结构相同) 同步方式:统一数据同步/增量同步。 首次部署进行一次"统一数据同步"操作,厂家将总部所有须同步的数据统一进行下发 ; 每日进行"增量同步",厂家将数据上传至总部,由总部进行统一分发。 使用"增量同步"方式必须增加以下数据表: 同步数据配置表(固定两条数据T/G,用于设置周期): "属性名称 "字段名称 "数据类型 "备注 " "主键 "GUID "VARCHAR2(42) " " "同步任务 "TASK "VARCHAR2(42) " " "同步方式 "SYN_TYPE "CHAR(1) "T表示统一数据同 " " " " "步 " " " " "G表示增量同步 " "同步周期 "PERIOD "INTEGER "单位为天,可以为" " " " "小数 " 同步数据配置表: "属性名称 "字段名称 "数据类型 "备注 " "主键 "GUID "VARCHAR2(42) " " "数据来源单位 "FROM_DEPT "VARCHAR2(42) "数据来源部门编码" "数据分类 "DATA_TYPE "VARCHAR2(20) "SB设备 " " " " "QX缺陷 " " " " "DJ点检 " " " " "JX检修 " "同步表名称 "TB_TBNAME "VARCHAR2(50) " " "全表/增量同步 "ISFULL "CHAR(1) "F表示全表 " " " " "G表示增量 " "最后更新时间 "LAST_DOWNLOAD_TI"DATE "厂家接收总部数据" " "ME " "后更新该字段 " 本地更新数据log表: "属性名称 "字段名称 "数据类型 "备注 " "主键 "GUID "VARCHAR2(42) " " "操作名称 "OPERATE "CHAR(1) "C表示新建 " " " " "D表示删除 " " " " "U表示更新 " "更新表名称 "GX_TBNAME "VARCHAR2(50) " " "数据ID "GX_GUID "VARCHAR2(42) "相应记录的guid " "操作时间 "OPE_TIME "DATE " " 数据同步log表: "属性名称 "字段名称 "数据类型 "备注 " "主键 "GUID "VARCHAR2(42) " " "数据来源单位 "FROM_DEPT "VARCHAR2(42) "数据来源部门编码" "同步表名称 "TB_TBNAME "VARCHAR2(50) " " "全表/增量同步 "ISFULL "CHAR(1) "F表示全表 " " " " "G表示增量 " "更新数据条数 "COUNT_NUM "INTEGER " " "同步开始时间 "UP_TIME "DATE " " "同步结束时间 "UP_TIME "DATE " " 数据同步详细log表: "属性名称 "字段名称 "数据类型 "备注 " "主键 "GUID "VARCHAR2(42) " " "数据ID "GX_GUID "VARCHAR2(42) "相应记录的guid " "操作名称 "OPERATE "CHAR(1) "C表示新建 " " " " "D表示删除 " " " " "U表示更新 " 2. 文件同步 发送方式:手动召唤同步。 同步方向:应用中建立downloadfiles文件夹,按各单位建立子文件夹,用于存放同 步的文件。各单位在本系统中上传的附件名称须保证唯一性。(设备台账那比较多) 某单位或总部请求其他单位的文件时,请求先发送到总部,总部在downloadfiles中 查找目标文件,则将此文件在总部数据库中的记录与目标单位数据库中的记录进行对比 ,如果一致就把目标文件发送给请求单位。如果文件比对日期不一致或是文件不存在, 则去目标单位下载到downloadfiles后发送给请求单位。 ---
城市照明监控调度中心建设方案 一、项目背景与目标 随着城市化进程的加速,城市照明系统作为城市基础设施的重要组成部分,对于提升城市形象、保障市民生活安全具有重要作用。然而,传统的城市照明管理方式存在诸多问题,如效率低下、资源浪费、管理困难等。因此,建设城市照明监控调度中心,实现照明系统的智能化、精细化管理,成为当前城市照明管理的重要任务。 本项目的目标是建设一个高效、智能、可靠的城市照明监控调度中心,实现城市照明系统的集中监控、统一调度、智能控制,提高照明系统的运行效率和管理水平,降低能源消耗,提升城市形象。 二、系统架构与功能设计 2.1 系统架构 城市照明监控调度中心系统架构主要包括数据采集层、数据传输层、数据处理层和应用层。数据采集层负责收集各类照明设备的运行数据;数据传输层负责将采集到的数据传输到数据处理层;数据处理层负责对接收到的数据进行处理和分析,生成相应的控制指令;应用层则负责将控制指令发送到各个照明设备,实现对照明系统的实时监控和调度。 2.2 功能设计 2.2.1 实时监控 实现对城市照明系统的实时监控,包括各类照明设备的运行状态、能耗情况、故障信息等。通过实时监控,可以及时发现和处理问题,确保照明系统的稳定运行。 2.2.2 统一调度 根据城市不同区域的照明需求和实际情况,实现对照明设备的统一调度。包括定时开关、亮度调节、色温调节等功能,以满足不同时间段和不同区域的照明需求。 2.2.3 智能控制 通过智能算法,实现对城市照明系统的智能控制。例如,根据天气情况、交通流量等因素,自动调节照明设备的亮度和色温,以达到节能和提升照明效果的目的。 2.2.4 数据分析与决策支持 通过对收集到的数据进行分析和挖掘,提供决策支持。例如,分析不同区域的照明需求、能耗情况等,为优化照明系统设计和运行策略提供依据。 三、硬件与软件配置 3.1 硬件配置 包括服务器、存储设备、网络设备、监控大屏等。服务器负责数据处理和应用服务;存储设备负责数据存储和备份;网络设备负责数据传输和通信;监控大屏则用于展示实时监控数据和调度信息。 3.2 软件配置 包括操作系统、数据库、监控软件、调度软件等。操作系统负责系统的基本运行和管理;数据库负责数据的存储和查询;监控软件负责实时监控和数据分析;调度软件则负责照明设备的统一调度和智能控制。 四、实施与运维 4.1 实施步骤 需求分析和方案设计 硬件采购和部署 软件开发和安装 系统集成和测试 上线运行和验收 4.2 运维管理 建立专业的运维团队,负责系统的日常运行和维护。包括故障处理、数据备份、系统升级等工作。同时,建立完善的运维管理制度和应急预案,确保系统的稳定运行和安全可靠。 五、预算与投资回报 5.1 预算 详细列出项目所需的各项费用,包括硬件设备、软件开发、实施费用、运维费用等。确保预算的合理性和可行性。 5.2 投资回报 分析项目建成后的预期效益,包括节能降耗、管理效率提升、城市形象提升等方面。通过对比投资成本和预期效益,评估项目的投资回报率。 六、风险评估与应对措施 6.1 风险评估 识别项目建设和运行过程中可能面临的风险因素,如技术风险、管理风险、安全风险等。对这些风险因素进行分析和评估,确定其对项目的影响程度和可能性。 6.2 应对措施 针对识别出的风险因素,制定相应的应对措施。例如,加强技术研发和团队建设以降低技术风险;完善管理制度和应急预案以降低管理风险;加强安全防护和数据备份以降低安全风险等。 以上是城市照明监控调度中心建设方案的初步框架和内容概述。具体方案还需根据实际情况和需求进行细化和完善。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值