分布式任务调度器AX设计复盘：从crontab到高可用任务编排

凌晨1点47分我被一个电话叫醒凌晨的库存同步任务又没跑第二天早上的促销页面数据全是昨天的。这已经不是第一次了之前大家靠的是在群里值班同事手动重启。挂了电话我翻开写了一半的AX调度器设计文档决定第二天无论如何也要把它推上线。AX是我们内部做的一个分布式任务调度器代号取自最初需求文档的缩写“Attribute and Execute”后来叫着顺口就没再改。如果你最近因为“ax调度”这个词点进来看我先说明白AX不是什么知名开源产品就是我们团队内部自研的一套批处理任务调度系统。这篇文章不打算给它做宣传而是把从需求分析、核心设计、分布式一致性到上线头三周的线上事故原原本本复盘一遍。如果你正在做数据平台的定时任务编排或者被crontab的不可见依赖折磨过这些内容应该能帮你少走几天弯路。1. 为什么会有AX从凌晨1点47分那通电话说起1.1 公司里那套定时任务是怎么把我们拖垮的差不多有两年前我们小组维护着几十条业务线的数据任务最开始的架构极其朴素crontab加shell脚本每台服务器上留着上一位同事写的定时逻辑。系统没崩的时候一切岁月静好真出问题就是“人肉调度”A任务的负责人打电话给B任务的负责人求他把任务提前跑完因为自己的任务依赖他的输出。这种依赖关系完全靠口头传递换个人就断掉了。印象最深的例子是凌晨2点跑的对账任务它依赖1点30分的订单同步任务。只要同步任务延迟半小时对账任务就会准点启动读到的是残缺数据。为了缓解前一位同事在脚本里加了一行sleep 1800让对账任务硬等30分钟。这个“sleep大法”确实解决了表面问题但副作用是没人说得清为什么这个任务要睡半小时。后来任务越来越多两台服务器上部署了同一个脚本导致同一份数据被算了两遍财务对账怎么都对不上。第二个痛点是不可观测。凌晨跑挂的任务不会主动告诉任何人只能等第二天业务方投诉“怎么数据没更新”然后人肉去看日志。每个脚本的错误处理风格还不一样有的往文件里写有的发邮件有的直接吞掉。排查一次问题少则半小时多则一上午。第三个痛点是重复执行和单点故障。同一个任务部署到两台机器上本来是想做高可用结果两个脚本同时开跑下游收到了双份数据。而单机部署的任务只要机器重启或磁盘满那天就没有数据产出。1.2 开源方案不是不行而是离我们的需求差一截动手之前我认真做了一轮选型不是没看过开源项目。市面上能叫上名字的调度框架我基本都写过Demo跑过一轮也整理过一张对比表方案优势在我们场景下的问题crontab / 系统定时器简单零依赖无依赖编排无失败告警无历史记录XXL-JOB调度器和执行器分离支持分片广播操作界面友好依赖编排能力弱做不了复杂的跨任务DAG秒级触发勉强够用AirflowDAG描述能力强生态成熟调度与执行分离部署偏重Python依赖管理麻烦分钟级以下调度延迟偏高K8s CronJob容器化友好跟基础设施集成好依赖编排基本靠外部系统秒级调度和任务重试策略都比较原始选型结论是不是开源项目不行而是它们大多站在这条光谱的两端——要么是“轻量Cron”要么是“重量级工作流”。我们需要的恰恰是中间那一档分钟级、小时级的批量数据任务跨系统依赖要显性化失败要被看见还要有简单的优先级控制。Airflow能做但太重XXL-JOB轻但依赖编排不是它的主场。当时团队刚刚从几个大项目里腾出手技术栈也不统一与其花三周去定制一个庞大框架不如花两周做一个贴合自己业务的小调度器。于是AX立项目标很克制先解决“任务不丢、失败可见、依赖显性”这三件事不做分片不做多租户不做跨机房容灾。1.3 AX要解决的三件事第一件事是任务不能丢。只要任务进入了待调度状态系统就要保证它最终被执行哪怕过程中有节点宕机、数据库抖动也要有恢复机制。第二件事是失败能被看见。每个任务的每次运行都要有记录失败要有重试重试还失败要有告警告警要能找到任务负责人。这听起来是天经地义的但在经历过“失败三天没人发现”之后你会发现很多团队连这点都没做到。第三件事是依赖关系显性化。A跑完才能跑B这个依赖要写在系统里由调度器来等而不是靠人肉协调或sleep大法。任务的上游是谁、下游是谁随时可以查到换人接手时不用靠猜。这三件事听起来简单但真正做起来每一件都牵扯到分布式系统最麻烦的部分状态一致性、幂等、崩溃恢复。下面就从核心模型开始拆。2. AX的核心调度模型把时间、依赖和优先级塞进了一张大表2.1 任务定义和数据模型一张表解决80%的问题AX的数据模型没有整得很花哨核心就是三张表。第一张是任务定义表管“这个任务该怎么跑”字段说明task_id全局唯一IDtask_name任务名业务可读owner负责人告警通知到这个人trigger_typecron时间触发或 event依赖触发cron_expr标准cron表达式如0 2 * * *params任务参数JSON格式priority优先级0-9默认4timeout_seconds单次执行超时时间retry_times最大重试次数statusenabled / disablednext_fire_time下一次触发时间第二张是运行记录表管“这次执行得怎么样”。每次调度都会生成一个全局唯一的execution_id记录里包含任务ID、计划触发时间、实际派发时间、状态、worker节点、开始结束时间、错误信息。execution_id会贯穿整个链路后面排查问题全靠它。第三张是依赖关系表。字段很简单task_id、depends_on_task_id、conditionsuccess 或 failure。这张表决定了一个任务要等哪些前置任务完成。有人可能会问为什么不用标准工作流引擎里常见的ProcessDefinition那一套因为我们的任务模型足够简单每个任务就是一个独立的执行单元依赖关系就是“前置成功才触发自己”不需要子流程、循环、网关那套复杂语义。过度建模是调度器项目最容易犯的错你想把工作流引擎的能力都塞进来最后就会发现自己造了一个跑不动的Airflow。2.2 调度循环数据库时间戳加上内存时间轮调度器的核心是一个每秒循环的goroutine用数据库兜底、用内存加速。我直接贴核心逻辑示意图for { // 1. 从数据库抓未来2秒内该触发的任务最多200个 rows : fetchDueTasks(now.Add(2*time.Second), 200) // 2. 放进内存时间轮时间轮按500ms一格 for _, task : range rows { wheel.AddAt(task.NextFireTime, task) } // 3. 弹出已经到期的任务 due : wheel.PopDue(time.Now()) // 4. 派发给执行器 for _, task : range due { dispatch(task) } time.Sleep(200 * time.Millisecond) }为什么不能纯内存节点重启之后内存里的时间轮数据全丢没有DB里的next_fire_time做兜底重启就会漏任务。为什么不能纯数据库每200毫秒查一次库高峰期会有明显抖动而且DB SQL扫描的延迟不可控。所以设计上各取所长数据库负责保存“下一次触发时间”这个持久状态内存时间轮负责毫秒级的到期判定两者之间有两秒的提前量。这样即使内存时间轮出了故障数据库里的状态也不会丢重启后最坏情况只是任务延迟几秒而不是丢失。时间轮的具体实现没有用复杂的分层时间轮就是一个数组加链表一格500毫秒。对万级任务量来说简单结构反而更稳后续优化空间也大。2.3 依赖触发反向邻接表加等待计数依赖触发是AX相对crontab最核心的升级。实现上我们维护了一张反向依赖表外加一个等待计数表。当一个任务执行成功后会调用调度器的CompleteTask接口这时会做三件事把这个任务标记为success找到所有依赖它的下游任务把对应的waiting_count减1某个下游任务的waiting_count降到0且触发条件满足时把它的next_fire_time置为当前时间进入下一轮派发这里要注意的是condition字段的语义。如果依赖条件是success那就只有前置成功才会减计数如果依赖条件是completed那前置无论成功失败都算“跑完了”。数据任务场景下绝大多数依赖都是success失败要立刻触发下游的失败补偿任务所以condition为failure的依赖也很有用。用反向邻接表而不是每次实时查依赖图是为了避免“查上游”变成N1次查询。任务每次完成只需要查“我影响了谁”这在一张带索引的依赖表上只需要一次SQL。后来任务量涨到两三万这个环节也没有成为瓶颈。2.4 优先级与配额防止一个慢任务堵死全局调度SQL里有一个非常关键的子句ORDER BY priority DESC, next_fire_time ASC。优先级的取值范围是0到9数字越大越优先。这保证了高优先级任务到期时能被先抓取、先派发。但只有优先级还不够。早期我们遇到过一个情况某个业务线把几十个任务全设成9级一下把worker线程池占满了其他业务线的高优任务全部排队。后来给每个任务owner加了一个令牌桶配额每个owner每秒最多消耗一定数量的并发额度超出部分退回下一轮调度。这两条规则加在一起的效果是优先级决定了同一个owner内部谁先跑配额决定了不同owner之间不会互相饿死。3. 分布式下绕不开的三大难题锁、幂等和崩溃恢复3.1 Redis分布式锁为什么被我们换成了数据库乐观锁调度器最怕的事情之一是同一个任务同时被两个调度节点执行。刚开始我们用了最经典的Redis分布式锁方案SET resource_name token EX 30 NX任务到期时先抢锁抢到了才派发。表面上没问题实际跑了两个星期就遇到一个典型的分布式锁坑。第一次出事是锁过期。有一个数据同步任务执行时间超过30秒Redis锁自动释放了另一个调度节点立刻抢到锁又派发了一次。更麻烦的是第一次执行的worker并不知道锁已经失效依然在慢慢跑。两个worker同时处理同一个任务下游消息队列收到了两条。第二次出事是主从切换的情况网络抖动导致持锁节点短暂失联但锁记录还在另一个节点去查询时状态不一致出现了“任务已经被派发但锁记录显示未占用”的假象。后来我们换成了数据库乐观锁。核心就一条update语句UPDATE task_def SET status dispatching, dispatching_worker ?, dispatching_time NOW() WHERE task_id ? AND status pendingaffected rows为1说明抢占成功为0说明被别人抢了直接跳过。这个方案之所以可靠是因为“抢占”和“修改状态”在同一个数据库事务里完成天然具备原子性。代价是数据库的写压力更大但我们用Redis做了一层预筛真正走到数据库状态变更的任务量并不大。Redis负责流量过滤数据库负责最终一致性这个组合一直用到现在。3.2 幂等AX不承诺恰好一次但承诺不重复执行分布式系统里有个经典的说法网络不可靠消息可能丢失也可能重复中间件能做的只有“至少一次”或“最多一次”。AX选择的策略是“至少一次加业务幂等”。为什么这么选数据任务宁可重复跑一遍也不能因为丢消息而不跑——丢一版数据比重复发一封邮件严重得多。实现上每次调度都会生成全局唯一的execution_id插入execution表execution_id上建唯一索引。调度器派发时带着这个ID执行器在执行业务逻辑之前先把execution_id和任务ID写入自己的执行日志表。如果这条ID已经存在说明之前跑过直接放弃。这里有朋友可能要问了数据库唯一索引已经挡了一层为什么还要在进程内做重复判断因为两个消费goroutine可能同时查到了“这条ID不存在”然后同时执行业务逻辑。唯一索引能保证最后只有一条记录但它不阻止业务逻辑被执行两次。所以AX在每个worker进程内部还维护了一个execution_map消费消息前先CAS写入这个mapmap里已存在就直接丢弃。双层幂等之后线上重复执行的问题基本绝迹。这里要给业务方立一个规矩凡是接AX的任务业务逻辑里必须能接受重复入参。我们并不承诺“恰好一次执行”而是承诺“重复执行会尽量被拦截但业务侧也要有兜底”。好在绝大多数数据任务天然具备幂等性同样的SQL重算一遍结果一样。3.3 Worker崩溃之后心跳、检查点和指数退避重投Worker崩溃是所有调度器都必须处理的事故。AX的机制不算复杂每个worker每10秒上报一次心跳心跳记录写入DB调度器里有一个专门的goroutine每秒扫描一次找出超过30秒没心跳的worker把它们标记为dead。标记dead之后接下来要做的事是把该worker名下所有还在running的任务找出来把状态改回pending然后重投。重投之前要处理两个问题一是重投频率二是重投次数上限。重投频率我们采用了指数退避第一次重投隔2分钟第二次隔5分钟第三次隔15分钟超过3次不再自动重投任务进入人工待处理队列告警通知负责人。为什么这样设计如果没有退避一个worker刚崩掉的瞬间调度器会发现100个任务等着重投一轮全部派发出去然后新一轮worker又崩掉再全部派发形成重投风暴。退避机制像是给这个急脾气系统加了一个缓冲垫。还有一个细节是“检查点”。早期实现里重投是把整个任务重新执行一遍。对数据任务来说这没问题但后来有些任务执行到一半已经写了不少数据重投等于重复计算。后来我们引入了一个简单的检查点约定任务执行过程中可以在params里更新一个progress字段重投时从progress继续。执行器配合不配合其实不强求核心是重投之后任务不能处于“永久running”状态必须要么成功要么失败要么回到pending。3.4 时钟偏差调度器最容易忽略的“隐形杀手”写调度器之前我从没想过时钟同步问题会如此恶心。任务触发要依赖next_fire_time now这个判断而“现在”这个时间每台机器看到的都可能不一样。NTP同步不是即时生效的机器负载高的时候时钟抖动个两三秒很常见。我们处理这个问题的方法很朴素调度器在每次循环开始时先执行一条SELECT NOW()拿到数据库时钟计算数据库时间与本机时间差的偏移量bias然后所有到期判断都用now bias来比较。而且我们故意让这个偏差值保守一点比真实偏差略小一点。因为任务晚触发几秒可以接受提前触发会破坏依赖关系——前置任务还没跑完下游就被错误拉起来这是更严重的事故。这个“宁晚勿早”的原则后来也体现在了很多其他细节里比如时间轮到期判断给了一个200毫秒的冗余窗口不追求在毫秒级精确触发追求的是稳定不抖动。4. 上线头三周踩过的四个真实问题附完整排查链路4.1 同一个任务被两个消费进程同时执行了上线第二天晚上业务方反馈收到了两倍的夜间推送消息。第一反应是不是幂等没做住我立刻去查execution表结果发现execution_id只有一条记录说明AX侧的任务生成没有重复。那就说明重复发生在派发或消费环节。继续查worker日志发现同一个执行器节点上两个goroutine几乎同时打印了“dispatch received”日志时间戳相差不到200毫秒。顺着日志里的连接上下文往上追真相浮出水面这台worker在某个时刻与注册中心发生断连随后重连成功但断连前的旧消费者goroutine没有被正常终止两个消费者同时绑定了同一个任务队列于是一份dispatch消息被消费了两次。排查链路完整复盘一遍是这样的查execution表确认execution_id只有一条——排除调度侧生成重复。查worker日志定位到两个消费goroutine同时打印了接收日志——问题在消费侧。查注册中心连接日志确认发生了断连重连旧会话未清理。修复在worker内部加进程级去重map消费前CAS写入同时修复注册中心重连逻辑重连前强制关闭旧消费者。这个教训后来写进了AX的文档分布式系统里重复消费是无处不在的不能指望任何一个环节“肯定不会重复”只能在每一层都加去重保险。4.2 秒级任务延迟从200ms漂移到3秒有一次大促前的容量测试我们发现一批秒级触发任务的调度延迟从平均200毫秒漂移到了3秒左右。按经验第一反应是Full GC但看了监控GC停顿并不严重。那就换个方向查调度循环的耗时。看日志的时候发现fetchDueTasks这个SQL在高峰期执行时间从1毫秒涨到了300多毫秒。原来这条SQL一开始写得太随意JOIN了一张很大的业务表用来过滤某些业务状态。高峰期业务表一增长SQL执行计划就变了走了全表扫描直接拖垮了整个调度循环。修复方案分两步。第一把调度SQL改成只扫描task_def这张小表业务状态关联彻底去掉所有需要业务信息的过滤都放到执行器侧处理。第二在next_fire_time和status这两个字段上建了联合索引同时把“抓取未来2秒”改成“抓取未来5秒”给调度循环留出容错窗口。延迟漂移的另一个来源是写路径和读路径互相争抢数据库连接池。调度器既要读“哪些任务到期”又要写“任务状态更新”高峰期读写都挤在一个连接池里互相拖累。后来把连接池拆成读池和写池问题明显缓解。这个“读写分离连接池”的经验比我想象中重要得多。4.3 一千个任务同时到期数据库连接先被击穿大促前的联测中凌晨00:00有超过一千个任务同时到期。调度器非常高效地把它们全部投递了出去然后执行器就崩了。准确地说是执行器把每个任务都当成一个独立goroutine运行瞬间创建了三千多个并发goroutine每个都在申请数据库连接。我们业务数据库连接池上限是50大量goroutine在等待获取连接部分连接等待超时一批任务卡在running状态再也没有后续。这次事故让我意识到调度器必须做好“背压控制”不能无脑地把所有任务一次性交付给执行器。修复方案上了两级队列调度器只负责把任务投递到一个内部的channel通道执行器用固定大小的worker池消费这个channel当channel积压超过阈值时调度器自动降速减少后续派发。这个改造的本质是把“调度”和“执行”解耦得更彻底。调度侧只关心“有没有到期”执行侧只关心“有没有空闲worker”。中间的channel变成了一个天然的缓冲区和限流器。效果很明显后续再遇到一千个任务同时到期调度器会以每秒50个的速率稳定派发worker永远不会被打爆。4.4 没有监控的第一周失败三天没人知道AX上线第一周线上监控只有“任务完成数”和“任务失败数”两个指标。结果一个数据同步任务连续失败三天没有一个人收到通知。查原因时发现这个任务的执行脚本在内部自己吞掉了异常AX这边看到的是进程正常退出返回码为0所以重试逻辑没有被触发但业务数据实际上已经错了。这次事故之后我把监控指标重新梳理了一遍AX真正跑起来依赖的是下面这几个调度延迟scheduled_time到actual_dispatch_time的差值P99超过2秒就要告警。任务失败率统计周期内失败任务占比超过1%告警。队列积压channel队列长度超过阈值告警。僵尸任务running状态持续超过1小时未结束的任务告警。告警内容必须带execution_id和任务负责人否则告警发出去也没人认领。另外还加了一条“重试吞噬检测”的规则所有重试必须记录日志失败重试后状态置为failed要发告警不允许悄悄吞掉。靠这套监控后来几次小问题都在业务方感知之前就被消灭了。5. AX现在的能力边界和下一步计划5.1 压测数据和真实运行表现AX在单调度节点8核16G后端MySQL 4核8G的配置下实测调度判定能力约为每秒3000次日常稳定调度两万多个任务日调度次数最高到过8万次左右单任务端到端延迟P99维持在1.2秒以内。这个规模离“互联网大厂调度平台”还差得远但对我们的业务体量已经足够。选择在什么规模停下来是一个工程取舍问题。继续堆性能当然可以但当前瓶颈已经不在调度器本身而在下游系统的消费能力。调度器设计得像一个大水管但下游只需要小水杯那真正要优化的就不是水管而是整个任务链路的协作方式。5.2 不敢说自己是个完整产品短板清单AX能跑但我不认为它是一个“完整产品”因为短板非常明确没有真正的分片执行任务粒度还是“整件”大任务要在业务代码里自己拆做不到像XXL-JOB那种分片广播。没有跨机房容灾调度节点是主备结构备机平时只接心跳机房级故障恢复时间要分钟级这是我们不能接受但也暂时没预算解决的。权限模型很粗只有owner字段没有部门粒度的资源授权别人想看某个任务就得有全量权限。不支持自定义日历节假日调度要拼一串cron表达式很蠢也很难维护。动态优先级调整要靠改数据库字段没有一个独立的运营接口。这些短板有些是明确不做有些是当前没排期。写在这里不是为了卖惨而是想如实说清楚一个内部调度器做到什么程度就可以停了后面的工程价值曲线会越来越平。先把核心稳定住比什么都有用。5.3 下一步分片、容灾和任务血缘接下来半年DAX的计划集中在三件事上。第一是支持数据分片新增task_slice表一个任务可以拆成N个分片执行每个分片独立跟踪状态全部执行完才标记整个任务成功。第二是调度状态外置把time轮和“下一次触发”的状态做成版本化存储每次加载时做校验为多节点调度做准备。第三是任务血缘从task_dependency表生成一张上游影响图业务方可以直观看到“我这个任务挂了会影响谁”或者“我的数据来自哪条链路”。第三件事其实是最有价值的因为调度器最终面向的不是机器是人。业务方不关心你的底层状态机怎么流转他只想知道“我的数据是怎么一步步算出来的哪一步出错了”。任务血缘就是把人从“人肉排查”里解放出来的关键。6. 做调度器这几年的体会先稳定再花样百出调度器这种中间件真正难的不是算法是边界。一百个任务和十万个任务用到的原理差不多但工程复杂度是指数上升的。如果让我重做一次我会先把“哪些状态必须由调度器负责哪些该放手给执行器”画清楚再动代码。状态边界理不清后面每加一个功能都在还债。日志里全链路带execution_id这个投入回报率极高。排查线上问题90%的时间花在把散落各处的日志串起来execution_id就是那根线。从调度生成、派发、执行、重试到最终成功失败每一段日志都必须带它少一段都不行。最后分享一个小技巧时间轮不要用单格无限轮询直接sleep到最近一个到期任务的时刻能省大量CPU空转。我第一版就是每秒轮询一次两万任务时还能忍涨到五万任务后“每秒扫描一次”的网络开销和CPU开销彻底成了瓶颈。改成“最短等待唤醒”模式后调度节点的负载直接降了一个量级。AX这个项目到目前为止没有引入任何花哨的算法所有设计都围绕着“别丢任务、让失败可见、让依赖显性”这三条朴素原则。如果你也在做类似的调度器我的建议是先做到这三件事再谈分片、容灾和动态优先级。地基稳了上面盖多高都不慌。