分布式定时任务调度系统实践：从Cron到AX调度平台

跟任务调度打交道久了，你会发现一个很有意思的现象：很多业务团队最早都是从几个 cron 脚本开始跑定时任务，跑着跑着一两年过去，脚本越来越多，互相之间出现依赖，半夜失败以后没人知道，数据对不上账也没人敢重跑。我这里说的 ax 并不是那个 Wi-Fi 6 的 802.11ax，也不是什么斧头类游戏道具，而是一个内部项目的代号——AX 调度。这个项目本质上是一套分布式定时任务与异步任务调度系统，把任务的创建、触发、执行、重试、监控全部收敛到一个统一平台里。

这篇文章我围绕 AX 调度的完整落地过程来写，包括为什么没直接上现成组件、任务模型怎么设计、分布式锁怎么才能不出事故、压测数据大概是多少，以及一系列我在实际运维中踩过的坑。如果你正准备把团队里的零散 cron 收拢成一套正经的调度平台，或者已经在用 XXL-Job、Quartz 但觉得不够贴合业务，这篇内容应该能给你不少可以照抄的细节。

1. 项目整体设计与思路拆解

1.1 出发：先说清 AX 调度解决的是一类什么问题

很多团队在最早期往往只有一两个定时任务，比如每天凌晨同步一次数据、每小时清理一次日志，用系统的 crontab 就能搞定。但业务一旦复杂起来，定时任务会迅速失控。我见过一个团队在生产环境挂了大概 30 多个 cron 脚本，分散在三四台机器上，有些脚本之间还有隐式的先后依赖——上游不跑完，下游跑出来就是脏数据。出了问题就只能靠人去翻日志，找到执行记录再手动补跑，几乎谈不上可靠和可观测。

AX 调度最开始的目标非常朴素：把分散在各台机器上的定时任务收进来，做成一个可以统一查看、统一编辑、带失败重试和告警的调度中心。后续业务提出异步任务、延迟任务、分片任务这些需求以后，体系才逐步长成。核心要解决的四个问题分别是：定时触发的可靠性、任务执行期间的状态可见性、失败后的自动重试与幂等兜底、以及多实例部署时不会出现任务重复执行。

这四个问题听起来简单，但真正落地过的人知道，每一个背后都有大量细节。比如定时触发不只是“到点调一个接口”，还要考虑错过了触发时间怎么办、实例重启以后没有补偿怎么办；任务状态也不只是“成功/失败”两个值，中间还夹着运行中超时、手动取消、被下游依赖阻断等一堆状态。AX 调度的整个设计，本质上是围绕这几个问题上做的取舍。

1.2 技术选型：为什么不是 Quartz，也不是直接上 K8s CronJob

做选型的时候，我把市面上常见的方案都摆在一起比过一轮：Quartz、XXL-Job、Apache Airflow、K8s CronJob，以及自研的 AX。

Quartz 本身是一个非常好的调度库，但它在集群环境下要依赖数据库锁来做调度互斥，时间触发精度在大规模任务下会随着任务数量上升而明显下降。XXL-Job 是一个很成熟的开源产品，文档也全，但它天然带了自己的管理端和执行器模型，接入以后很多逻辑要往它的模型上靠。Airflow 更适合做数据管道编排，用来跑普通业务接口显然太重了。

最后决定不走“拿开源产品改”的路线，核心原因是业务侧有很多定制需求。我们要的任务不只是“到点触发 HTTP 请求”，还包含延迟队列、任务分级、跨服务编排、灰度发布任务、失败分群提示这类偏业务能力。与其在开源框架上绕来绕去，不如用一个非常朴素的核心模型自己搭。AX 的核心模型其实只有三件事：任务、触发、执行结果。简单反而让后续扩展余地变得很大。

1.3 整体架构与核心流程

AX 调度在逻辑上拆分成三个模块：ax-server（调度中心）、ax-worker（执行器）、ax-console（管理后台）。

