定时任务（XXL-Job / Quartz / Elastic-Job）

定时任务概述

什么是定时任务

定时任务（Scheduled Task）是指按照预设的时间规则自动执行特定逻辑的程序机制。在企业级应用中，定时任务广泛用于处理周期性、批量性的后台操作，例如数据同步、日志清理、报表生成、缓存刷新、消息推送等。

应用场景

场景	示例
数据批处理	每日凌晨同步订单数据到数仓
状态检查	每 5 分钟检测超时订单并自动取消
资源清理	每天清理 30 天前的临时文件和日志
报表生成	每周一上午 9 点生成上周业务报表
缓存预热	应用启动后立即加载热点数据到缓存
健康检查	每隔 10 秒探测下游服务可用性

单机定时任务的局限

在单机环境下，使用 java.util.Timer 或 Spring @Scheduled 即可实现简单的定时任务。但在分布式系统中，单机模式面临以下问题：

单点故障：任务执行节点宕机后任务永久丢失
无法分片：大数据量任务只能单机串行执行，无法水平扩展
重复执行：多节点部署时同一任务被多次触发，导致数据不一致
缺乏管理：没有统一的任务管理界面，无法动态启停、调整触发时间

分布式定时任务的核心需求

需求	说明
高可用	调度器或执行器宕机后，任务能被其他节点接管
任务分片	将一个大任务拆分为多个分片，分发到不同节点并行执行
故障转移	某一分片执行失败后自动转移到其他健康节点重试
动态管理	支持在线创建、修改、删除、启停任务，无需重启应用
执行日志	记录每次任务执行的开始时间、结束时间、状态、异常信息
弹性伸缩	执行器节点动态增删时，任务分片自动重新分配

Quartz

概述

Quartz 是一个开源的、功能丰富的 Java 任务调度库，几乎已成为 Java 定时调度的事实标准。它由 Terracotta 公司维护，支持嵌入式和集群两种部署模式。

核心概念

Quartz 的三大核心概念构成其调度模型的基础：

概念	说明
Job	定义要执行的具体业务逻辑
Trigger	定义任务触发的时间规则
Scheduler	管理 Job 和 Trigger 的注册、调度、生命周期

Job / JobDetail

Job 是一个接口，包含一个 execute(JobExecutionContext context) 方法。JobDetail 用于描述 Job 的实例信息，包括名称、组、关联数据等。

java

public class SendEmailJob implements Job {
    @Override
    public void execute(JobExecutionContext context) throws JobExecutionException {
        JobDataMap dataMap = context.getJobDetail().getJobDataMap();
        String email = dataMap.getString("email");
        System.out.println("Sending email to: " + email);
    }
}

java

JobDetail jobDetail = JobBuilder.newJob(SendEmailJob.class)
        .withIdentity("sendEmailJob", "emailGroup")
        .usingJobData("email", "user@example.com")
        .storeDurably()
        .build();

Trigger

Trigger 定义任务何时执行。Quartz 提供两种主要触发器：

SimpleTrigger：适用于固定间隔的执行（如每隔 10 秒执行一次）
CronTrigger：基于 Cron 表达式的复杂时间规则

java

// SimpleTrigger 示例：延迟 5 秒后执行，之后每 10 秒重复一次
Trigger simpleTrigger = TriggerBuilder.newTrigger()
        .withIdentity("simpleTrigger", "group1")
        .startAt(DateBuilder.futureDate(5, DateBuilder.IntervalUnit.SECOND))
        .withSchedule(SimpleScheduleBuilder.simpleSchedule()
                .withIntervalInSeconds(10)
                .repeatForever())
        .build();

// CronTrigger 示例：每天上午 10:15 执行
Trigger cronTrigger = TriggerBuilder.newTrigger()
        .withIdentity("cronTrigger", "group1")
        .withSchedule(CronScheduleBuilder.cronSchedule("0 15 10 ? * *"))
        .build();

Cron 表达式

Cron 表达式由 6~7 个字段组成，各字段以空格分隔：

秒 分 时 日 月 星期 [年]

字段	必须	取值范围	特殊字符
秒	是	0-59	`, - * /`
分	是	0-59	`, - * /`
时	是	0-23	`, - * /`
日	是	1-31	`, - * ? / L W`
月	是	1-12 或 JAN-DEC	`, - * /`
星期	是	1-7 或 SUN-SAT	`, - * ? / L #`
年	否	1970-2099	`, - * /`

