“ax”这名字在我们团队一开始只是随手敲出来的缩写后来叫着叫着就成了内部黑话。如果有人喊一嗓子“ax又挂了”不用问都知道准是那批定时任务没跑出来。这篇就把我们做“ax调度”的全过程整理出来从痛点、架构选型到核心代码、参数调优再到那些不跑一次绝对发现不了的坑一次聊透。1. 先聊聊ax是什么为什么会有这个项目1.1 从一段“崩溃的凌晨操作”说起事情得从三年前的一次线上事故讲起。当时我们系统里跑着将近两千个定时任务清一色是部署在几台机器上的crontab脚本。每天凌晨两点是订单表清理、报表聚合、用户积分结算的高峰期也是运维同事最怕的时间点。某个周一凌晨因为上游数据源延迟一个核心聚合脚本跑挂了但crontab不会自动重试后续依赖它产数的十几个任务全部静默失败。第二天早上业务方看到的数据全是前一天旧值客诉电话直接被打爆。那次事故之后我们统计了一下过去一个季度里因为脚本超时、机器负载、依赖数据未就绪而导致的定时任务失败占总任务执行次数的4.7%。最难受的不是失败本身而是失败没有任何记录全靠第二天业务方反馈才后知后觉。这就是ax项目的起点——我们需要的不是一个简单的cron替代品而是一套能把“任务跑没跑、为什么挂、挂了怎么补救”讲清楚的调度系统。1.2 为什么没直接上现成调度框架当时市面上的调度框架其实不少Quartz、Elastic-Job、XXL-Job我们都有调研过。Quartz胜在轻量但集群模式下靠数据库锁保证调度唯一性任务一多性能就撑不住Elastic-Job的分片模型在当当内部玩得转但我们需要的是更偏向工作流级别的编排而不是单纯的分片执行XXL-Job功能全、上手快但它的调度器和执行器强绑定在Java技术栈里我们团队当时还有一批Python写的算法脚本硬迁成本很高。还有一个很现实的原因调度这件事和业务耦合太深。我们要的不只是“到点触发”还要支持任务依赖A跑完才能跑B、动态延迟数据没就绪就自动往后推、人工重跑只重跑失败的那一天、全局幂等控制同一个任务不能在两台机器上重复执行。这些场景在通用框架里要么不支持要么需要改框架源码。与其在别人的地基上盖楼不如把地基修成我们自己的形状。ax的设计目标从一开始就定得很清楚做一个可以承载复杂业务编排、支持多语言执行器、能自愈的调度平台而不是又一个定时触发工具。1.3 ax的核心定位与能解决的问题ax定位成“分布式任务调度与编排平台”核心能力拆开来看就四块可靠触发到点必须触发不能因为单台机器宕机就漏跑。底层基于数据库租赁时间轮扫描双保险确保任务触发的最终一致性。依赖编排支持DAG有向无环图模型一个任务可以声明“依赖谁”依赖没完成就自动等待而不是像cron那样到点不管三七二十一就跑。执行治理每个执行实例都有状态机等待、调度中、运行中、成功、失败、取消、超时任何状态都能被追踪和人工干预。自愈与补偿失败自动重试重试仍失败就告警告警后支持一键查看日志、一键重跑、一键跳过把“救火”从小时级压缩到分钟级。这套东西做下来最大的感受是调度的本质不是“定时”而是“确定性”。你要能确定任务在什么时机跑、跑在哪台机器上、跑到什么状态、如果失败应该走哪条补偿路径。ax解决的就是这套确定性机制。2. ax调度系统的整体架构与任务模型设计2.1 整体模块划分调度中心、执行器、注册中心ax的架构走的是典型的“中心调度分散执行”模式三个模块各司其职。调度中心scheduler是大脑负责接收任务定义、计算触发时间、下发执行指令、收集执行结果。它是无状态服务可以多节点部署节点之间通过数据库行锁来抢任务保证同一时刻一个任务只有一个节点在负责触发。执行器worker是手脚部署在各业务服务里也可以是独立进程负责接收调度指令并执行真正的业务逻辑。注册中心registry负责执行器动态上下线调度中心通过心跳感知哪些执行器还活着、各自负载如何。为什么不让调度中心直接调用执行器的HTTP接口因为直接接口调用在任务量小的时候最省事但一旦执行器重启、网络抖动调用就断了你根本分不清是任务没触发还是执行了没返回。ax采用的是执行器主动拉取模式调度中心把执行指令写入任务实例表执行器通过长轮询long polling来拉取属于自己的指令。这样即使执行器短暂宕机恢复后还能继续拉取未处理的任务不会因为一次网络闪断就把任务弄丢。2.2 任务模型从Job、Task到Instance的层级拆解最初设计数据模型时我们犯过一个经典错误把“任务定义”和“任务执行”混在一张表里导致要查历史记录变得臃肿不堪。后来参考了工作流引擎的思路拆成了三个概念清晰非常多Job任务定义描述“做什么”包括任务名称、所属应用、执行器类型Java/Python/Shell、回调URL、超时时间、重试策略、触发规则。这是静态配置不会每次执行都复制一份。Task任务节点在Job之上抽象出来的节点概念用于编排依赖。一个DAG由多个Task组成Task可以指向一个Job也可以指向子流程。Instance任务实例描述“某一次具体的执行”是动态数据。每次触发都会生成一条instance记录记录这次执行的触发时间、实际开始时间、结束时间、状态、日志路径、重试次数。所有查询、统计、排障都围绕instance展开。这个三层模型最大的好处是职责单一。Job层面我们可以安全地修改触发规则不影响历史记录Task层面可以灵活编排依赖关系Instance层面则可以放心地写入大量运行数据不用担心把配置表撑爆。2.3 触发器与调度策略的取舍触发器这块我们调研了cron表达式、固定间隔、日历调度三种主流方案最终以cron表达式为主、固定间隔为辅日历调度只作为扩展预留。cron表达式表达能力足够覆盖“每天凌晨2点”“每5分钟”“每月最后一个工作日”这些场景。但cron有一个天然缺陷它描述的是墙钟时间而不是“相对上一个执行点的时间”。举个例子一个任务设为“每5分钟执行一次”如果用cron表达式0 */5 * * * ?在服务器时钟跳到凌晨2点时任务会在2:00、2:05、2:10这样整点触发但如果中间有一次任务执行了8分钟下一个5分钟周期已经错过了cron不会自动补跑。如果改用固定间隔调度就会变成“任务结束后5分钟再触发下一次”虽然不丢周期但触发时间会漂移。最后我们做了个混合策略默认cron触发但允许任务配置“触发后可延迟的最大容忍时间”超过容忍时间就自动跳过这次调度并记录miss同时触发告警。这样既保证了正常场景下触发时间的确定性又不会因为某次慢执行导致任务堆积。3. 核心实现调度器、分配器与执行器3.1 调度器时间轮与扫描补偿机制的取舍调度器的核心职责就是回答一个问题现在有哪些任务的触发时间已经到了第一版我们用的是数据库轮询每隔几秒扫描一次任务表把到期的任务捞出来。这在任务量几百的时候勉强够用但超过五千后数据库压力直线上升扫描一次要几百毫秒高峰期CPU飙到70%。后来我们把方案改成了内存时间轮数据库扫描兜底的双层结构。时间轮timing wheel是把未来一段时间内要触发的任务按秒为刻度放到一个环形数组里调度器只有一个指针每秒跳动一次指向该秒需要触发的任务链表。这比全表扫描高效得多触发的实时性也能达到秒级。但内存时间轮的问题是如果调度器重启内存里的时间轮数据就全丢了。所以每次启动时我们还会从数据库加载未来10分钟内需要触发的任务重新构建时间轮。至于数据库扫描降级为兜底方案每分钟只扫描一次查找那些“应该触发但还没有触发”的任务这在时间轮丢失任务时能自动补触发。两层配合下来的效果正常情况触发延迟控制在1秒内极端情况下调度器频繁重启最多延迟1分钟同时有miss记录可追踪。代码层面的骨架大概是这样class TimingWheel: def __init__(self, tick: int 1, wheel_size: int 3600): self.tick tick # 刻度间隔单位秒 self.wheel_size wheel_size # 环形数组大小 self.slots [deque() for _ in range(wheel_size)] self.current_index 0 def add_task(self, task, delay_seconds: int): # 超过一圈的任务先放到 overflow 集由推动指针时检查 if delay_seconds self.tick * self.wheel_size: self.overflow.append((time.time() delay_seconds, task)) return idx (self.current_index delay_seconds // self.tick) % self.wheel_size self.slots[idx].append(task) def advance(self): 每秒推动一次指针返回当前刻度到期任务 self.current_index (self.current_index 1) % self.wheel_size tasks list(self.slots[self.current_index]) self.slots[self.current_index].clear() # 检查 overflow 中已经到了时间的任务 now time.time() due [t for s, t in self.overflow if s now] self.overflow [(s, t) for s, t in self.overflow if s now] return tasks due需要注意的是时间轮的刻度选择最好和实际触发精度对齐。我们一开始用0.1秒刻度结果时间轮数组太大内存占用反而得不偿失。后来让“秒”做基础刻度毫秒级精度指定成“任务内部逻辑自己控制”实测没有任何场景需要调度器精确到毫秒级。3.2 任务分配与分布式锁怎么避免同一任务被两台机器同时触发分布式调度最怕的就是“重复执行”。两个调度器节点同时扫到了同一个到期任务各自下发指令业务逻辑就被执行两次。第一版我们天真地用了数据库的唯一索引来约束也就是任务实例表里对“job_id 计划触发时间”建唯一键谁先插入谁成功后插入的直接报错跳过。这个方案简单实在但有一个问题单条插入在高并发下会成为性能瓶颈而且MySQL死锁的概率随并发量上升明显。后来我们改成了“先抢锁再插入”的两阶段方案调度器在扫描到期任务时先对任务ID执行一个基于数据库GET_LOCK的分布式锁请求。拿到锁的节点才被允许创建任务实例并主动释放锁没拿到锁的节点直接跳过该任务。为了避免锁超时导致任务漏跑锁持有时间设置为30秒正常情况下创建实例只需要几十毫秒释放很快。如果节点GC卡顿导致锁超时另一个节点会在下一个调度周期重新抢占不会造成永久跳过。这里有个细节分布式锁的超时时间不能设得太短。我们曾经设成5秒结果业务高峰期调度节点发生一次Full GC锁过期任务被另一个节点重复触发。GC本来就是不确定的锁超时至少要给GC留出充分的缓冲时间30秒起步在多数场景下是合理的。宁可让任务晚1分钟触发也不要让任务重复执行这是我们在金融属性业务上踩了坑之后立下的铁律。3.3 执行器与超时、重试、熔断处理执行器相对简单就是目标服务的业务逻辑入口ax通过一个统一的SDK暴露两种接入方式HTTP回调模式调度中心通过任务配置里指定的回调URL把任务实例ID和入参POST过去。适合快速接入、不想引入SDK依赖的团队。SDK内嵌模式服务引入ax-worker包标注AxTask(taskName)调度中心通过RPC或消息队列把指令投递给执行器。适合内部核心服务性能更好还能透传链路追踪ID。不管是哪种方式执行器执行完必须回调调度中心上报状态。考虑到网络抖动我们允许状态上报失败后自动重试三次每次间隔2秒、4秒、8秒指数退避。调度中心则有一个“超时判定”机制任务配置了超时时间比如默认300秒执行器一直没有上报完成调度中心就主动标记为“执行超时”并触发重试策略或者告警。超时的判定不能只靠执行器在业务代码里自己判断因为业务代码可能已经假死或阻塞在线程池里根本执行不到超时逻辑。调度中心必须在自己的角度维护一个“心跳表”执行器每30秒上报一次心跳超过90秒没有心跳就认为执行节点失联将该任务标记为失败并转移给其他健康节点执行。这套机制在真实场景下遇到过一个大坑某个批次处理业务在数据库锁等待时整个线程池全部阻塞所有任务心跳全部停止ax把所有任务都误判为“节点失联”疯狂的转移重试把另一组机器也打挂了。这个问题的根本解法不是优化心跳而是限制单个执行节点的任务并发数让线程池永远有空闲线程处理心跳上报。后来我们在执行器侧加了信号量控制默认每台worker同时执行的任务数不超过CPU核心数的两倍心跳线程单独走一个固定线程池才彻底解决了误判问题。4. 关键参数怎么定一次压测与调优实录4.1 线程池参数的确定从“拍脑袋”到压测数据说话执行器侧线程池参数如果乱配一定会出问题。我们第一版给worker配的是corePoolSize16, maxPoolSize32, queueCapacity2000看起来挺标准压测直接翻车。当时模拟了3000个任务同时下发给一台8核16G的worker结果内存直接打满任务处理速度越来越慢直到线程池拒绝策略生效。后来分析发现queueCapacity2000意味着有2000个任务实例在内存里排队每个实例自带入参、日志句柄、上下文对象一个实例平均占用80KB光排队任务就吃掉了160MB内存再加上线程栈内存16G机器根本扛不住。压测之后我们把参数调成了corePoolSize8, maxPoolSize16, queueCapacity256同时增加了“执行器最大并发数”的全局开关默认并发执行中任务数不超过12个。配合队列容量限制超过并发阈值的任务由调度中心缓存在分布式任务表里而不是堆在worker内存里。调整之后单台worker稳定处理量从每秒20个提升到了每秒85个内存占用从峰值90%降到40%。4.2 重试间隔与退避算法不是所有失败都值得立刻重试ax的重试策略支持固定间隔和指数退避两种模式。刚开始图省事全部统一用固定间隔5秒重试3次。但很快发现一个典型场景一个任务依赖外部数据源数据源凌晨3点到4点做维护任务一旦失败重试基本等于白试因为每次都会在同样位置失败白白消耗资源还会让数据源压力更大。指数退避更合理第一次失败后隔10秒重试第二次失败后隔30秒第三次失败后隔2分钟。但这个间隔上限一定要控制住否则后续依赖的任务会一直等待。我们最终把重试上限设为5次每次退避时间10秒、30秒、2分钟、5分钟、10分钟同时支持任务配置“失败后的延迟重试窗口”比如“2点失败后允许在2点到6点之间每隔半小时重试一次”。这样的好处是既给了任务足够的恢复时间又不会无限拖延依赖链路。4.3 数据清理与任务积压的边界任务实例表是增长最快的表一天几十万条记录很正常。如果不清理半年后查询性能直线下降。但清理是个双刃剑——清理太激进排障时找不到历史日志不清理库表越来越大。我们按“热数据3天温数据15天冷数据3个月”的分级存储策略3天内的instance数据全部在在线库支持任意字段检索。3天到15天的数据按天分表支持按任务ID和时间范围查询。15天以上的数据归档到分析库只保留状态、耗时、错误码摘要等核心字段原始日志不再保留。清理任务本身也用ax调度每天凌晨自动执行。这里有个经验数据清理任务一定要加“当前积压量的水位线”逻辑。比如清理任务启动前先查一下在线库的instance总量如果超过阈值比如1亿条就分批次循环删除每次删除5万条后休眠1秒避免长时间锁表把业务写操作堵死。5. 常见问题与排查技巧实录5.1 问题速查表先看状态机再翻日志ax上线后我整理了下面这张排查表团队排障效率提升非常明显现象可能原因排查步骤常见解决方案任务到点没触发调度器节点宕机、时间轮丢失、cron表达式写错查instance表是否有应生成记录查调度器心跳日志手动触发一次检查任务是否被并发锁卡住确认时间轮补偿扫描已开启任务一直显示“运行中”但不结束业务代码阻塞、线程池耗尽、回调地址不可达查执行器线程栈确认任务所在线程是否BLOCKED查心跳是否正常人工标记失败并重跑优化业务SQL添加心跳兜底转移任务重复执行分布式锁超时、上次执行结果未被正确记录、回调接收端丢失确认查同一job_id计划时间是否有两条instance调整锁超时时间检查回调幂等实现确保上报状态使用相同trace_id高峰期间任务大面积延迟调度器短板、worker并发数打满、数据库锁竞争查调度器平均调度耗时查worker活跃线程数查数据库慢查询扩容worker调低单worker全局并发数优化调度器分批拉取SQL重试后仍然失败且失败内容都一样依赖的外部数据或接口未恢复、失败点在调用前端未进入业务看错误摘要是否一致复现一次入参执行关闭自动重试改人工介入调整失败重试窗口避开故障时间5.2 “看起来很稳但其实要挂”的几个坑挑三个印象最深的讲。第一是调度中心节点的时钟漂移。ax的触发计算依赖服务器本地时间如果某台调度器的系统时钟和NTP服务器差了几分钟它负责的任务就可能提前或延后触发。我们从线上抓到一个案例一台测试环境误入了生产集群时钟慢了2分钟导致一项2:00触发的任务在1:58就跑了。后面所有调度相关节点都强制开启了时间同步监控偏差超过1秒就把节点摘除。第二是日志太多把磁盘打满。执行器在DEBUG级别下每个任务光日志就几十MB一周就能打满一块40G的数据盘。ax默认把执行日志写到独立的数据目录并在执行器侧加了日志保留策略最多保留7天、单文件最大200MB。此外调度中心下发任务指令前会检查执行器所在节点的磁盘剩余空间低于2GB就暂时不下发新任务磁盘满导致的全量任务连环失败这个坑算是彻底堵上了。第三是任务依赖成环没有校验。DAG编排上线时我们第一次允许用户自由配置“依赖哪些任务”结果有人配置了一个环A依赖BB依赖A。两个任务互相等待永远无法触发。后来在保存DAG拓扑时强制做了一次环检测发现环直接拒绝保存并提示哪两个任务成环。代码逻辑其实就是DFS加状态标记几十行的事但没做之前排障能排到怀疑人生。5.3 监控与可观测性的落地经验最后说下可观测性。ax本身是调度系统它的可观测性和业务系统的指标不完全一样。我们围绕三个核心指标建监控大盘调度延迟从计划触发时间到实际触发时间的差值P99超过5秒就要告警。这个指标直接反映调度器的健康程度。执行失败率按任务ID、执行器节点、小时维度计算失败率。某个任务失败率突然从0.1%涨到5%大概率是业务代码或依赖服务出问题了。排队积压量当前处于等待状态的instance数量。如果积压量持续上涨说明下游消费能力跟不上需要扩容或者优化任务拆分逻辑。还有一个容易被忽视的点调度系统的告警自身也要有兜底。我们把ax的告警通道连了多个渠道钉钉、短信、电话但有一次是告警服务本身挂了直到业务方反馈我们才发现。后来调度中心每5分钟会生成一条心跳指标如果连这种基础指标都没了监控系统自己也会拉响“告警链路中断”的警报。这个细节看起来不起眼出事的时候能救命。我个人在实际操作中的体会是调度系统的价值往往在半年后才真正体现。刚上线时你觉得不就是一个触发工具吗但等到你面对几千个任务、几百条依赖链路、每天半夜还能安心睡觉的时候才会意识到“确定性”这三个字有多值钱。如果你也正在考虑搭建类似的东西无论规模大小第一版一定要把任务状态机、失败可观测、人工补跑这三个基础设施做扎实这三块后面再补的代价会非常大。还有一个小技巧调度系统上线前最好提前准备一份故障演练脚本模拟调度中心宕机、执行器断网、数据库锁等待三种场景把应对流程走一遍等真出事的时候你会感谢当时的自己。