ax-server 负责任务的注册、调度时间计算、任务分发和结果回收，是无状态服务，可以水平扩多个实例。所有实例共享同一套任务配置数据库，通过 Redis 做分布式锁和延迟队列。ax-worker 是真正跑业务逻辑的一端，它接收调度中心下发的任务，执行业务方法，再把结果回调给调度中心。ax-console 提供可视化的任务管理界面。

一条任务从创建到完成的核心流程大致如下：

1. 用户在 ax-console 创建任务，写入任务配置表，指定任务类型、调度表达式、超时时间、重试次数、所属业务分组。
2. ax-server 启动后从数据库加载未完成任务，并把最近需要触发的任务写入 Redis ZSet，score 为下一次触发时间戳。
3. 调度线程每秒从 Redis ZSet 拉取 score 小于等于当前时间戳的任务，取出后投递到任务分发线程池。
4. 分发线程根据任务配置选择对应的 ax-worker，把任务请求发给执行器。
5. ax-worker 收到请求后开始执行，并在执行过程中定期上报心跳、更新执行日志。
6. 执行结束后，ax-worker 把结果回调给 ax-server，ax-server 更新任务状态和下次触发时间。
7. 如果执行失败，ax-server 判断重试次数是否耗尽：没有耗尽则重新进入延迟队列等待重试，已耗尽则标记失败并触发告警。

这整个流程听起来并不复杂，但实际开发里最花时间的恰恰是那些异常分支：回调丢了怎么办、执行器假死怎么办、任务重试时业务侧重复执行了怎么办。后面我会逐个拆开讲。

2. 核心细节解析与实操要点

2.1 任务模型与生命周期状态机

AX 调度里有一个最核心的表，叫任务表 ax_task，它保存任务本身的配置信息。任务实例执行时会产生 ax_task_log，记录每一次触发和执行的实际情况。

任务整体生命周期我用状态机管理，避免状态散落得到处都是。核心状态如下：

状态机设计的关键是让每个状态都有明确的进入与离开条件。比如 RUNNING 不是靠执行器回调才能离开，调度中心还有一个超时扫描线程，它定期扫描长期处于 RUNNING 状态的任务，一旦超过配置的超时时间，就先把状态改成 TIMEOUT，再通知执行器执行中断。这个超时扫描很重要，因为执行器可能会假死，网络分区时回调也可能一直发不回来，如果只依赖回调，任务状态会永远卡在 RUNNING。

这里有个容易被忽略的细节：任务状态与执行日志状态要分开。任务配置表 ax_task 上的字段表达“这个任务最近一次跑到什么状态了”，而 ax_task_log 记录每一次运行的具体状态。否则一个每日执行的任务，你只能看到最终状态，无法回溯历史执行过程，排查问题会非常痛苦。

2.2 分布式锁的正确姿势

调度中心既然可以水平扩展，那理论上多个调度实例可能同时把同一个任务拉出来执行，这是任务重复执行的最大来源。AX 调度里我用 Redis 分布式锁来保证同一时刻同一个任务只被一个实例处理。

很多文章教人用 setnx 加锁，用完再 del，这个思路能跑通 demo，但离生产可差得远。AX 里的分布式锁实现做了三件关键事：锁的 value 必须携带一个全局唯一的请求标识，比如 UUID，这样释放锁的时候要校验 value 是否属于自己，防止误删别人的锁；设置锁的时候必须用 set key value nx ex 这种原子命令，而不是 setnx 之后单独设置过期时间，否则中间进程崩溃会让过期时间设置失败，锁永远不会释放；锁的过期时间要略微大于任务执行时间，并且执行期间要做续期，我建议用一个后台线程每过三分之一过期时间就续一次锁。

我当时踩过的真实事故是这样的：某次任务执行时间比较久，锁过期了，另一个调度实例抢到锁开始执行同一个任务，两边同时跑，下游接口被重复调用了好几次，出现了脏数据。后来我把锁的过期时间从固定 60 秒改成根据任务预估执行时间动态计算，并加了续期逻辑，这个问题才算彻底根治。分布式锁不是加一个 setnx 就高枕无忧，它需要像一小节有状态的生命周期来管理。