常用示例：

表达式	含义
`0 0 12 * * ?`	每天中午 12:00
`0 0/5 * * * ?`	每 5 分钟
`0 0 2 ? * MON-FRI`	工作日凌晨 2:00
`0 0 0 1 * ?`	每月 1 日凌晨
`0 15 10 L * ?`	每月最后一天 10:15
`0 0/30 9-17 * * ?`	每天 9:00-17:00 每半小时

Scheduler

Scheduler 是 Quartz 的总控制器：

java

SchedulerFactory schedulerFactory = new StdSchedulerFactory();
Scheduler scheduler = schedulerFactory.getScheduler();

scheduler.start();
scheduler.scheduleJob(jobDetail, cronTrigger);
// scheduler.shutdown();

集群模式

Quartz 支持基于数据库的集群模式。通过将 Job 和 Trigger 的状态持久化到共享数据库，多个 Quartz 节点可以协同工作，避免任务重复执行。

集群原理

所有节点共享同一个 Quartz 数据库表
节点通过数据库行级锁（SELECT ... FOR UPDATE）竞争任务
获得锁的节点执行任务，执行完成后释放锁
节点宕机后，锁自动超时释放，其他节点接管

配置示例

properties

# quartz.properties
org.quartz.scheduler.instanceName = MyClusteredScheduler
org.quartz.scheduler.instanceId = AUTO

# 使用 JDBC JobStore
org.quartz.jobStore.class = org.quartz.impl.jdbcjobstore.JobStoreTX
org.quartz.jobStore.driverDelegateClass = org.quartz.impl.jdbcjobstore.StdJDBCDelegate
org.quartz.jobStore.dataSource = quartzDataSource

# 集群配置
org.quartz.jobStore.isClustered = true
org.quartz.jobStore.clusterCheckinInterval = 20000
org.quartz.jobStore.maxMisfiresToHandleAtATime = 1

# 数据源
org.quartz.dataSource.quartzDataSource.driver = com.mysql.cj.jdbc.Driver
org.quartz.dataSource.quartzDataSource.URL = jdbc:mysql://localhost:3306/quartz
org.quartz.dataSource.quartzDataSource.user = root
org.quartz.dataSource.quartzDataSource.password = root
org.quartz.dataSource.quartzDataSource.maxConnections = 10

Quartz 数据库表说明

表名	作用
`QRTZ_JOB_DETAILS`	JobDetail 信息
`QRTZ_TRIGGERS`	Trigger 信息
`QRTZ_CRON_TRIGGERS`	CronTrigger 信息
`QRTZ_SIMPLE_TRIGGERS`	SimpleTrigger 信息
`QRTZ_FIRED_TRIGGERS`	正在执行的触发器
`QRTZ_SCHEDULER_STATE`	调度器节点状态
`QRTZ_LOCKS`	集群锁信息

Spring Boot 集成

Maven 依赖

xml

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-quartz</artifactId>
</dependency>

配置

yaml

spring:
  quartz:
    job-store-type: jdbc   # 使用数据库存储
    jdbc:
      initialize-schema: always   # 自动初始化表结构
    properties:
      org:
        quartz:
          scheduler:
            instanceId: AUTO
          jobStore:
            class: org.quartz.impl.jdbcjobstore.JobStoreTX
            isClustered: true
            clusterCheckinInterval: 20000

定义 Job

java

@Component
public class DataSyncJob extends QuartzJobBean {
    @Override
    protected void executeInternal(JobExecutionContext context) {
        System.out.println("数据同步任务执行中...");
    }
}

配置 JobDetail + Trigger

java

@Configuration
public class QuartzConfig {

    @Bean
    public JobDetail dataSyncJobDetail() {
        return JobBuilder.newJob(DataSyncJob.class)
                .withIdentity("dataSyncJob")
                .storeDurably()
                .build();
    }

    @Bean
    public Trigger dataSyncTrigger() {
        return TriggerBuilder.newTrigger()
                .forJob(dataSyncJobDetail())
                .withIdentity("dataSyncTrigger")
                .withSchedule(CronScheduleBuilder.cronSchedule("0 0 2 * * ?"))
                .build();
    }
}

