定时任务详解

定时任务详解

在定时任务中，操作系统或应用程序会利用计时器或定时器来定期检查当前时间是否达到了预定的执行时间，如果当前时间已经达到了预定的时间，系统会自动执行相应的任务。在操作系统中，常见的定时任务管理工具有crontab（Linux系统）、Windows Task Scheduler（Windows系统）等。

1. 定时任务的概念
   定时任务是计算机程序中常用的一种任务调度方式。它允许程序在指定的时间间隔或特定时间点自动执行某些操作或任务。定时任务广泛应用于各种领域，如系统管理、数据处理、日志记录等。
2. 定时任务的原理
   定时任务的原理主要包括以下几个方面：
   定时触发器：定时任务的实现依赖于定时触发器。定时触发器可以根据设定的时间规则，在特定的时间点或间隔触发执行任务。常见的定时触发器有系统级定时器、Cron表达式等。
   任务调度器：任务调度器负责管理和调度定时任务。它可以根据任务的触发规则，决定任务的执行时间，将任务安排到适当的时间点执行。任务调度器通常会维护一个任务队列，按照设定的优先级、时间规则等对任务进行排队和调度。
   任务执行器：任务执行器负责执行定时任务的具体操作。根据任务类型的不同，任务执行器可以是一个单线程或多线程的执行器。它会从任务队列中取出待执行的任务，并按照设定的规则执行相应的操作，如发送邮件、生成报表等。
   错误处理机制：定时任务的错误处理机制可以保证任务的可靠性和容错性。当任务执行器在执行任务过程中出现错误或异常时，错误处理机制可以进行相应的处理，如重新执行任务、记录日志、发送警报等。
3. 定时任务的实现方式
   定时任务的实现方式有多种，包括但不限于以下几种：

JDK自带

Timer：java.util.Timer类允许你调度一个java.util.TimerTask任务。但这种方式一般用的较少，因为它不能让程序在指定时间运行。
ScheduledExecutorService：基于线程池设计的定时任务类，任务是并发执行，互不影响。
Spring Task：Spring3.0以后自带的task，通过@Scheduled注解可以实现定时任务控制。

第三方任务调度框架

Quartz Scheduler：功能强大且灵活的任务调度库，支持基于cron表达式的任务调度、集群支持、作业持久化等。
xxl-job：分布式任务调度平台，提供可视化的任务管理界面和多种任务调度方式。
Elastic Job：分布式任务调度框架，实现分布式任务调度和作业执行。
PowerJob：由阿里巴巴集团开发并开源的分布式任务调度框架，支持多种任务类型。
定时任务的应用场景

定时任务广泛应用于各个领域，以下是一些常见的应用场景：
数据备份：定时自动备份数据库或文件，以防数据丢失。
日志记录：定时记录程序运行日志，以便后续排查问题。
定时任务调度：定时调度其他任务，如定时发送邮件、生成报表等。
数据处理：定时处理数据，如定时清理过期数据、统计数据等。
注意事项
确保定时任务的触发时间和执行时间准确可靠。
合理设置任务调度器的优先级和调度规则，以确保任务能够按照预期的顺序和时间执行。
对于重要的定时任务，建议设置错误处理机制，以便在任务执行过程中出现问题时能够及时处理。
定期检查和监控定时任务的执行情况，以确保任务能够正常运行并达到预期的效果。

java有哪些定时任务的框架

单机
timer：是一个定时器类，通过该类可以为指定的定时任务进行配置。
这是java自带的java.util.Timer类，这个类允许你调度一个
TimerTask类是一个定时任务类，该类实现了Runnable接口，缺点异常未检查会中止线程
java.util.TimerTask任务。使用这种方式可以让你的程序按照某一个频度执行，但不能在指定时间运行。一般用的较少。
ScheduledExecutorService：也jdk自带的一个类；是基于线程池设计的定时任务类,每个调度任务都会分配到线程池中的一个线程去执行,也就是说,任务是并发执行,互不影响。
相对延迟或者周期作为定时任务调度，缺点没有绝对的日期或者时间

