1. 先说说我为什么自己写了个调度核心接触过定时任务的人应该都有过这种体会一开始只是几个 cron 表达式在服务器上挂着跑后来任务多了散落在各个服务的代码里状态靠数据库日志看失败靠人工盯。我这次要讲的ax其实就是一个被我不断打磨出来的轻量级调度核心项目。它的代号来自async execution的缩写含义很直白——异步执行调度。而ax调度这个说法是我们团队内部对这套调度核心的统称因为它在我们的体系里已经不只是定时触发这么简单了。这个项目要解决的核心问题是很多中大型系统都会遇到的任务编排混乱、重试不可控、分布式环境下重复执行、依赖关系靠硬编码串联。我最早写它的时候动机很简单就是不想每次新接一个调度需求就跑过去改一个开关、加一个状态字段。后来做着做着发现调度系统这摊水比想象中深触发只是最外层真正麻烦的是状态流转、路由决策、异常兜底和任务之间的依赖编排。如果你也有类似痛点——任务数量上了几百、执行节点从一个变成多个、光是重试和幂等就让你头疼——那这篇分享应该对你有参考价值。我会把 ax 调度核心的设计思路、模块拆解、关键代码逻辑和真实踩坑记录都摊开讲。里面没有高大上的新概念都是成熟做法在不同约束下的取舍。不同基础的读者也能跟上如果你刚接触分布式调度可以从头读理解链路是怎么转起来的如果你已经在维护一套类似系统可以直接跳到第 4 节和第 7 节看问题复盘。2. 触发链路拆解从一条 cron 到任务真正跑起来2.1 调度器不只是到点调一下很多人觉得调度系统就是定时器到点触发任务方法。但真放在生产环境里这个触发动作背后藏着一整条链路时间到点、生成执行实例、判定是否有并发限制、路由到具体执行节点、记录执行状态、处理超时、决定是否需要重试、通知依赖它的下游任务。ax 的核心设计把这条链路分成两层——调度层和执行层。调度层只负责一件事在正确的时间点产生执行意图也就是生成一个 ExecutionRequest。它不关心任务的业务逻辑甚至不关心任务跑在哪台机器上。执行层则负责把 ExecutionRequest 变成真正的执行动作维护运行状态上报心跳和结果。这样拆的好处很明显调度层可以做到无状态方便水平扩展执行层则可以有状态因为任务本身需要上下文。我最早犯的错就是把这两层混在一起。调度器同时跑着触发逻辑又直接执行任务结果一旦任务阻塞后续所有定时触发全被拖住。拆开之后调度节点只干筛任务、出请求、发 MQ 这三件事压力小了一个量级。2.2 触发算法不扫表靠最小堆加时间轮定时触发的第一版实现很多人会选每次扫描数据库找出到期的任务。任务少的时候没毛病但任务量和集群规模上去之后频繁扫全量表会把数据库拖垮。ax 里没有用这种扫表方案而是把所有任务的 nextTriggerTime 放进一个最小堆加上时间轮做精度补充。具体逻辑大致是这样的public class TriggerEngine { private PriorityQueueTaskInstance minHeap; private TimingWheel timeWheel; public void schedule(TaskInstance task) { if (task.getNextTriggerTime() - now() WHEEL_THRESHOLD) { timeWheel.add(task); } else { minHeap.add(task); } } public void tick() { long now System.currentTimeMillis(); while (!minHeap.isEmpty() minHeap.peek().getNextTriggerTime() now) { TaskInstance task minHeap.poll(); dispatch(task); } } }时间轮负责近期的、秒级精度的触发最小堆负责稍远的、分钟级以上的触发。近期触发上限我设的是 30 秒超过这个阈值的任务进堆。触发线程每秒 tick 一次从堆顶取到期的任务再交给后续的判空、路由模块。这套组合的好处是内存里只保留将要触发的任务历史任务不占常驻内存扫描时间从分钟级降到毫秒级。2.3 触发失败与补偿调度层不能丢数据触发链路里最容易翻车的是任务已经从时间轮里取出来了正要生成执行请求的时候进程挂了。如果你只是把任务从队列里拿走再生成请求宕机那一刻任务就丢了。ax 的处理是把取出和生成实例做成两步并且每一步都落库从时间轮到待生成实例集合时先写一条 trigger_log 记录。生成 ExecutionRequest 后更新 trigger_log 状态为 emitted。恢复流程启动后扫描 trigger_log 里所有已取未发的记录做补偿重新生成执行请求。这里幂等的关键是 ExecutionRequest 里带一个唯一 requestId执行层用这个 id 做去重。说白了调度层可以丢的是时间精度不能丢的是执行意图。3. 路由与分片分布式环境下任务到底该由谁来跑3.1 单机时代不需要路由分布式时代路由就是命脉任务要跑的时候面对多个执行节点选择谁来执行就是路由。ax 支持四种路由策略简单随机、加权轮询、一致性哈希、最闲优先。前两种适合无状态任务后两种适合有状态或资源敏感型任务。这四种策略我建议不要做成全局配置而是做成任务级别的属性。因为同一个系统里有的任务耗时 5 秒纯粹算数有的任务跑 20 分钟还要占用大量磁盘 IO。混在一起用同一套路由策略必然有一方吃亏。ax 的任务定义里路由策略是单独一个字段由业务创建任务时指定调度层只负责执行路由算法不解释业务意图。3.2 一致性哈希的实际效果让追随模式成为常态很多调度依赖型任务有个隐含需求任务在哪个节点第一次执行后续尽量还在那个节点执行。比如某个任务要增量同步某台业务库 binlog它得在一个固定的节点上维护游标。这种场景我用一致性哈希来做路由。key 取任务 id哈希环上挂上所有健康执行节点的虚拟节点。一致性哈希的核心收益不是负载均衡而是节点变动时最小化任务迁移。实测下来对一个 500 任务规模的集群如果使用普通取模哈希上线一个新节点会导致约 40%-50% 的任务迁移执行节点一致性哈希加上 128 个虚拟节点后迁移率能压到 10% 左右。当然它也有代价哈希倾斜时负载不均。我的做法是每 5 分钟统计一次节点负载如果偏差超过 20%就对冲突的区间做局部 rehash。3.3 分片任务把一个大任务拆成 N 份并发跑ax 调度还有一个分片模式适用于数据量大的批处理任务。逻辑并不复杂任务定义一个 ShardHandler调度层根据配置的分片数生成多个 ExecutionRequest每个请求携带分片序号和总分片数。public interface ShardHandler { Object process(int shardNo, int totalShards, String taskContext); }分片数怎么定我的建议是不要照着机器核数拍脑袋优先看数据源的带宽和数据量再看执行端的 IO 瓶颈。我们曾经把分片数调到和核心线程数一样结果任务接口被压垮数据库连接池先爆了。后来调整为单分片处理数据耗时在 30 秒左右作为基准根据总数据量反推分片数。如果总数据量不可预估就先执行一个 count 查询再动态决定分片数。4. 状态机与可靠性崩溃、重试、幂等怎么兜底4.1 一个任务实例的一生用状态机管理而不是 if-else执行状态如果散落在代码里后期维护就是灾难。ax 把每个任务实例的状态流转收敛成一个显式的状态机定义PENDING待调度- READY就绪- DISPATCHED已派发- RUNNING执行中- SUCCEEDED成功/ FAILED失败/ TIMEOUT超时/ RETRYING待重试- TERMINATED终态为什么要显式建模一个直接原因分布式环境下状态不是线性推进的可能同时发生执行节点上报成功和调度器判定超时。如果没有状态机约束两段代码各改各的任务状态就会被覆盖。ax 对这类冲突的处理规则是终态一旦写入所有非终态更新一律拒绝。这个规则靠版本号字段实现每次更新都需要带上期望的当前状态。4.2 重试策略不是简单失败再跑一次重试是调度系统最容易做坏的地方。第一层风险是重复执行导致数据重复所以幂等是必须的设计还而不是可选的补充第二层风险是重试风暴——失败任务在短时间内反复重试把下游系统打挂。ax 的重试配置长这样重试次数最多 5 次初始间隔10 秒递推倍数2 倍上限间隔5 分钟也就是说第一次失败后等 10 秒重试第二次失败等 20 秒第三次等 40 秒以此类推封顶 5 分钟。用指数退避比固定间隔合理的多因为大多数瞬时故障网络抖动、连接池暂满在 10 秒到 1 分钟内都能恢复不需要太激进。重试时机也有讲究任务执行不超过 30 秒的重试间隔从 5 秒起步执行时长分钟级的重试间隔至少 30 秒起步否则前一次还没跑完后一次就叠上去了。4.3 幂等三件套requestId 去重、执行锁、一致性裁决分布式调度的重试必须配套三个机制缺一不可唯一业务键每个 ExecutionRequest 生成时带上唯一 requestId执行节点在处理前先查询一次执行记录表如果该 requestId 已经存在且状态是 RUNNING 或终态直接丢弃新的触发。执行锁防止同一任务的多个实例并发执行。ax 的锁是数据库悲观锁加本地短路。任务执行前先select for update锁任务行成功后更新 lastExecAt锁粒度精确到任务级别。一致性裁决调度层超时后不能直接判失败得主动查询执行节点的状态或者等待执行节点的最终上报。我们遇到过最典型的情况任务实际执行成功但结果响应因为网络问题回传超时调度层若直接判失败并重试业务就会重复执行。裁决逻辑是收到超时信号后先做一次状态查询查询无结果才允许重试。这套组合下来重试不再是一个可能搞出脏数据的雷而是一个正常设计的可靠性机制。5. 秒级延迟调度与时间轮的取舍5.1 为什么不用 Quartz 的默认线程池模型如果你用过成熟调度框架可能会觉得直接把定时触发交给现成框架不就行了。我的答案是现成框架解决不了两个问题——高密度触发下的调度延迟以及调度与执行混合导致的任务饥饿。Quartz 默认线程池里跑着 job调度器线程池如果忙触发就会被推迟而 ax 的目标是到点该触发就必须触发不受任务执行时间影响。所以 ax 的触发引擎里没有业务执行逻辑纯粹是时间判断加消息投递。线程模型很简单一个触发器线程负责最小堆的 tick一个时间轮推进线程负责槽位扫描各自独立互不阻塞。调度核心的线程占用控制得很低生产上承载 3000 个常驻任务时触发器线程 CPU 占用率也就是一位数百分比。5.2 时间轮的槽位粒度与溢出策略时间轮我采用的是分级时间轮结构底层 100 个槽位每个槽位代表 100ms上层 60 个槽位每个代表 1 秒。任务插入时间轮时先计算它能落在哪一层逐层降级。这个设计的确不是我自己拍脑袋想出来的参考了业界通用的时间轮实现思路但在槽位存储上做了一点改动每个槽位存的是链表头节点上带着任务的 id 和触发时刻槽位扫描时只负责把到期任务挪到待触发列表不直接执行。时间轮最关键的问题是溢出任务怎么办。ax 的答案是目前强制要求时间轮的覆盖范围至少在 12 小时以上超过这个范围的远期任务回退到最小堆。两个结构的衔接点是每 10 秒从最小堆取一批近期的任务插入时间轮。这个联动逻辑是后期加的早期版本里远期任务和近期任务各管各的结果大量任务压到最小堆里触发延迟飙升到近 1 分钟。5.3 延时任务与定时任务怎么统一很多调度系统面临定时 延时的双轨制问题——定时任务靠 cron 表达式生成实例延时任务比如 30 分钟后回调某接口靠阻塞队列实现。ax 把两者统一了延时任务本质上就是一个没有周期属性的任务触发时间 创建时间 delay。内部用同一个时间轮和最小堆只是任务定义的 cron 字段为空、delay 字段有值。这样省掉了一套延时中间件的维护成本也让延时任务天然拥有了调度层的持久化和重试能力。6. 依赖编排与级联触发让有依赖关系的任务自动跑起来6.1 从手动等上次跑完到DAG 自动触发调度任务多起来之后最烦人的不是单个任务而是任务之间的先后关系。A 任务生成数据B 任务等数据好了才能跑C 任务等 B 完成再聚合。早期我见过不少团队在业务代码里用线程 sleep 轮询前序任务的标志位或者让 A 任务结尾主动调用 B 接口。这两种方式都能跑但都非常脆弱——A 没跑成功 B 就没人触发或者 B 被人改动了触发时间和 A 的衔接就断链了。ax 的级联调度用 DAG 来描述依赖关系。任务定义一个依赖列表每个依赖由上游任务 id 完成状态组成。上游任务进入终态后调度引擎会检查所有下游任务的依赖条件是否全部满足满足则立即生成下游的执行请求。这里我特意选择了事件驱动而不是状态轮询下游任务状态的变化会触发一个 DependCheckEvent由事件处理器统一检查下游依赖。6.2 DAG 环状依赖的检测策略依赖关系必须要防环。ax 的做法是在创建或更新任务依赖时触发一次全量拓扑排序检验。具体操作是对整个依赖图做 DFS如果在访问路径上再次遇到当前路径中的节点就判定有环直接拒绝本次修改。有环的依赖会引发连锁触发、死循环。我们把创建时的环检测和运行时的超时打断都做了。运行时的情况是即使依赖图创建时无环某些任务因为手动干预重跑、强制跳过也可能导致触发链路出现非法循环。所以 ax 在级联触发链路上还加了最大层级限制比如默认 6 层超过就拒绝触发并报警。这个阈值拍脑袋定的话不准最好根据你们实际业务链最长依赖层级再乘以 1.5 作为兜底。6.3 一个真实场景T1 数据任务的级联编排举例来说我们有这么一组数据任务原始数据采集每日 03:00 定时数据清洗依赖采集成功指标计算依赖清洗成功分 4 个分片并发报表推送依赖所有指标计算分片成功在 ax 里配置大概是这样的{ taskId: indicator-compute, cron: , shardCount: 4, dependencies: [ {upstream: data-clean, status: SUCCEEDED} ] }因为指标计算分片是并发执行的报表推送的依赖条件不是一个下游任务完成而是所有分片都完成。ax 的依赖检查会把 shardCount 纳进来只有下游执行请求的所有分片实例都进入终态才认为依赖满足。其实这个语义原本容易踩坑很多调度框架里分片任务的完成是任一分片完成就算导致后续任务提前触发用的还是半截数据。7. 上线半年踩过的坑三个让我改代码的真实事故7.1 事故一任务重复执行根因是调度中心时钟跳变上线后遇到的第一起 P1 事故是某个批处理任务在凌晨重复执行造成下游订单数据被重复修改。当时第一反应是路由或者幂等有问题查了半天发现是调度节点上的系统时钟被 NTP 往前调整了 200 毫秒。因为触发逻辑是nextTriggerTime now时钟往前跳让一批原本还没到时间的任务集体提前触发而每个任务实例因为 requestId 是全新生成的幂等也没兜住时钟跳跃导致的时间窗重叠。修复方案调度节点全部改用单调时钟System.nanoTime 的底层机制来判断是否到点wall clock 只用于落库展示。这之后时钟跳跃再也没引发触发窗口重叠问题。如果你是自建调度系统强烈建议触发判断不要直接用System.currentTimeMillis()对比任务时间差最好用单调时钟计算相对时间。7.2 事故二任务超时判定和实际执行时间严重不符另一个让我头疼的问题是任务超时设置。最开始统一把所有任务的超时时间设成 2 分钟以为很宽裕。结果有个跑数据备份的任务执行到 2 分钟 02 秒的时候被调度层强制判定超时然后走了重试。重试又是一次全新执行旧执行却还在跑。两个任务实例同时写同一个备份目录直接把文件写坏了。这个事故让我彻底改了任务超时的设计原则超时时间不能是全局默认值而必须是任务创建时按最差执行时长指定的对于拿不准的任务宁可设置 30 分钟也不要赌肯定能在 2 分钟内跑完。同时超时阈值设置成任务执行历史 P99 时长的两倍到三倍比拍脑袋合理得多。另外我还加了一条铁律超时任务不能无条件重试如果执行节点反馈任务仍在 RUNNING就只升级告警不触发重试。7.3 事故三级联触发在凌晨的高峰期把自己打崩了第三个印象深刻的问题是级联触发链路在某个大促流量高峰期出现雪崩。一个上游任务完成后1 分钟内触发了 400 多个下游任务这批任务又各自触发下一层导致 MQ 积压调度中心负载飙高连人工干预页面都打不开了。复盘下来根因是没有做级联扇出控制。触发动作本身是异步的生成 ExecutionRequest 很轻量但不代表下游任务不会瞬间产生巨大压力。修复方案是在级联触发链路里加入扇出限制和令牌桶限流同一 DAG 实例里每秒最多新触发 20 个下游任务任务执行节点侧做排队长度监控超过阈值就熔断下游恢复后再继续。说白了调度系统负责把该触发的触发掉但也要保护下游系统不被激增流量淹没。8. 最后说点个人体会调度系统这东西看起来是个不起眼的中间件但它像一根隐形的水管把业务系统里的定时、重试、依赖、并发全部串起来。ax 这套核心在我手上迭代了快两年最大的体会就是调度系统的复杂度不在算法而在对异常场景的完整覆盖。时钟跳变、网络延迟、进程 OOM、节点频繁上下线——这些才是真正考验设计的地方。如果你准备自己动手写一个类似的调度核心我的建议是从小处开始先实现最小堆加时间轮的触发模型再逐步加上路由、状态机、重试、依赖编排。每一步都要想清楚如果这一步挂了会导致什么后果以及下游系统能不能承受最坏情况。别急着上高级特性先把状态机的流转和幂等做扎实这套系统就已经超过很多企业内部的伪调度中心了。最后再分享一个小技巧调度系统上线后别只盯着任务成功率看。把调度延迟 P99、触发抖动次数、重试原因分布这几个指标单独建一张看板你会发现很多隐性故障在爆发之前早就露出苗头了。这个习惯帮我提前排查过三次潜在事故基本上相当于免费送的安全感。