2.3 任务幂等与超时控制

分布式锁能避免同一个任务被两个调度实例同时捞出去执行，但它没法处理一种情况：任务调用下游 RPC 之后，网络超时了，调度中心判定这次执行失败，进入重试，于是任务被同一实例再次执行。对下游系统来说，这相当于重复请求，所以 AX 调度强制要求每个任务都要做幂等设计。

具体做法是定义全局唯一的执行标识，简称为 gid。ax-server 每次分发任务时生成一个 gid，透传给 ax-worker，ax-worker 调用下游系统时把 gid 作为幂等键传递。下游系统收到请求后先查幂等表，如果这个 gid 已经处理过，直接返回上一次结果；如果没有，才执行业务逻辑并把结果落库。这个设计很简单，但很多人会忽略 gid 的生成规则，直接用任务 ID 加时间戳其实是错的——重试时时间戳变了，幂等就失效了。正确做法是 gid 由任务实例 ID 直接派生，我推荐用 ax_task_log 的主键作为 gid 来源，同一个任务实例无论重试多少次，gid 始终保持不变。

超时控制方面，AX 采用两层超时：调度侧超时和执行器侧超时。调度侧超时主要防止执行器失联导致任务卡死，执行器侧超时则控制任务本身的执行时长，以代码里 Future.get 的 wait 时间来实现。两层超时的时间设置要有区别，建议执行器侧超时比调度侧超时短 5 到 10 秒，这样执行器侧先超时，主动中断任务并上报超时结果，调度中心就不用等到扫描线程来处理了。

2.4 优先级分组与资源隔离

调度系统最让人头疼的场景之一，是一个低优先级的批量任务把线程池占满，导致线上高优任务排队等了几分钟。AX 调度从一开始就把任务按业务分组隔离开，每一组任务有独立的调度配额和执行线程池。

分组对应一张 ax_group 表，字段包括 group_key、调度配额、告警联系人。比如支付相关的任务组，调度配额是 200，线程池大小是 50；报表相关的任务组，调度配额是 50，线程池大小是 10。这样即使报表组任务量爆发，也不会抢占支付组的执行线程。

同一个组内的任务，AX 还支持优先级字段 priority。优先级高的任务在分发队列里会被优先取出，代码实现上用 Redis 的 ZSet 本身就是按 score 排序的，所以优先级调度不需要额外维护队列，直接把优先级映射到 score 的低位区间就行。这里需要注意的是优先级不能只靠调度端的队列保证，执行器端也要有对应的处理优先级。ax-worker 接收到多个任务请求时，会先把请求放入一个队列，再按优先级重新排列，这样即使调度端同时分发一批任务，执行器端也不会出现低优任务抢占高优任务的情况。

3. 实操过程与核心环节实现

3.1 表结构设计与初始化

先看 AX 任务表的核心字段。我这套用 MySQL 8.0，表结构做了最简优化，去掉了业务无关的冗余字段。

CREATE TABLE ax_task ( id BIGINT PRIMARY KEY AUTO_INCREMENT, group_key VARCHAR(64) NOT NULL COMMENT '任务分组', task_name VARCHAR(128) NOT NULL COMMENT '任务名称', task_type TINYINT NOT NULL COMMENT '任务类型：1-scheduled 2-delay 3-event', status TINYINT NOT NULL DEFAULT 0 COMMENT '任务状态：0-创建 1-启用 2-暂停', cron_expr VARCHAR(32) COMMENT 'cron 表达式', executor_key VARCHAR(128) NULL COMMENT '执行器标识', biz_param TEXT NULL COMMENT '业务参数，JSON 格式', timeout_seconds INT NOT NULL DEFAULT 60 COMMENT '超时时间', retry_count TINYINT NOT NULL DEFAULT 3 COMMENT '最大重试次数', priority TINYINT NOT NULL DEFAULT 5 COMMENT '优先级 1-10', last_trigger_time BIGINT NULL COMMENT '上次触发时间戳', next_trigger_time BIGINT NULL COMMENT '下次触发时间戳', version INT NOT NULL DEFAULT 0 COMMENT '乐观锁版本', create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY idx_group_status (group_key, status), KEY idx_next_time (next_trigger_time) );