分布式
xljob 与 elastic-job
Xxljob 自己内部注册注册中心，
而 elastic-job 是基于 zk 实现注册中心 ，整体思想是差不多的
分布式任务调度平台(xxl-job、elastic job、阿里巴巴 Scheduler)
Quartz：Java事实上的定时任务标准。但Quartz关注点在于定时任务而非数据，并无一套根据数据处理而定制化的流程。虽然Quartz可以基于数据库实现作业的高可用，但缺少分布式并行调度的功能
TBSchedule：阿里早期开源的分布式任务调度系统。代码略陈旧，使用timer而非线程池执行任务调度。众所周知，timer在处理异常状况时是有缺陷的。而且TBSchedule作业类型较为单一，只能是获取/处理数据一种模式。还有就是文档缺失比较严重
elastic-job：当当开发的弹性分布式任务调度系统，功能丰富强大，采用zookeeper实现分布式协调，实现任务高可用以及分片，目前是版本2.15，并且可以支持云开发
Saturn：是唯品会自主研发的分布式的定时任务的调度平台，基于当当的elastic-job 版本1开发，并且可以很好的部署到docker容器上。
xxl-job: 是大众点评员工徐雪里于2015年发布的分布式任务调度平台，是一个轻量级分布式任务调度框架，其核心设计目标是开发迅速、学习简单、轻量级、易扩展。

为什么需要定时任务

很多业务场景需要我们某一特定的时刻去做某件任务，定时任务解决的就是这种业务场景。一般来说，系统可以使用消息传递代替部分定时任务，两者有很多相似之处，可以相互替换场景。如，上面发货成功发短信通知客户的业务场景，我们可以在发货成功后发送MQ消息到队列，然后去消费mq消息，发送短信。
但在某些场景下不能互换：
a)时间驱动/事件驱动：内部系统一般可以通过时间来驱动，但涉及到外部系统，则只能使用时间驱动。如怕取外部网站价格，每小时爬一次
b)批量处理/逐条处理：批量处理堆积的数据更加高效，在不需要实时性的情况下比消息中间件更有优势。而且有的业务逻辑只能批量处理。如移动每个月结算我们的话费
c)实时性/非实时性：消息中间件能够做到实时处理数据，但是有些情况下并不需要实时，比如：vip升级
d)系统内部/系统解耦：定时任务调度一般是在系统内部，而消息中间件可用于两个系统间

定时任务扫表的方案有什么缺点

定时任务扫表是一种常见的定时任务调度方案，但它也存在一些缺点，包括：

1. 实时性差：定时任务扫表是基于轮询的方式，需要定期轮询数据库或其他数据源来获取需要执行的任务。这种方式无法做到实时性，可能存在一定的延迟。
2. 资源消耗较大：如果任务的执行频率较高，比如每秒钟都有大量任务需要执行，那么频繁的数据库查询或轮询会消耗大量的系统资源，包括CPU和内存等。
3. 扩展性差：当任务数量增多或者任务执行时间变长时，定时任务扫表可能面临性能瓶颈。随着任务的增加，数据库查询或轮询的开销也会增加，可能导致系统的响应时间变慢。
4. 数据库依赖：定时任务扫表通常需要依赖数据库或其他外部存储来存储任务信息，这增加了系统的复杂性和对数据库的依赖性。数据库故障或性能问题可能会影响到任务的执行。
5. 时间同步问题：定时任务的执行时间依赖于系统时间。如果系统时间出现偏差或不同步，可能导致任务执行的不准确或混乱。
6. 分布式环境下的同步问题：在分布式环境中，多个节点同时进行任务扫表可能会导致重复执行或者执行冲突的问题。需要额外的同步机制来保证任务的一致性。
7. 任务冲突：如果多个定时任务在处理相同的数据或资源时发生冲突，可能会导致数据不一致或其他问题。
8. 错误处理：如果定时任务在执行过程中出现错误，可能需要人工介入进行错误处理。这可能增加管理员的工作负担。
9. 难以调试和优化：对于复杂的定时任务，调试和优化可能比较困难。
   综上所述，定时任务扫表虽然简单易用，但在实时性、资源消耗、扩展性和分布式环境下的同步等方面存在一些缺点。在一些对实时性要求较高、任务量大或分布式环境下的场景中，可能需要考虑其他更为高效和可靠的任务调度方案。
   为了克服这些缺点，可以考虑以下策略：