Quartz 的优缺点

优点	缺点
成熟稳定，社区庞大	缺乏统一的运维管理界面
灵活的集群机制	不支持任务分片
精确的时间调度	动态修改任务需要编码实现
与 Spring 深度集成	历史包袱重，API 略显陈旧

XXL-Job

概述

XXL-Job 是大众点评（许雪里）开源的分布式任务调度平台。它提供了一个轻量级的调度中心 + 执行器架构，具备开箱即用的 Web 管理界面、动态任务管理、分片广播、故障转移等能力，是目前国内使用最广泛的分布式任务调度框架之一。

架构设计

XXL-Job 采用经典的调度中心（中心节点） + 执行器（工作节点） 架构：

┌─────────────────────────────────┐
│         调度中心 (xxl-job-admin) │
│  ┌──────────┐ ┌──────────┐    │
│  │ 调度线程 │ │ Web 管理  │    │
│  └──────────┘ └──────────┘    │
└──────────┬──────────────────────┘
           │ 注册 / 发现 / 调度
   ┌───────┼───────┬───────┐
   ▼       ▼       ▼       ▼
┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐
│执行器1│ │执行器2│ │执行器3│ │执行器N│
│节点A  │ │节点B  │ │节点C  │ │节点D  │
└──────┘ └──────┘ └──────┘ └──────┘

调度中心：负责任务的调度触发、日志管理、执行器注册管理，提供 Web 界面
执行器：运行在业务应用中，接收调度中心的调度请求，执行具体任务逻辑

通信流程

执行器启动时向调度中心注册（IP + Port + AppName）
调度中心根据 Cron 表达式在指定时间向执行器发送 HTTP 调度请求
执行器接收请求后，通过线程池异步执行任务
执行完成后，执行器将执行结果回调给调度中心

任务类型

XXL-Job 支持三种任务类型：

Bean 模式

最常用的方式，任务类实现 IJobHandler 接口，由 Spring 容器管理：

java

@Component
public class MyJobHandler extends IJobHandler {
    @Override
    public ReturnT<String> execute(String param) throws Exception {
        XxlJobLogger.log("任务开始执行，参数: {}", param);
        // 业务逻辑
        System.out.println("处理任务，参数: " + param);
        return ReturnT.SUCCESS;
    }
}

GLUE 模式（动态代码）

GLUE 模式允许在调度中心的 Web 界面上直接编写和修改任务代码（Java/Shell/Python 等），调度中心将代码推送到执行器动态编译执行，无需重启应用：

java

// 在调度中心 Web 界面编写的 GLUE 代码
// 任务以 "glue_xxljob_" 命名存储
public ReturnT<String> execute(String param) {
    // 这里可以写任意 Java 代码
    System.out.println("GLUE 模式动态执行，参数: " + param);
    return ReturnT.SUCCESS;
}

Shell 模式

直接执行 Shell 脚本，适用于跨语言脚本任务：

bash

#!/bin/bash
echo "Shell 任务开始执行"
date
# 执行任意 shell 命令

路由策略

XXL-Job 提供丰富的路由策略，决定任务调度到哪个执行器节点：

策略	说明	适用场景
第一个	固定选择注册列表第一个节点	简单非关键任务
最后一个	固定选择注册列表最后一个节点	简单非关键任务
轮询	按顺序轮流分配	负载均衡
随机	随机选择一个节点	负载均衡
一致性 HASH	对参数哈希取模，同一参数始终路由到同一节点	有状态任务
最不经常使用（LFU）	选择最近使用次数最少的节点	均衡负载
最近最久未使用（LRU）	选择最久未使用的节点	均衡负载
故障转移	检测节点是否健康，失败则自动切换到下一个	高可用场景
忙碌转移	检查节点空闲程度，避免将任务分配给繁忙节点	资源敏感任务
分片广播	向所有节点广播，各节点根据分片参数处理数据子集	大数据量批处理

分片广播

分片广播是 XXL-Job 的核心能力。当路由策略设为分片广播时，调度中心向所有注册的执行器节点发送调度请求，每个节点收到 index（当前分片序号）和 total（总分片数）两个参数，各节点只处理属于自己的数据片段。

