做了好几年批量任务和实时调度的系统我一直觉得“调度”这个词被低估了。很多人一听到任务调度第一反应就是“定时跑一下脚本”但真等你的业务量上来任务之间有关系、有优先级、有重试策略、有资源上限你就会发现调度其实是一个分布式系统里最容易被低估的模块。今天我们聊的这套系统内部代号叫 AX后来大家顺口就叫它“AX 调度”。A 代表 AsyncX 代表可扩展的调度策略它要解决的就是资源有限、任务量大、依赖关系复杂的时候怎么把每一批任务安排得明明白白。这套东西不是从一个正式立项开始的。最开始只是一段处理异步消息的脚本后来发现业务方这个概念太大于是做了独立服务。整个演进过程里踩过不少坑也重构过好几轮所以这篇内容适合正在设计或维护任务调度平台的后端工程师、架构师以及刚接触分布式任务但又不想一上来就堆重量级框架的同学。看完你能知道一套调度系统从 0 到 1 需要想清楚哪些事哪些设计决定了它是能平稳跑三年还是上线一个月就被人吐槽。1. 为什么需要一套专门的调度系统1.1 传统定时的局限我最早接触调度是拿系统的 crontab 直接写后来用 Quartz再后来有一段时间直接用开源任务调度平台。说实话在任务量不大、执行时间相对固定的阶段这些方案都够用。但一旦进入下面这几种场景问题就出来了:任务数量指数级上涨每天上千万个执行单元单个数据库里存任务表压力巨大。任务之间有依赖一个任务要等上游跑完才能触发纯靠定时轮询非常浪费。不同任务对时效性的要求不同有的 10 秒内必须跑有的延迟半小时也能忍但如果你全部按固定优先级排队高优任务会被低优任务堵住。执行节点分布在多台机器上失败重试、节点宕机恢复、任务幂等这些事都得自己处理。我举个真实例子。我们之前有个业务白天高峰期会动态产生一批分片任务每个分片要查不同的数据区间然后汇总结果。任务总数不算夸张单次也就几万个分片但有个特点突发性极强早上 9 点到 11 点之间集中创建。如果按传统的方式每分钟扫描一次待执行表到点把所有任务都捞出来丢给线程池瞬时负载很容易把数据库和业务接口一起打崩。更麻烦的是任务的分片大小还是动态的有的执行 10 秒有的执行 5 分钟如果调度模块不做调度语义只顾着盲目分发一定会出现某些节点忙死、某些节点闲死的情况。1.2 AX 调度要解决的核心问题所以做这套系统的时候我给自己定了几个目标这几个目标后来也成了整个架构设计的判断标准第一任务与执行分离。调度中心只负责任务状态管理、时间触发、依赖判断和分发策略不负责业务逻辑和执行。业务方只需要注册任务类型和处理回调执行器可以部署在任意节点上。第二优先级可控。调度队列必须支持多级优先级并且要有“插队”和“降级”机制。高优任务来了不能排队等太久低优任务也不能因为长期被高优挤压而饿死。第三状态机清晰可靠。一个任务从创建、等待、就绪、执行、失败、重试、成功、过期这些状态必须有明确的流转规则并且能把状态变更持久化进程挂了也能恢复。第四可观测。调度系统是典型的需要“出事能查”的系统。一个任务为什么没跑、为什么跑了三次、为什么卡在等待依赖这些问题必须能够在排查时快速定位。AX 调度这个项目就是围绕这四个目标展开的后面的所有设计和踩坑记录也都跟这四点相关。2. 核心设计思路与技术选型2.1 异步模型与事件驱动调度系统最怕的事是什么是“轮询”。很多早期的调度框架都是靠轮询数据库来发现到期任务比如定时任务表里的 next_run_time 小于当前时间就把这一批捞出来。任务量小的时候没问题任务量一大轮询频率太高会导致数据库压力上升频率太低则会让任务错过触发时间。AX 在设计上改成了事件驱动加准轮询的混合模式。对于定时任务维护一个内存中的时间轮每个业务周期直接触发检查逻辑对于依赖触发的任务则通过事件通知机制上游任务完成之后发送一条事件调度中心收到事件后检查下游任务的依赖条件条件满足就直接入队。可能有人会问时间轮也会丢事件进程重启了怎么办所以实现上是两层。内存时间轮只负责把到点任务的 ID 捞出来真正的任务状态判断和入队动作还是走数据库和消息队列。整个过程可以类比成订闹钟闹钟响了不代表你就起床穿衣完毕了只是提醒你该开始行动了。这个“提醒”层面用内存做准确且低延迟而“行动”层面用持久化存储做可靠且可恢复。2.2 存储选型与状态机设计任务的存储我见过很多方案有用纯内存的有用 MongoDB 的也有直接怼在 MySQL 里的。AX 最终选的是 MySQL 加 Redis 的组合MySQL 存任务元数据和状态流转日志Redis 承担队列和实时计数。任务状态机的设计是这套系统的地基我把它画成了非常清楚的几个节点实际演进过程中几乎没改过创建任务刚被业务方提交还没进入调度判断。等待任务有依赖条件依赖不满足时状态保持为等待。就绪依赖满足或时间已到任务可以被派发。执行中调度中心已经把任务派发给某个执行器节点等待执行器回报结果。成功执行器返回成功任务生命周期正常结束。失败执行器返回失败进入重试判断。重试中已经进入重试逻辑等待下一次派发。取消业务主动取消或者依赖链上有任务被取消后级联取消。过期任务达到了最长等待时间直接标记为失败。这个状态机看着简单但真正常踩坑的地方在“等待”“就绪”“执行中”这三个状态之间的转换。等待到就绪是依赖检查触发的就绪到执行中是调度线程触发的执行中到成功或失败是回调接口触发的。只要这三个转换之间线程不安全或者数据库更新语句写错条件就会出现同一个任务被派发两次、或者任务永远卡在就绪不执行的问题。关于状态转换有一个关键点必须提一下任何状态变更的 SQL 都必须带上“当前状态”作为条件。比如把任务从等待改成就绪SQL 的 where 条件里一定带着 statuswaiting如果更新影响行数为 0说明状态已经被其他线程改了当前线程就不能再继续后面的派发动作。这个操作方式看似不起眼却是避免重复调度最重要的一道防线。2.3 队列与优先级实现任务就绪之后不是立刻被派发的而是进入一个待派发队列。这个队列的设计决定了调度系统的高峰能力。AX 里用的是基于 Redis 的延迟队列加多级优先队列。延迟队列负责处理“定时等待”的任务score 用任务的期望调度时间戳。比如一个任务希望下午 3 点执行初始化时就把它塞进延时队列score 设为 15:00 对应的时间戳。调度线程每 500 毫秒扫一次队首如果队首的 score 已经小于当前时间就把这批任务挪到就绪池。就绪池里再按优先级分成多个队列比如 P0 到 P5一共六级。P0 是最高优先级一般用于线上实时性要求极高的任务P5 是最低优先级用于离线批量任务。派发线程每次取任务的时候先看 P0 队列P0 空了再看 P1以此类推。这里有个需要注意的坑如果某个高优先级类型的任务量一直很大P5 的任务可能永远取不到我们叫“饿死”。AX 的解法是带权重的轮转调度不是严格按优先级顺序取完一个队列再取下一个而是按权重分配派发比例。比如 P0 权重 40%P1 权重 25%P2 权重 15%以此类推每个派发窗口内按比例取任务。这样既保证了高优任务的低延迟又让低优任务不会完全饿死。3. 关键机制与代码落地3.1 调度主流程的骨架AX 调度主流程其实不复杂核心就是一个循环每一轮做四件事加载到期任务、检查依赖、按优先级入队、派发给执行器。我拿一段简化代码来展示这个逻辑骨架import time from ax.scheduler import task_storage from ax.scheduler import dependency_checker from ax.scheduler import dispatcher def run_schedule_loop(): while True: # 1. 从时间轮和延迟队列中取出到期的任务ID due_task_ids task_storage.fetch_due_task_ids(nowtime.time()) for task_id in due_task_ids: # 2. 幂等加锁防止多个调度线程处理同一个任务 if not task_storage.lock_task(task_id): continue task task_storage.get_task(task_id) # 3. 检查依赖是否满足 if not dependency_checker.is_ready(task): task_storage.update_status(task_id, waiting) continue # 4. 更新状态并入队 task_storage.update_status(task_id, queued) dispatcher.push_to_ready_queue(task) # 5. 把就绪队列中的任务按优先级派发出去 dispatcher.dispatch_ready_tasks() time.sleep(0.5)这一段只是示意真实实现要复杂得多但核心逻辑没变。有个问题在代码里不明显但实际运行时会暴露出来fetch_due_task_ids 这一步如果一次取太多任务内存里会堆积大量任务对象如果一次取太少高吞吐下轮询次数会很频繁。我们最开始用的是每次取 1000 个后来发现调度延迟忽高忽低原因是某一次任务量特别大1000 个不够还要再查一次数据库多出来的时间就让延迟变大了。后来改成动态容量根据队列的积压长度每次取 min(当前积压量, 5000) 个任务效果明显改善。3.2 派发策略与执行器负载均衡派发这个动作说白了就是把就绪任务分配到具体的执行节点上去。这个过程要考虑两个问题一是任务类型是否匹配节点能力二是节点的当前负载。AX 给每个执行器节点设置了标签 capability比如有些节点可以执行 GPU 类型的任务有些节点只能跑普通 CPU 任务。任务本身也有 required_capability 字段。调度中心在做派发决策时先过滤具备对应能力的节点再根据负载打分。负载评分不能只看节点上的任务数量因为任务有大有小。我们采用的方法是滑动窗口内的累计预估耗时每个任务在执行之前会带上一个 estimated_cost比如 300 毫秒或 2 秒。节点在注册心跳时会汇报当前积压的预估耗时总和调度中心把新任务派给预估耗时最低的节点。这块有一个典型的反例只看任务数量不看成本。刚开始跑的时候某个节点只被派了一个大任务另一个节点被派了五十个小任务结果这两个节点的实际负载完全反过来了。大任务跑得慢小任务跑得快但只看数量大任务所在的节点显得很空闲下一轮又被塞了新任务最终这台节点卡到业务超时。所以说调度系统里的“负载”最好是预估成本而不是任务个数。3.3 超时与重试机制任务派发出去之后调度中心并不是什么都不管了。执行器节点可能宕机网络可能抖动业务代码可能抛异常这些都会导致任务没有在预期时间内完成。AX 的做法是三层超时控制第一层是执行超时。每个任务有一个 timeout 字段执行器本地也有一个兜底超时防止外界没限制时任务永远占用线程资源。第二层是派发超时。任务从派发到执行器开始执行之间有一个 dispatch_timeout比如 60 秒。如果执行器拿了任务但迟迟没开始执行调度中心会把任务重新标记为就绪重新派发一次。第三层是总体超时。一个任务从进入就绪态开始到最终完成有一个总的时间预算超过这个预算直接按失败处理。重试策略上AX 支持指数退避加抖动。首次失败后等 5 秒重试第二次失败后等 25 秒重试第三次失败后等 125 秒依此类推同时每次重试间隔加入随机抖动避免多个任务同一时间点集体重试造成的“重试风暴”。重试风暴这个问题我用一个案例来说曾经有一个上游数据源短暂宕机导致 3000 个任务同时失败。由于当时的重试策略是固定 10 秒后重试结果 10 秒之后 3000 个任务又一次全部启动又把下游 API 打爆了。后来改成随机抖动之后重试任务在一个时间窗口内均匀散开下游压力减了不止一个量级。3.4 幂等与分布式锁调度系统是天然有重复执行风险的因为网络是不可靠的。执行器完成任务后返回结果给调度中心这条返回可能丢了调度中心就会认为执行失败触发重试于是同一个任务被执行两次。A 方案是把重试次数设小B 方案是执行器侧做幂等。AX 两件事都做了。调度侧每个任务实例有全局唯一的 execution_id每次派发生成一个新的 ID执行器侧在执行业务逻辑之前会先检查这个 execution_id 是否已经执行过。检查方式有两种一种是在业务库里记录执行幂等表另一种是采用 Redis 做短时间内的去重。这里我想重点说一个问题分布式锁不能只靠 Redis 的 SETNX因为锁会有过期时间任务执行时间如果超过锁过期时间锁就会自动失效另外的线程就可能进来抢到同一把锁。AX 的处理是任务的锁状态不只是 Redis 里一个 key而是同时记录在任务状态字段里并且锁更新用的是状态机的条件更新。只有当前状态为就绪或等待的任务才能被线程抢到执行权。即使 Redis 里的 key 意外过期数据库状态仍然能拦截重复派发。4. 部署与配置实操4.1 整体部署结构AX 部署的时候分成三个角色跟多点单点的关系是这样的:调度节点可以部署多个实例但同一时刻只有一个实例作为主调度者其余作为备选。主备切换通过选举机制完成。这个角色主要干的是时间轮扫描、依赖检查、队列派发。执行节点业务节点跑具体的业务任务代码数量可以按业务量横向扩展。存储层MySQL 存任务元数据和事件流水Redis 存队列和实时状态使用主从加哨兵保证高可用。调度节点虽然是单主模式但它本身不执行任务所以单主的性能压力并不大。真正支撑高吞吐的是执行节点横向扩展。4.2 关键配置参数参考我分享一套实际生产中比较稳定的配置你可以参考但要根据自己系统的任务量和机器情况调整。调度线程的扫描周期是 500 毫秒每次扫描最大任务数是 5000 个。派发线程有四个并发每个派发线程一次最多派发 200 个任务给执行节点。MySQL 这边任务表按任务 ID 分表一共分了 128 张表。每张表的 task 表只存元数据内容不长单条记录大概 500 字节以内所以单表数据量在几百万也不会有什么性能问题。执行日志单独存一张表按日期分区超过 30 天的分区自动删除。Redis 这边就绪队列的 key 按优先级分成六组分别是 ax:ready:p0 到 ax:ready:p5。执行中的任务 ID 统一维护在 ax:executing 这个 Hash 里字段是 task_id值是 execution_id。延迟队列用 Redis ZSetkey 为 ax:delayscore 为期望执行时间戳。这里有一个小而关键的配置Redis 连接池的最大连接数。调度系统对 Redis 的操作频率是很高的一个时刻可能同时有几百个线程在读写队列。默认的 50 连接池大小肯定不够我们调到 300 之后才算够用。如果你发现调度延迟不稳定先看一下 Redis 连接池连接等待的耗时这经常是隐藏瓶颈。4.3 日常运维与监控指标调度系统的监控指标我建议重点盯这几个调度延迟任务从就绪状态到被派发出去的时长。这个指标最能反映调度中心本身的性能。队列积压量每个优先级队列中待派发的任务数量。积压量上涨说明执行节点处理能力不足或者派发逻辑出了问题。执行成功率与重试率重试率高不一定是坏事但突然上涨大概率是业务代码或下游依赖出了问题。调度节点的心跳主调度节点的心跳过期后多久能完成主备切换这个时间决定了调度系统的最长不可用时长。监控告警我放在了 Grafana 里主要看两条曲线一条是所有队列积压量的总额另一条是 P0 任务的调度延迟。这两条线只要出现明显尖峰基本第一时间就能感知到异常。日常运维还有一个容易被忽略的细节历史任务数据的清理。如果你只删任务表不删执行日志表和事件流水表磁盘很快就会被打满。事件流水表增长尤其快每个任务从创建到结束至少产生三到五条事件记录。如果按 30 天保留建议事件流水表定期打包归档到冷存储不要直接 insert 到同一个库里面拖累主库性能。5. 生产环境常见问题与排查实录5.1 任务大面积堆积怎么办有一段时间我们碰到过一次非常诡异的任务堆积。业务那边反馈说任务提交了但迟迟没有开始执行。调度中心自己的监控数据显示队列积压量快速上涨但执行节点上明显没有新增任务在执行。排查过程是这样的先看调度线程日志发现 fetch_due_task_ids 返回的数据量异常大每次能取出几千个任务。但派发的时候速度跟不上。原因是那段时间某几个大任务把 execute 线程池占满了新的任务虽然被派发到了执行节点但执行节点的线程池没有空闲线程可以接手。这种问题不是调度系统自身的 bug而是执行节点的资源规划问题。后来我们把执行节点的线程池分成两个组一个是常规任务池一个是高优任务池。高优任务池的线程数虽然少但优先级高确保紧急任务始终能抢占执行。同时给执行节点加了线程池活跃度的监控活跃度超过 80% 就告警。这样执行节点在扛不住的时候我们能提前发现而不是等任务全部堆积了才反应。5.2 同一个任务为什么被执行了两次重复执行是调度系统最严重的正确性问题我们遇到过两次一次是锁过期导致一次是回调超时导致。锁过期那次的场景是某个任务执行业务逻辑花了 40 分钟而它对应 Redis 的锁过期时间只设置了 30 分钟。锁过期之后调度中心认为这个任务还没人执行就重新派发了一次。但任务本身还在跑于是同一份数据被处理了两遍。修复的方法有两层。第一层是把锁的过期时间调成任务执行超时时间再加上一个缓冲比如任务超时是 30 分钟锁就是 40 分钟。第二层更重要就是前面提到的数据库状态机条件更新即使 Redis 过期数据库里的状态仍然是执行中其他线程无法把状态改回就绪。这两个机制一起作用之后重复执行的坑就再也没有踩过了。回调超时导致重复执行是另一种路径。执行器执行完后回调调度中心结果网络抖动回调丢了调度中心等了一段时间没收到回执就认为执行超时重新派发。这次我们不是在调度侧修复而是建议业务方在执行器里记录 execution_id 并可查询发现新派发的 execution_id 和旧的不同可以直接拒绝新任务并返回成功状态。这个方案执行器侧要做一点改造但能从根本上防住网络层面的重复。5.3 重试风暴怎么治重试风暴的症状前面提过就是大量失败任务在同一时刻集体重试瞬间打爆下游系统。第一次遇到的时候我们的处理方案很粗暴手动在配置中心把重试开关关掉停止所有重试任务等下游恢复了再打开。这个操作对临时止血有效但不能作为常态。后续我们做了两个改进。第一个是重试窗口化把指数退避的间隔分成多个时间窗口每个窗口内最多只能有 N 个任务进入重试。比如第一窗口 5 秒内最多重试 100 个任务第二窗口 25 秒内最多重试 200 个任务以此类推。超出的任务顺延到下一个窗口。第二个是给重试队列单独设置一道熔断闸门当下游系统的错误率超过阈值时重试队列暂停派发直到错误率恢复正常。这两个能力合在一起才把重试风暴的问题真正解决掉。5.4 任务状态卡在等待依赖状态卡在“等待”也是一个高频问题。上游任务已经成功了但下游任务就是不动。到最后发现原因往往是事件消息丢了。上游完成后发送了一条事件消息但调度中心当时正在重启或者网络分区消息没有被消费到。由于依赖检查逻辑是只有收到事件才触发于是下游任务永远等待。修复方案是增加一个兜底扫描逻辑每个等待中的任务记录一个“最早允许执行时间”依赖条件满足之后还要有一个依赖超时时间。超过依赖超时时间后调度中心每隔一段时间做一次全量依赖检查把漏掉的事件重新补上。虽然全量检查有点重但这个兜底逻辑保证了事件丢失时系统仍然能自愈不会出现僵尸任务。6. 踩坑之后的改进与经验沉淀6.1 时间轮内存必须定期校准时间轮的实现我们走了简化路线把需要定时触发的任务放到一个最小堆里每次取出堆顶判断时间是否到了。这个方案本身问题不大但有一个隐患如果调度节点本身宕机内存堆里的定时任务就都丢了。虽然在主备切换之后从数据库里还能捞回任务、重新初始化时间轮但初始化过程中如果任务量大从数据库全量捞一遍耗时可能非常长。后来我们做了增量恢复。数据库里记录每个任务的上次调度时间重启之后只加载当前时间之后 5 分钟内需要调度的任务更远的任务等时间快到的时候再从数据库加载。这样既保证了时效性又减少了初始化压力。6.2 动态分片任务支持AX 发展下来有一个比较特殊的能力就是动态分片。有些任务是分片执行的任务提交的时候并不知道总分片数需要先跑一个分片计算逻辑然后根据计算结果动态地把任务拆成多个子任务。这个场景用静态任务模型处理不了。我们在任务描述里增加了一个 shardable 标记调度中心遇到这类任务时先派发一个“分片计算任务”计算完成后把生成的分片列表注册到任务表再按分片 ID 逐个派发执行。分片任务之间还支持配置依赖关系比如所有分片都必须完成后才能进入汇总阶段。这个能力让调度系统从一个单纯的定时工具变成了一个能编排复杂业务流的执行框架。如果你也有分片任务的需求我建议在设计任务表时就把 shard_id 字段预留出来并建立联合索引。我们最初没有预留后来业务方提需求时已经积累了大量存量数据为了加字段和索引做了好几轮迁移相当折腾。6.3 调度系统的容量规划公式最后分享一个容量规划的估算公式这是我摸着石头过河总结出来的不一定精确但很好用。假设每秒钟新产生的任务数是 S每个任务从创建到完成的平均等待时间是 T_wait那么系统中积压的任务量大约就是 S 乘以 T_wait。如果 T_wait 为 10 秒每秒新任务 5000 个那么积压任务就是 50000 个。执行节点处理一个任务平均耗时是 T_exec那么要支撑这个吞吐至少需要的并发执行能力就是 S 乘以 T_exec。如果 S 是 5000T_exec 是 0.5 秒那么并发执行至少要 2500 个线程/协程。如果一台执行节点可以同时跑 200 个任务那你至少要准备 13 台执行节点。这个公式帮助我们在扩容时有了明确的依据而不是凭感觉加机器。实际情况中还要考虑波峰系数一般留 30% 到 50% 的余量才不会被偶发的流量尖峰直接打穿。做调度系统这件事我最大的感受是它不像某些业务功能上线就能看到成果但它是整个系统稳定性的底盘。调度一旦出问题所有依赖它的业务都会一起遭殃。如果你也在设计类似的调度系统建议先把状态机和幂等设计想清楚再考虑性能和扩展性顺序反了很容易后面不断还债。以上这些都是我在实际项目中踩过坑之后沉淀下来的经验希望你用不上但真遇到了能有个排查方向。