📚 课程目录第1章调度系统选型

1. 调度系统选型：自研 vs 开源框架的取舍与避坑

说到调度系统选型，这几乎是每个团队都会遇到的灵魂拷问。我自己经历过三次选型决策，每次的结论都不一样。说白了，没有银弹，只有最适合你当前阶段的方案。

先看一张整体对比图，帮你快速建立全局认知：

自研调度系统：什么时候该走这条路？

先说说自研。我见过不少团队，一上来就想自研调度系统。为什么？因为觉得开源框架不够灵活，或者想打造"技术壁垒"。但说实话，自研的坑比想象中多。

我曾经踩过的坑： 有个项目，团队花了三个月自研调度引擎，结果上线第一天就遇到任务丢失问题。排查了两天，发现是状态机设计有缺陷。如果当时用成熟框架，半天就能搞定。

自研适合的场景其实很明确：

任务规模极大：每天千万级以上的任务调度，开源框架的调度器可能成为瓶颈
调度逻辑极其特殊：比如需要支持复杂的DAG依赖、动态分片、实时优先级调整
团队有足够人力：至少3-5人专职维护，且具备分布式系统设计经验
时间不紧迫：可以接受6个月以上的研发周期

但你要想清楚，自研不只是写代码。你还要搞定：任务持久化、失败重试机制、分布式锁、调度器高可用、任务分片策略、监控告警……每一样都不简单。

三大开源框架：Quartz、XXL-JOB、Elastic-Job

如果决定用开源，那选哪个？我直接给你对比表：

特性	Quartz	XXL-JOB	Elastic-Job
定位	轻量级任务调度库	分布式任务调度平台	分布式弹性作业调度
部署方式	嵌入应用	调度中心+执行器	ZooKeeper协调
任务分片	不支持	支持（广播/分片）	支持（分片策略丰富）
失败处理	简单重试	邮件/回调/重试	失效转移+重分片
运维界面	无	功能完善	基础功能
学习成本	低	中	高

Quartz：小而美的选择

Quartz 我用了很多年。它本质上就是个库，不是平台。你把它 jar 包引进来，写几行代码就能跑起来。

// Quartz 最简单的用法
JobDetail job = JobBuilder.newJob(MyJob.class)
    .withIdentity("myJob", "group1")
    .build();

Trigger trigger = TriggerBuilder.newTrigger()
    .withIdentity("myTrigger", "group1")
    .withSchedule(SimpleScheduleBuilder.repeatSecondlyForever(10))
    .build();

scheduler.scheduleJob(job, trigger);
scheduler.start();

你看，代码很简洁。但 Quartz 的坑也不少：

集群模式依赖数据库锁：性能瓶颈明显，节点多了容易死锁
没有管理界面：任务状态全靠日志，排查问题很痛苦
不支持动态分片：所有节点执行相同任务，资源浪费

我的建议： Quartz 适合单机或少量节点的场景。如果你只有几台机器，任务量不大，Quartz 是最轻量的选择。但一旦超过5个节点，我建议你换 XXL-JOB。

XXL-JOB：中小团队的利器

XXL-JOB 是我目前最推荐的开源调度框架。为什么？因为它把"好用"做到了极致。

它的架构很清晰：一个调度中心，多个执行器。调度中心负责任务分发，执行器负责干活。两者通过 HTTP 通信，部署非常简单。

// XXL-JOB 执行器示例
@Component
public class MyJobHandler extends IJobHandler {
    @Override
    public ReturnT<String> execute(String param) throws Exception {
        XxlJobLogger.log("任务开始执行，参数：{}", param);
        // 业务逻辑
        return ReturnT.SUCCESS;
    }
}

XXL-JOB 的几个亮点：

管理界面完善：在线查看日志、手动触发、停止任务、查看执行记录
分片广播：支持按参数分片，每个节点处理一部分数据
失败重试策略：支持固定间隔、指数退避等多种重试方式
动态扩容：执行器上下线自动感知，无需重启

我曾经遇到的坑： 有一次线上任务突然全部失败，排查发现是调度中心的数据库连接池满了。XXL-JOB 默认的数据库连接池配置偏小，高并发场景下需要手动调大。另外，调度中心是单点，虽然可以部署多台，但需要自己配置负载均衡。

Elastic-Job：复杂场景的王者

Elastic-Job 是当当开源的，后来捐给了 Apache。它的核心优势在于弹性调度和分片能力。

它的架构依赖 ZooKeeper，所有节点通过 ZK 协调。任务分片策略非常灵活，支持轮询、哈希、自定义等。

// Elastic-Job 任务示例
public class MyElasticJob implements SimpleJob {
    @Override
    public void execute(ShardingContext shardingContext) {
        int shardingItem = shardingContext.getShardingItem();
        int totalCount = shardingContext.getShardingTotalCount();
        // 根据分片项处理对应数据
        List<Data> dataList = fetchDataBySharding(shardingItem, totalCount);
        processData(dataList);
    }
}

Elastic-Job 的优势很明显：

分片策略丰富：支持平均分配、哈希分配、自定义分配
弹性伸缩：节点增减自动重新分片，无需人工干预
失效转移：节点宕机后，任务自动转移到其他节点
作业依赖：支持简单的作业依赖关系

但它的缺点也很突出：

强依赖 ZooKeeper：ZK 集群本身需要维护，增加了运维复杂度
学习曲线陡峭：概念多，配置复杂，新手容易出错
管理界面简陋：相比 XXL-JOB，界面功能少很多

  我的经验： Elastic-Job 适合任务量大、节点多、需要频繁扩缩容的场景。如果你的团队有 ZK 运维经验，Elastic-Job 是不错的选择。否则，我建议优先考虑 XXL-JOB。

选型决策清单

最后，我给你一个实用的决策清单。每次选型前，对照着打勾：

任务量：每天任务数 < 10万 → 开源框架；> 100万 → 考虑自研
节点数：< 5个 → Quartz；5-50个 → XXL-JOB；> 50个 → Elastic-Job
定制需求：标准 CRON + 简单重试 → 开源框架；复杂 DAG + 动态分片 → 自研
团队能力：有分布式系统经验 → 自研或 Elastic-Job；新手团队 → XXL-JOB
运维投入：愿意维护 ZK → Elastic-Job；不想额外运维 → XXL-JOB
时间窗口：1个月内上线 → XXL-JOB；3个月以上 → 自研

嗯，选型这件事，没有标准答案。但记住一个原则：用最简单的方案解决当前的问题，为未来的扩展留好接口。别一开始就想搞个大而全的东西，那往往是灾难的开始。