java

@Component
public class ShardingJobHandler extends IJobHandler {
    @Override
    public ReturnT<String> execute(String param) throws Exception {
        // 获取分片参数
        int shardIndex = XxlJobHelper.getShardIndex();    // 当前分片序号，从 0 开始
        int shardTotal = XxlJobHelper.getShardTotal();    // 总分片数

        // 假设需要处理 1000 万条用户数据
        List<Long> userIds = getAllUserIds();
        for (int i = 0; i < userIds.size(); i++) {
            // 根据分片取模，每个节点只处理属于自己的数据
            if (i % shardTotal == shardIndex) {
                processUser(userIds.get(i));
            }
        }
        return ReturnT.SUCCESS;
    }
}

分片广播的优势：

大数据量任务可以水平扩展，节点数越多处理越快
没有单点瓶颈，天然抗压
某一节点宕机只影响该分片的数据，不会导致整个任务失败

动态任务管理

XXL-Job 的调度中心 Web 界面提供完整的任务管理能力：

新增任务：在线创建任务，配置 Cron、路由策略、任务参数等
编辑任务：修改触发时间、路由策略等，即时生效
启停任务：暂停/恢复任务执行
手动触发：忽略 Cron 配置，立即手动执行一次
日志查看：查看每次执行的详细日志和调用链
GLUE 编辑：在线编辑 GLUE 任务代码，即时生效

Spring Boot 集成

Maven 依赖

xml

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

配置

yaml

# application.yml
xxl:
  job:
    admin:
      addresses: http://localhost:8080/xxl-job-admin   # 调度中心地址，多个逗号分隔
    accessToken: default_token
    executor:
      appname: my-app-executor      # 执行器应用名
      address:                      # 可选，手动指定执行器地址
      ip:                           # 可选，手动指定 IP
      port: 9999                    # 执行器端口
      logpath: /data/applogs/xxl-job/jobhandler
      logretentiondays: 30

执行器配置类

java

@Configuration
public class XxlJobConfig {

    @Value("${xxl.job.admin.addresses}")
    private String adminAddresses;

    @Value("${xxl.job.accessToken}")
    private String accessToken;

    @Value("${xxl.job.executor.appname}")
    private String appname;

    @Value("${xxl.job.executor.port}")
    private int port;

    @Bean
    public XxlJobSpringExecutor xxlJobExecutor() {
        XxlJobSpringExecutor executor = new XxlJobSpringExecutor();
        executor.setAdminAddresses(adminAddresses);
        executor.setAccessToken(accessToken);
        executor.setAppname(appname);
        executor.setPort(port);
        return executor;
    }
}

XXL-Job 的优缺点

优点	缺点
功能完备的 Web 管理界面	调度中心本身存在单点风险（可集群部署）
支持多种任务类型（Bean/GLUE/Shell）	依赖数据库
丰富的路由策略和分片广播	社区版部分高级功能不开放
轻量级，学习成本低	GLUE 模式动态编译存在安全风险
活跃的国内社区	与 Spring 生态耦合较高

Elastic-Job

概述

Elastic-Job 是当当网开源，后捐赠给 Apache ShardingSphere 作为其子项目的分布式任务调度框架。它最初的设计理念源自于 Google 的分布式调度系统，核心特点是弹性伸缩和数据分片。

Elastic-Job 经历了两个主要版本：

Elastic-Job-Lite：轻量级无中心化解决方案，依赖 Zookeeper 实现协调
Elastic-Job-Cloud：基于 Mesos 的云原生解决方案（目前已较少使用）

本文主要介绍 Elastic-Job-Lite。

核心架构

Elastic-Job 采用无中心化设计，不依赖独立的调度中心。所有任务节点通过 Zookeeper 进行协调，通过选举机制确定任务的主节点：

┌───────────────────────────────────────┐
│              Zookeeper                 │
│   (任务注册 / 分片协调 / 选举 / 跟踪)   │
└──┬──────┬──────┬──────┬──────┬────────┘
   │      │      │      │      │
   ▼      ▼      ▼      ▼      ▼
┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐
│节点1│ │节点2│ │节点3│ │节点4│ │节点5│
│主节点│ │分片0│ │分片1│ │分片2│ │分片3│
└────┘ └────┘ └────┘ └────┘ └────┘