10. 优化任务：尽量减少任务的复杂性，避免不必要的资源消耗。
11. 精确时间控制：使用精确的时间同步机制来确保任务按计划执行。
12. 冲突管理：设计机制来避免或处理任务冲突，例如使用锁或队列来确保任务的顺序执行。
13. 错误处理和日志记录：为任务添加错误处理机制，并记录详细的日志以便于问题追踪和解决。
14. 使用专门的调度工具：考虑使用专门的调度工具或框架来简化定时任务的管理和配置。
15. 监控和警报：建立监控机制来检测任务的性能和状态，并在出现问题时及时发出警报。

使用定时任务关闭超期未支付订单，会存在的弊端：

1. 会有时间差，程序不严谨
   10:39下单，11:00检查不足1小时，12:00检查，超过1小时多余39分钟
2. 不支持集群
   单机没毛病，使用集群后，就会有多个定时任务
   解决方案：只使用一台计算机节点，单独用来运行所有的定时任务
3. 会对数据库全表搜索，及其影响数据库性能：select * from order where orderStatus = 10;
   定时任务，仅仅只适用于小型轻量级项目，传统项目
   到消息队列：MQ-> RabbitMQ, RocketMQ, Kafka, ZeroMQ…
   延时任务（队列）
   10:12分下单的，未付款（10）状态，11:12分检查，如果当前状态还是10，则直接关闭订单即可

Quartz

Quartz是一个任务调度框架,在项目中主要是用来做为定时处理,如商品限时抢购等.
Quartz作为一个优秀的开源调度框架，
Quartz 具有以下特点：
强大的调度功能，
支持立即调度、定时调度、周期调度、并发调度； 灵活的应用方式，
支持job间通过listener实现依赖调度，可以方便的进行调度组合
用Quartz做定时任务调度
需求是这样的，以整点时间戳为文件名，每隔一小时创建一个文件，在这一小时内不断的写文件，达到下一小时关闭当前文件句柄和流，并以当前整点小时创建新文件!
写一个单例服务类，服务类两个成员变量，一个是文件句柄，一个是流，可get可set。把它作为spring的一个bean，在quartz和你的读写线程都注入这个bean。quartz里面用set来改句柄(百度上有很好的解释)和流，读写线程用get来读

如何监控Quartz的job执行状态：运行中，暂停中，等待中
目前我能想到的解决办法是通过往表（新建一个操作日志表）里插入日志的形式：
运行中：通过JobListener监听器来实现运行时更改表信息
暂停中：调用scheduler.pauseTrigger()方法时，更改表中job信息
等待中：新添加的job默认给其等待中的状态，也是更改表中的job信息
但是上面这种形式的麻烦之处是得频繁的往表里

xxl-job

概述