任务执行日志表 ax_task_log 负责记录每一次触发实例的执行状态，核心字段是 task_id、gid、trigger_time、start_time、end_time、status、result_msg、retry_times、trace_id。

初始化时注意两点：一是 task_type 要设计得足够抽象，我见过很多调度系统把定时任务和延迟任务分成两张表，维护成本加倍，其实它们在触发逻辑上高度一致，只是触发时间来源不同；二是 next_trigger_time 必须建索引，调度中心每次启动都要扫描下一批要触发的任务，没有这个索引，任务量一上来肯定全表扫描。

3.2 调度主循环实现细节

ax-server 的调度主循环是整个系统的发动机。我用 Go 来写这一段，因为 goroutine 在这个场景下用着顺手，但换成 Java 对应的逻辑也完全一样。

func (s *Scheduler) dispatchLoop(ctx context.Context) { ticker := time.NewTicker(1 * time.Second) defer ticker.Stop() batchSize := 200 for { select { case <-ctx.Done(): return case <-ticker.C: now := time.Now().UnixMilli() keys := buildZSetKeys() for _, key := range keys { s.pullAndDispatch(key, now, batchSize) } } } } func (s *Scheduler) pullAndDispatch(key string, now int64, batchSize int) { tasks, err := s.redis.ZRangeByScore(key, now, batchSize) if err != nil { log.Errorf("pull tasks from redis failed: %v", err) return } for _, t := range tasks { // 尝试获取分布式锁 locked, err := s.tryLock(t.ExecutorKey, t.Id, t.Gid) if err != nil || !locked { continue } // 投递到本机分发线程池 s.dispatchPool.Submit(func() { s.dispatch(t) }) } }

这里一个非常关键的细节：ZSet 里拉取任务之后，不能立刻删除任务的 zset 成员。如果立刻删除，但分发线程执行任务时失败，任务需要回滚到队列里，处理起来会很绕。我的做法是先把任务从 ZSet 中移除，但把整个任务对象反序列化后放入自己维护的待执行集合中，执行完再根据结果决定是回写 ZSet 还是直接更新状态。这样既避免多个调度实例同时捞到同一个任务，又保留了失败回滚的能力。

另外，ZSet 的 key 我这里做了分片，默认 16 个分片。所有任务按照 group_key 的 hash 值落到不同分片的 ZSet，防止单 key 数据量过大导致 Redis 操作变慢。如果你任务量不大，不分片问题也不大，但一旦每秒调度任务量超过几千，分片优势就很明显了。

3.3 执行器回调与结果处理

ax-worker 接收到任务后，会按照 executor_key 找到对应的执行器实现类，反射调用业务方法，然后把执行结果回调给 ax-server。

回调不能做成同步 HTTP 请求后直接等结果。真实场景里，调度中心分发时可能正好在发布重启，或者网络抖动导致回调失败，所以 AX 设计成执行器先写本地结果队列，异步把结果上报。

func (w *Worker) execute(task Task) { execResult, err := w.invoke(task) if err != nil { execResult = &Result{Status: StatusFailed, Message: err.Error()} } // 本地落一条结果记录 w.localResultStore.Save(task.ExecutionId, execResult) // 异步回调调度中心 w.callbackAsync(task.ExecutionId, execResult) }

回调结果写到 MySQL 时再做一层校验：只有当前任务状态是 RUNNING 或 RETRYING 时才允许更新为 SUCCESS 或 FAILED。如果任务已经被超时扫描线程改成了 TIMEOUT，回调结果仍然记录到日志表，但不更新任务主状态。用乐观锁版本号实现，更新语句带上 where version = current_version，稳得很。

这里顺便说一下重试的表态公式。每次执行失败后，判断当前重试次数是否小于配置的最大重试次数，如果小于，则把任务重新放入延迟队列，延迟时间按 2 的 n 次方递增，即 1 分钟后重试、2 分钟后重试、4 分钟后重试，封顶 30 分钟。这个简单指数退避策略比固定延迟效果好很多，能避免服务恢复瞬间发生重试风暴。

3.4 压测结果与配置参考

AX 调度上线前我做了一轮压测，这里把关键数据放出来，你们可以对照自己的机器配置来评估。

压测环境：8 核 16G 虚拟机两台跑 ax-server，Redis 6.0 单节点，MySQL 8.0 单实例，任务总量 2 万个定时任务，调度频率为每 10 秒一批，任务执行时间是模拟的真实 HTTP 调用，平均耗时 80ms。

这个压测结果基本满足大部分业务场景。如果你的任务量超过这个量级，优先把 Redis 换成集群模式，再不行就把调度任务量按租户维度做垂直拆分。调度延迟的 P99 主要花在 Redis 和网络 IO 上，任务本身不复杂的话，单机调度 5000 个任务每秒并没有太大压力。

4. 常见问题与排查技巧实录

4.1 任务重复执行，先从一张调度日志找线索

线上最怕的就是“任务明明只该跑一次，结果跑了一次又一次”。我处理过的重复执行案件里，真正因为分布式锁失效的其实占比不大，更多是回调超时后触发了重试，而下游接口没有做幂等。

排查这类问题我的经验是先查 ax_task_log 表，从日志看同一个 task_id 在同一个时间窗口内的多条日志，比较它们的 gid。如果 gid 相同，说明是同一任务实例的重试；如果 gid 不同，说明是多个调度实例各自捞取了一次，那就要查分布式锁为什么没有生效。两条路径的修复方案完全不同，前者是下游幂等没做好，后者是锁本身有问题。很多新手一上来就去翻 Redis 锁的日志，方向就错了。

补充一个排查技巧：ax-worker 每次收到任务请求时，把任务 ID、gid、执行器 IP 完整打一行日志，这行日志是解决 80% 重复执行问题的钥匙。没有这行日志的话，两边日志时间轴对不上，排查难度会高一个量级。

4.2 任务积压导致调度延迟飙升

某个业务组曾经因为大量耗时的导出任务堆积，把调度延迟从 20ms 推到 5 分钟级别。当时的表象是所有的任务触发时间都比配置时间晚了几分钟，业务方来投诉说定时上报的数据没有按时出现。

我看了一眼监控，调度线程池的活跃线程数是 200，直接满编。这些线程全被大量耗时 3 到 5 秒的导出任务占住了。问题出在调度分发时没有区分任务的执行时长类型，把短任务和长任务混在同一个线程池里。长任务占线程，短任务排队等，延迟自然就上去了。

解决办法有两个层面。第一个层面，按照任务时长打断言，长耗时任务走单独的线程池，带宽限制更严格。第二个层面，调度分发时增加一个“已投递未完成数量”的指标，如果某个组的未完成任务数超过阈值，新任务直接进入等待队列，而不是盲目往线程池里塞。压测里我把这个阈值设置为线程池大小乘 3，实测下来系统稳定很多。

4.3 锁超时但任务实际执行成功的情况

前面提过锁过期导致重复执行，这里还有个更隐蔽的问题：任务实际执行成功了，但因为锁超时被另一个实例抢走执行，第二个实例也成功了，结果下游系统同一笔业务被处理了两次。这个事故的根源在于任务执行时间超过了预估。

我们后来的解决方案是：执行器执行期间必须发送心跳，心跳不仅用于续期分布式锁，还会实时更新任务日志表的心跳时间。调度中心的超时扫描线程判断任务是否超时，不再只看总时长，而是看“最近一次心跳到现在”的间隔。只要执行器还在发心跳，任务就一直保持 RUNNING；一旦心跳停了，才可能判定超时。这个机制能有效减少执行苏醒但实际正常的情况。与此同时，锁的续期逻辑和执行器心跳绑定，心跳发一次，锁就续一次过期时间，从机制上杜绝了锁比任务先过期的情况。

4.4 实例重启后任务丢失

开发环境重启服务是很频繁的事，但 AX 初版上线时确实遇到过一个问题：凌晨一次性重启所有 ax-server 实例，结果本该在凌晨 2 点触发的任务没跑，第二天早上业务报警才发现。

原因是任务只在 Redis ZSet 里存了一份，Redis 虽然不会丢，但重启后我的调度主循环只加载 next_trigger_time 大于当前时间的任务，那些在重启窗口期已经该触发但还没触发的任务被跳过了。这个 bug 的修复方式是在 ax-server 启动时补做一个补签操作：从数据库扫描 last_trigger_time 小于配置周期且 next_trigger_time 已经早于当前时间且状态为 ENABLED 的任务，把它们重新投入调度队列。补签窗口设置成 10 分钟，超过 10 分钟没跑的任务视为异常，人工介入处理，避免服务宕机很久以后重启时瞬间把所有历史任务全部补跑一遍，造成下游压力过载。

4.5 配置了几个最佳实践的默认值

最后分享一组经验默认值，适合大多数常规业务：任务超时时间默认 60 秒，允许重试 3 次，重试退避策略用 1 分钟、2 分钟、4 分钟指数递增，锁过期时间设置为超时时间加 10 秒，心跳上报频率每 15 秒一次，调度主循环轮询周期 1 秒。这组参数在我维护的大部分业务系统里都能直接使用，可以当作起步值，再根据具体业务调整。

5. 扩展经验与个人体会

5.1 从单机任务到 DAG 工作流的自然演进

AX 调度做到第二个月，业务侧提出了一个典型需求：数据同步任务跑完以后，要自动触发数据校验任务，校验通过之后再触发报表生成任务。这不再是简单的定时任务，而是任务之间的依赖编排。

当时有两种方案：一种是在任务参数里加一个上游任务 ID，上游执行成功之后由调度中心主动触发下游；另一种是引入完整的 DAG 模型。我最终选了前者，原因很简单：业务真正需要的有向依赖不超过两层，引入完整 DAG 的工作量和对任务模型的影响都不划算。在 ax_task 表里增加 upstream_task_id 字段，执行器执行成功后，调度中心判断是否存在下游任务，如果存在直接投递下游。这个轻量级方案上线后运转得很稳定。如果你确实需要复杂的大规模 DAG 编排，再考虑引入 Argo 或 Airflow 那一层，不必一开始就上重武器。

5.2 简单模型带来的维护红利

现在回头看，AX 这个项目最值得骄傲的并不是功能有多丰富，而是核心模型足够简单，简单到每个新接手的人在一小时内就能看懂状态机。你去看很多开源调度平台的设计，它们往往把触发机制、任务依赖、告警规则、权限管理塞在一起，扩展性确实好，但理解成本很高。AX 走的是另一个极端：核心模型只有任务、触发、执行结果三个概念，一切复杂行为都在这三个概念的基础上去叠加。这使得排查问题时的心智负担非常低。

5.3 最后一点建议

如果你也在做类似的调度系统，我的建议是先花两周时间把自己业务里现有任务完整盘点一遍，搞清楚每一类任务对延迟、可靠性、幂等的要求差别，再动手设计。千万不要一开始就把 DAG、分片、动态扩缩容全部塞进去，调度系统的复杂度往往是后面长出来的，不是前期设计出来的。AX 调度从最初只是把 cron 收拢起来的轻量平台，慢慢长出分组隔离、优先级、重试、补签这些能力，每一步都是为了解决实际线上问题才加的，这也是它至今没有变得臃肿的原因。

最后分享一个小技巧，每次发布调度系统新版本之前，手动把任务配置表完整导出一份 JSON 文件放到发布目录里，一旦新版本出现批量问题，可以用最快的速度回滚配置而非依赖数据库备份恢复。这个小习惯已经帮我避免过两次潜在事故，希望对你有用。