主节点选举：节点启动后在 ZK 创建临时节点，第一个创建的节点成为主节点
主节点职责：负责分片分配、任务分发（不负责执行任务）
分片分配：主节点根据当前存活的节点数量和分片总数，计算每个节点负责的分片
弹性伸缩：节点新增或宕机时，ZK 临时节点变化触发重新分片

数据分片 Job

Elastic-Job 的核心模型是数据分片——将一个任务的数据分为多个分片，分片均匀分配给各节点执行。

定义分片 Job

java

public class MyShardingJob implements SimpleJob {
    @Override
    public void execute(ShardingContext shardingContext) {
        int shardingItem = shardingContext.getShardingItem();    // 当前分片项
        int shardingTotalCount = shardingContext.getShardingTotalCount(); // 总分片数
        String jobParameter = shardingContext.getJobParameter(); // 任务参数

        // 根据分片项处理对应数据
        List<Integer> dataList = getDataList();
        for (int i = 0; i < dataList.size(); i++) {
            if (i % shardingTotalCount == shardingItem) {
                processData(dataList.get(i));
            }
        }
    }
}

配置

yaml

elasticjob:
  regCenter:
    serverLists: localhost:2181
    namespace: elastic-job-demo
  jobs:
    myShardingJob:
      cron: 0 0/5 * * * ?
      shardingTotalCount: 4       # 总分片数
      shardingItemParameters: "0=北京,1=上海,2=广州,3=深圳"
      jobParameter: "test"
      failover: true              # 开启故障转移
      misfire: true               # 开启错过任务重新执行
      description: "数据分片示例任务"

Java API 配置

java

// 注册中心
CoordinatorRegistryCenter regCenter = new ZookeeperRegistryCenter(
        new ZookeeperConfiguration("localhost:2181", "elastic-job-demo"));
regCenter.init();

// 任务配置
JobConfiguration jobConfig = JobConfiguration.newBuilder("myShardingJob", 4)
        .cron("0 0/5 * * * ?")
        .shardingItemParameters("0=北京,1=上海,2=广州,3=深圳")
        .failover(true)
        .misfire(true)
        .build();

// 启动任务
new ScheduleJobBootstrap(regCenter, new MyShardingJob(), jobConfig).schedule();

任务分片策略

Elastic-Job 提供多种分片策略，可通过 SPI 机制扩展：

策略	类名	说明
平均分片	`AverageAllocationJobShardingStrategy`	默认策略，将分片尽量均匀分配给各节点
哈希分片	`OdevitySortByNameJobShardingStrategy`	根据任务名称哈希值奇偶性分配
轮询分片	`RotateServerByNameJobShardingStrategy`	根据任务名称按顺序轮询分配

java

// 自定义分片策略
JobConfiguration jobConfig = JobConfiguration.newBuilder("myJob", 4)
        .cron("0 0 2 * * ?")
        .jobShardingStrategyType("AVG_ALLOCATION")  // 平均分片
        .build();

// 或通过 SPI 加载自定义策略
// .jobShardingStrategyType("com.example.MyCustomStrategy")

平均分片算法逻辑：

假设总分片数为 shardingTotalCount，可用节点列表为 servers：

计算每个节点应分配的基础分片数：base = shardingTotalCount / servers.size()
计算剩余分片数：remainder = shardingTotalCount % servers.size()
前 remainder 个节点各多分配 1 个分片

例如：8 个分片分配给 3 个节点 → 节点分配为 [3, 3, 2]。

故障转移

当执行某分片的节点宕机时，Elastic-Job 的故障转移机制会将该分片重新分配给其他健康节点：

java

JobConfiguration jobConfig = JobConfiguration.newBuilder("myJob", 4)
        .cron("0 0 2 * * ?")
        .failover(true)        // 开启故障转移
        .monitorExecution(true) // 开启执行监控
        .build();

故障转移流程：

节点 A 在执行分片 0 的任务时宕机
Zookeeper 检测到节点 A 的临时节点消失
主节点感知到变化，触发重新分片
分片 0 被重新分配给节点 B 或节点 C
节点 B 从上次中断处继续执行（如果任务实现了幂等）

任务事件追踪