具体使用方法可以参考 XXL-Job 官方文档：https://www.xuxueli.com/xxl-job/
XXL-JOB 是一个功能强大且易于使用的分布式任务调度平台，通过其高可用性设计、灵活的调度策略和丰富的功能特性，可以满足各种复杂任务调度需求。在实际使用中，通过合理配置和使用其提供的API，可以实现高效稳定的任务调度和管理。
XXL-JOB是一个轻量级分布式任务调度框架，其核心设计目标是开发迅速、学习简单、轻量级、易扩展。现已开放源代码并接入多家公司线上产品线，开箱即用。
在平时的业务场景中，经常有一些场景需要使用定时任务，比如：
时间驱动的场景：某个时间点发送优惠券，发送短信等等。批量处理数据：批量统计上个月的账单，统计上个月销售数据等等。固定频率的场景：每隔5分钟需要执行一次。所以定时任务在平时开发中并不少见，而且对于现在快速消费的时代，每天都需要发送各种推送，消息都需要依赖定时任务去完成，应用非常广泛。
XXL-JOB 是一个开源的分布式任务调度平台，广泛应用于各种定时任务的调度和管理。它提供了一套完整的分布式任务调度解决方案，适用于Java生态系统。以下是 XXL-JOB 的详细介绍，包括其架构、核心功能、实现原理和使用方法。
架构设计
XXL-JOB 的架构主要包括以下几个组件：
调度中心（Scheduler）：
调度中心是 XXL-JOB 的核心组件，负责任务的调度和管理。
可以部署为集群模式，通过分布式锁或Leader选举机制保证高可用性。
负责任务的创建、更新、删除、调度以及调度日志的管理。
执行器（Executor）：
执行器是任务的实际执行单元，通常是部署在业务服务中的独立进程。
通过注册到调度中心，接收调度中心分配的任务并执行。
支持多种执行方式，如同步执行、异步执行、广播执行等。
调度API：
提供了丰富的API接口，用于任务的调度和管理。
可以通过API实现任务的动态创建、修改、删除和触发。

核心功能
XXL-JOB 提供了一系列强大的功能，满足不同场景下的任务调度需求：
简单易用的Web界面：
提供直观的Web管理界面，方便用户进行任务管理和监控。
支持任务的创建、修改、删除、启动、停止等操作。
分布式调度
支持多种调度策略，如单机调度、分布式调度、广播调度等。
调度中心和执行器均支持集群部署，保证高可用性。
任务日志管理：
详细记录任务的调度日志和执行日志，便于问题排查和性能监控。
提供日志查询和分析功能，方便用户查看任务的执行情况。
执行策略
支持任务的失败重试、超时处理、任务依赖等复杂调度需求。
提供灵活的任务执行策略，如单次执行、周期执行、CRON表达式等。
多语言支持
虽然 XXL-JOB 是基于 Java 实现的，但通过 REST API，可以支持多种语言的任务执行。
通知和报警
支持任务执行结果的通知和报警功能，如任务失败通知、任务超时报警等。
可以通过邮件、短信、钉钉等方式进行通知。

实现原理

1. 任务调度原理：
   调度中心定期扫描数据库中的任务，根据任务的调度策略生成调度事件。
   调度事件通过 HTTP 请求发送给相应的执行器。
2. 任务执行原理：
   执行器接收到调度请求后，按照任务定义的执行逻辑执行任务。
   执行结果通过 HTTP 请求反馈给调度中心，更新任务状态和执行日志。
3. 分布式锁和高可用性：
   调度中心集群通过 Zookeeper 或者其他分布式锁机制进行 Leader 选举，保证在任何时刻只有一个调度节点负责任务调度。
   执行器通过心跳机制定期向调度中心报告状态，调度中心根据执行器的状态分配任务，保证任务的高可用性。

使用方法
环境准备：
搭建 MySQL 数据库，用于存储任务和调度日志。
部署 XXL-JOB 调度中心，可以通过下载官方发布的 WAR 包部署到 Tomcat 服务器。
引入依赖：
在业务项目中引入 XXL-JOB 的依赖。

<dependency><groupId>com.xuxueli</groupId><artifactId>xxl-job-core</artifactId><version>2.3.0</version>
</dependency>

配置执行器： 在 Spring Boot 项目中，配置 XXL-JOB 执行器。