Elastic-Job 支持将任务执行事件持久化到数据库，便于追踪和审计：

yaml

elasticjob:
  trace:
    type: RDB             # 关系型数据库追踪
    dataSource:           # 追踪数据源，可指向业务库或独立库
      driverClassName: com.mysql.cj.jdbc.Driver
      url: jdbc:mysql://localhost:3306/elastic_job_trace
      username: root
      password: root

开启后会自动创建 JOB_EXECUTION_LOG 和 JOB_STATUS_TRACE_LOG 两张表，记录每次任务执行的完整生命周期信息：

字段	说明
`job_name`	任务名称
`sharding_item`	分片项
`execution_id`	执行 ID
`start_time`	开始时间
`complete_time`	完成时间
`success`	是否成功
`failure_cause`	失败原因
`task_summary`	任务摘要

Spring Boot 集成

Maven 依赖

xml

<dependency>
    <groupId>org.apache.shardingsphere.elasticjob</groupId>
    <artifactId>elasticjob-lite-spring-boot-starter</artifactId>
    <version>3.0.3</version>
</dependency>

配置

yaml

elasticjob:
  regCenter:
    serverLists: localhost:2181
    namespace: elastic-job-springboot
  jobs:
    dataSyncJob:
      elasticJobClass: com.example.DataSyncJob
      cron: 0 0 2 * * ?
      shardingTotalCount: 4
      shardingItemParameters: "0=shard0,1=shard1,2=shard2,3=shard3"
      failover: true
      misfire: true
      overwrite: true

实现 Job

java

@Component
public class DataSyncJob implements SimpleJob {
    @Override
    public void execute(ShardingContext context) {
        int shard = context.getShardingItem();
        String shardParam = context.getShardingParameter();
        System.out.println("分片 " + shard + " 处理参数: " + shardParam);
        // 业务逻辑
    }
}

Elastic-Job 的优缺点

优点	缺点
无中心化，架构简洁	强依赖 Zookeeper，运维成本高
原生支持弹性伸缩	缺乏内置管理界面（需额外开发或使用第三方）
灵活的分片策略和 SPI 扩展	无动态 Cron 修改（需重新调度）
任务事件追踪机制完善	社区活跃度不如 XXL-Job
Apache 基金会背书	学习曲线相对陡峭

对比表

特性	Quartz	XXL-Job	Elastic-Job
定位	任务调度库	分布式任务调度平台	分布式任务调度框架
架构模式	库嵌入应用	调度中心 + 执行器	无中心化（ZK 协调）
配置方式	Java API / Spring Boot 配置 / properties	Web 界面配置 + application.yml	Java API / YAML / Spring Boot Starter
运维界面	❌ 无	✅ 完整的 Web 管理界面	❌ 无官方界面（有第三方扩展）
任务分片	❌ 不支持	✅ 分片广播	✅ 天然数据分片
动态调度	❌ 需重启或 API 编程	✅ Web 界面实时修改	❌ 需重新调度
集群模式	✅ 数据库行锁	✅ 多调度中心 + 多执行器	✅ ZK 协调 + 主节点选举
故障转移	⚠️ 基于 JobStore 恢复	✅ 故障转移路由策略	✅ 重新分片转移
Cron 支持	✅ 完整	✅ 完整	✅ 完整
执行日志	❌ 需自行集成	✅ 内置完整日志	✅ 事件追踪（支持 RDB）
任务类型	纯 Java Job	Bean / GLUE / Shell / Python	Simple / Dataflow / Script
外部依赖	可选数据库（集群模式）	数据库	Zookeeper（必选）
Spring Boot 集成	✅ 官方 Starter	✅ 官方 Starter	✅ 官方 Starter
社区活跃度	⭐⭐⭐ 稳定成熟，更新慢	⭐⭐⭐⭐⭐ 国内最活跃	⭐⭐⭐ 加入 Apache 后稳定
学习成本	⭐⭐ 较低	⭐⭐ 较低	⭐⭐⭐⭐ 较高
部署复杂度	⭐ 简单（库级别）	⭐⭐⭐ 需部署调度中心	⭐⭐⭐⭐ 需维护 ZK
适合规模	中小型项目	中型到大型项目	大型、数据分片密集型项目

选型建议

按场景选择