@Configuration
public class XxlJobConfig {@Value("${xxl.job.admin.addresses}")private String adminAddresses;@Value("${xxl.job.executor.appname}")private String appName;@Value("${xxl.job.executor.ip}")private String ip;@Value("${xxl.job.executor.port}")private int port;@Value("${xxl.job.accessToken}")private String accessToken;@Value("${xxl.job.executor.logpath}")private String logPath;@Value("${xxl.job.executor.logretentiondays}")private int logRetentionDays;@Beanpublic XxlJobSpringExecutor xxlJobExecutor() {XxlJobSpringExecutor xxlJobSpringExecutor = new XxlJobSpringExecutor();xxlJobSpringExecutor.setAdminAddresses(adminAddresses);xxlJobSpringExecutor.setAppName(appName);xxlJobSpringExecutor.setIp(ip);xxlJobSpringExecutor.setPort(port);xxlJobSpringExecutor.setAccessToken(accessToken);xxlJobSpringExecutor.setLogPath(logPath);xxlJobSpringExecutor.setLogRetentionDays(logRetentionDays);return xxlJobSpringExecutor;}
}
4.  定义任务： 使用 @XxlJob  注解定义任务。 
@Service
public class SampleJob {@XxlJob("sampleJobHandler")public ReturnT<String> execute(String param) throws Exception {System.out.println("XXL-JOB, Hello World.");return ReturnT.SUCCESS;}
}

5. 在调度中心配置任务：
   通过 XXL-JOB Web 管理界面配置任务的调度策略、执行器信息等。

xxl-job详解

https://github.com/xuxueli/xxl-job/
相对来说，xxl-job中心式的调度平台轻量级，开箱即用，操作简易，上手快，与SpringBoot有非常好的集成，而且监控界面就集成在调度中心，界面又简洁，对于企业维护起来成本不高，还有失败的邮件告警等等。这就使很多企业选择xxl-job做调度平台。
实际上更多公司选择xxl-job，目前xxl-job的github上有15.7k个star，登记公司有348个。毫无疑问elasticjob和xxl-job都是非常优秀的技术框架，接下来我们进一步对比讨论，探索一下为什么更多公司会选择xxl-job。
首先先介绍一下xxl-job，这是出自大众点评许雪里(xxl就是作者名字的拼音首字母)的开源项目，官网上介绍这是一个轻量级分布式任务调度框架，其核心设计目标是开发迅速、学习简单、轻量级、易扩展。跟elasticjob不同，xxl-job环境依赖于mysql，不用ZooKeeper，这也是最大的不同。
elasticjob的初衷是为了面对高并发复杂的业务，即使是在业务量大，服务器多的时候也能做好任务调度，尽可能的利用服务器的资源。使用ZooKeeper使其具有高可用、一致性的，而且还具有良好的扩展性。官网上写
elasticjob是无中心化的，通过ZooKeeper的选举机制选举出主服务器，如果主服务器挂了，会重新选举新的主服务器。因此elasticjob具有良好的扩展性和可用性，但是使用和运维有一定的复杂
xl-job则相反，是通过一个中心式的调度平台，调度多个执行器执行任务，调度中心通过DB锁保证集群分布式调度的一致性，这样扩展执行器会增大DB的压力，但是如果实际上这里数据库只是负责任务的调度执行。但是如果没有大量的执行器的话和任务的情况，是不会造成数据库压力的。实际上大部分公司任务数，执行器并不多(虽然面试经常会问一些高并发的问题)。
分别有调度中心和执行器两大组成部分

调度中心。负责管理调度信息，按照调度配置发出调度请求，自身不承担业务代码。支持可视化界面，可以在调度中心对任务进行新增，更新，删除，会实时生效。支持监控调度结果，查看执行日志，查看调度任务统计报表，任务失败告警等等。执行器。负责接收调度请求，执行调度任务的业务逻辑。执行器启动后需要注册到调度中心。接收调度中心的发出的执行请求，终止请求，日志请求等等。接下来我们看一下xxl-job的工作原理。
任务执行器根据配置的调度中心的地址，自动注册到调度中心。达到任务触发条件，调度中心下发任务。执行器基于线程池执行任务，并把执行结果放入内存队列中、把执行日志写入日志文件中。执行器的回调线程消费内存队列中的执行结果，主动上报给调度中心。当用户在调度中心查看任务日志，调度中心请求任务执行器，任务执行器读取任务日志文件并返回日志详情

为什么需要任务调度平台
在Java中，传统的定时任务实现方案，比如Timer，Quartz等都或多或少存在一些问题：
不支持集群、不支持统计、没有管理平台、没有失败报警、没有监控等等而且在现在分布式的架构中，有一些场景需要分布式任务调度：同一个服务多个实例的任务存在互斥时，需要统一的调度。任务调度需要支持高可用、监控、故障告警。需要统一管理和追踪各个服务节点任务调度的结果，需要记录保存任务属性信息等。显然传统的定时任务已经不满足现在的分布式架构，所以需要一个分布式任务调度平台，目前比较主流的是elasticjob和xxl-job。
elasticjob由当当网开源，目前github有6.5k的Star，使用的公司在官网登记有76家。
跟xxl-job不同的是，elasticjob是采用zookeeper实现分布式协调，实现任务高可用以及分片。

XXL-Job分片
XXL-Job 是一个分布式任务调度平台，它提供了任务调度和任务管理的功能。在 XXL-Job 中，分片是指将一个大任务拆分成多个小任务进行执行的机制。下面是对 XXL-Job 中分片的理解：

1. 任务分片：XXL-Job 将一个大的任务分解成多个小任务，每个小任务称为一个任务分片。每个任务分片可以独立执行，相互之间不会产生影响。
2. 分片数量：任务分片的数量由用户指定，可以根据实际需求进行调整。通常情况下，分片数量取决于任务的处理逻辑和数据量大小。
3. 分片策略：XXL-Job 提供了多种分片策略，用户可以根据实际情况选择合适的策略。常见的分片策略包括固定分片和动态分片两种：
   ○ 固定分片：将任务分成固定数量的分片，每个分片的数据量相等。
   ○ 动态分片：根据数据量大小或者其他条件动态地确定分片数量，使得每个分片的数据量尽可能均匀。
4. 分片执行：XXL-Job 会将任务分片分发给执行器节点执行。每个执行器节点负责执行其中的一个或多个分片，执行结果会汇总到调度中心进行统计和监控。
5. 分片参数传递：对于每个任务分片，XXL-Job 允许用户传递参数，以便在执行任务时使用。这些参数可以包括任务的起始位置、结束位置、分片序号等信息。
6. 分片失败处理：如果某个任务分片执行失败，XXL-Job 允许用户设置失败处理策略。常见的失败处理策略包括重试、忽略、记录异常信息等。
7. 监控和报警：XXL-Job 提供了丰富的监控和报警功能，用户可以实时监控任务的执行情况和任务分片的运行状态，及时发现和处理异常情况。
   总的来说，XXL-Job 的分片机制能够有效地提高任务的并发执行能力和处理效率，同时也能够保证任务的可靠性和稳定性。通过合理地设置分片参数和选择适当的分片策略，可以充分发挥任务调度平台的性能和效果。

elastic-job

Elastic-Job 是由当当网开源的一款分布式调度解决方案，主要用于大数据环境下的作业调度。它支持多种类型的作业调度和任务执行策略，具有高可用性和扩展性，适合处理大规模、高并发的任务调度需求。以下是对 Elastic-Job 的详细介绍，包括其架构、核心功能、实现原理和使用方法。
Elastic-Job 是一个功能强大且灵活的分布式任务调度框架，通过其高可用性设计、分片机制和丰富的作业治理功能，可以满足各种复杂任务调度需求。在实际使用中，通过合理配置和使用其提供的API，可以实现高效稳定的任务调度和管理。