场景	推荐方案	理由
简单定时任务，无分布式需求	Spring `@Scheduled` / Quartz	零依赖、快速开发
传统企业应用，已有数据库基础设施	Quartz 集群模式	无需引入额外中间件，稳定可靠
需要统一管理界面的中型项目	XXL-Job	功能完备的 Web 管理、动态调度、低学习成本
大数据量批处理，需要任务分片	XXL-Job 分片广播 / Elastic-Job	分片并行处理，水平扩展
已有 ZK 基础设施的微服务体系	Elastic-Job	利用现有 ZK，无中心化，弹性伸缩
跨语言任务（Python/Shell）	XXL-Job GLUE/Shell 模式	内置支持多语言任务
金融级容错场景	XXL-Job（故障转移路由） / Elastic-Job（重新分片）	完备的容错机制
云原生环境（K8s）	XXL-Job	部署灵活，与容器化适配性好

综合建议

中小项目（< 10 个任务）：优先考虑 Spring @Scheduled + Quartz，简单可靠，不需要额外部署
中型项目（10~100 个任务，需要管理界面）：推荐 XXL-Job，开箱即用、社区活跃、中文文档完善
大型数据密集型项目（> 100 个任务，海量数据分片）：推荐 Elastic-Job 或 XXL-Job 分片广播，前者适合已有 ZK 的环境，后者部署更轻量
已有 ShardingSphere 技术栈：推荐 Elastic-Job，统一技术体系，降低运维复杂度

注意：选型时还需考虑团队技术储备。XXL-Job 上手快、中文资源丰富；Elastic-Job 需要 ZK 运维能力；Quartz 方案灵活但缺乏统一管理。建议根据团队实际情况和未来扩展需求综合权衡。

定时任务（XXL-Job / Quartz / Elastic-Job） ​

定时任务概述 ​

什么是定时任务 ​

应用场景 ​

单机定时任务的局限 ​

分布式定时任务的核心需求 ​

Quartz ​

概述 ​

核心概念 ​

Job / JobDetail ​

Trigger ​

Cron 表达式 ​

Scheduler ​

集群模式 ​

集群原理 ​

配置示例 ​

Quartz 数据库表说明 ​

Spring Boot 集成 ​

Maven 依赖 ​

配置 ​

定义 Job ​

配置 JobDetail + Trigger ​

Quartz 的优缺点 ​

XXL-Job ​

概述 ​

架构设计 ​

通信流程 ​

任务类型 ​

Bean 模式 ​

GLUE 模式（动态代码） ​

Shell 模式 ​

路由策略 ​

分片广播 ​

动态任务管理 ​

Spring Boot 集成 ​

Maven 依赖 ​

配置 ​

执行器配置类 ​

XXL-Job 的优缺点 ​

Elastic-Job ​

概述 ​

核心架构 ​

数据分片 Job ​

定义分片 Job ​

配置 ​

Java API 配置 ​

任务分片策略 ​

故障转移 ​

任务事件追踪 ​

Spring Boot 集成 ​

Maven 依赖 ​

配置 ​

实现 Job ​

Elastic-Job 的优缺点 ​

对比表 ​

选型建议 ​

按场景选择 ​

综合建议 ​

定时任务（XXL-Job / Quartz / Elastic-Job）

定时任务概述

什么是定时任务

应用场景

单机定时任务的局限

分布式定时任务的核心需求

Quartz

概述

核心概念

Job / JobDetail

Trigger

Cron 表达式

Scheduler

集群模式

集群原理

配置示例

Quartz 数据库表说明

Spring Boot 集成

Maven 依赖

配置

定义 Job

配置 JobDetail + Trigger

Quartz 的优缺点

XXL-Job

概述

架构设计

通信流程

任务类型

Bean 模式

GLUE 模式（动态代码）

Shell 模式

路由策略

分片广播

动态任务管理

Spring Boot 集成

Maven 依赖

配置

执行器配置类

XXL-Job 的优缺点

Elastic-Job

概述

核心架构

数据分片 Job

定义分片 Job

配置

Java API 配置

任务分片策略

故障转移

任务事件追踪

Spring Boot 集成

Maven 依赖

配置

实现 Job

Elastic-Job 的优缺点

对比表

选型建议

按场景选择

综合建议