架构设计
Elastic-Job 的架构主要包括以下几个组件：
调度中心（Coordinator）：
负责任务的调度和管理，通常基于 Zookeeper 进行节点管理和任务分配。
维护作业的元数据、分片信息和执行状态，保证任务的统一调度和高可用性。
执行器（Executor）：
执行器是实际执行任务的节点，注册到调度中心并从调度中心获取任务。
可以水平扩展，通过增加执行器节点来提升任务处理能力。
Zookeeper：
用于协调和管理调度中心和执行器之间的交互，提供分布式锁和节点状态管理功能。

核心功能
Elastic-Job 提供了多种功能，满足不同场景下的任务调度需求：
分片机制：
支持将一个任务拆分为多个子任务，通过分片机制实现任务的并行处理。
每个执行器只处理一部分分片，提升任务执行效率。
弹性扩展
通过增加或减少执行器节点，实现任务调度的弹性扩展。
执行器节点的增加或减少不会影响任务调度的稳定性。
高可用性
通过 Zookeeper 实现调度中心的高可用性，防止单点故障。
支持任务的失败重试和故障转移，保证任务的可靠执行。
多种作业类型：
支持简单作业、数据流作业和脚本作业，适用于不同类型的任务调度需求。
简单作业：一次性执行的任务。
数据流作业：需要处理大量数据的任务。
脚本作业：通过执行脚本完成的任务。
作业治理：
提供丰富的作业治理功能，如作业状态监控、执行日志管理和作业分片策略调整。
任务依赖：
支持任务依赖管理，通过配置任务依赖关系，实现复杂任务流的调度。

实现原理
任务分片和调度：
调度中心将任务拆分为多个分片，并将分片分配给不同的执行器。
执行器注册到调度中心并定期上报状态，调度中心根据执行器的状态分配任务。
高可用性和故障转移：
通过 Zookeeper 实现调度中心的高可用性，调度中心的每个节点都可以作为主节点。
如果主节点出现故障，其他节点会自动接管，保证任务调度的连续性。
作业治理和监控：
调度中心和执行器会记录详细的作业执行日志和状态，提供丰富的监控和管理功能。
支持对作业的手动操作，如暂停、恢复、立即触发等。

使用方法
环境准备：
搭建 Zookeeper 集群，用于节点注册和状态管理。
部署调度中心和执行器，可以通过 Maven 引入 Elastic-Job 依赖。
引入依赖：
在 Spring Boot 项目中引入 Elastic-Job 的依赖。

org.apache.shardingsphere.elasticjob
elasticjob-lite-core
3.0.0

3. 配置调度中心：
○ 在 Spring Boot 项目中配置 Elastic-Job。

elasticjob:regCenter:serverLists: localhost:2181namespace: elasticjob-demojob:simple:name: mySimpleJobcron: 0/5 * * * * ?shardingTotalCount: 3shardingItemParameters: 0=A,1=B,2=C
4.  定义作业： ○ 使用 @ElasticJob  注解定义作业。 
@ElasticJobHandler(name = "mySimpleJob")
public class MySimpleJob implements SimpleJob {@Overridepublic void execute(ShardingContext shardingContext) {System.out.println(String.format("Item: %s | Time: %s | Thread: %s | %s",shardingContext.getShardingItem(), LocalDateTime.now(),Thread.currentThread().getId(), shardingContext.getJobParameter()));}
}

启动作业：
在 Spring Boot 应用启动时，Elastic-Job 会自动启动并注册作业到调度中心。
与其他框架的比较
与XXL-JOB相比，Elastic-Job采用无中心化解决方案，而XXL-JOB则采用中心集权方式。
Elastic-Job更注重于分布式环境下的任务调度和协调，而XXL-JOB则更注重于任务的灵活性和易扩展性。
官方文档与资源
官方文档：提供了Elastic-Job的详细使用教程、API文档和最佳实践案例。
官方网站：https://shardingsphere.apache.org/elasticjob/
源码地址：https://gitee.com/ityml/elastic-job-zgc