“ax”这个代号最早是我在内部项目里随手起的结果叫着叫着就改不过来了。说白了ax就是一个我自己写的调度引擎解决的是微服务体系里最烦的那类问题几百个定时任务、事件触发任务、人工补偿任务混在一起谁先跑、谁后跑、资源不够时先砍谁。最近“ax调度”这个说法在一些技术群里慢慢传开其实就是指这套任务编排和资源分配的内核。这篇不聊高大上的架构只讲讲我做这套东西时踩过的坑以及如果你是新手怎么把“ax调度”的核心思路落到自己的项目里。如果你现在还在用 crontab 加一堆 shell 脚本或者人工盯数据库定时扫表那你一定体会过“凌晨三点任务挂了没人管”的酸爽。ax调度不是为了替代某个成熟的调度框架而是把“什么时候触发、依赖谁、跑在哪台机器上、跑挂了怎么重来”这些问题整合成一个可以自己掌控的小系统。这篇文章我会从需求出发把设计思路、核心状态机、实际代码路径、参数计算和问题排查全部分享出来你完全可以照着抄。1. 为什么是“ax”调度需求从哪来1.1 传统定时任务和人工编排的痛点早期我所在的团队很小定时任务就是用 Linux 自带的 crontab最多再套一层 shell 脚本失败了就发一封邮件。后来服务拆成十几个模块任务数量涨到了几百个crontab 的痛点就很明显了每台机器上的 crontab 内容是独立的没法统一管理任务之间如果有依赖关系只能在脚本里用sleep硬等或者通过数据库状态位轮询执行完的结果没有统一记录出了问题只能去翻机器上的日志。再往后我们换过 Quartz、XXL-Job 这类框架单纯“定时触发”确实方便了很多但真正的麻烦在于“编排”。举例来说一个对账任务是凌晨 2 点跑但它必须等待所有上游的数据同步任务完成后才能开始如果数据同步因为上游接口超时晚了一个小时对账任务不能傻等它需要被动态推迟同一个任务在双 11 这种大流量日会同时触发上百个实例资源不够时还要保证高优任务先执行。这些需求传统定时任务的“cron 表达式 脚本”模型根本覆盖不了。1.2 ax要解决的核心问题ax调度给自己定的目标很明确把“时间触发”和“状态触发”统一成一个任务模型。时间触发就是常见的延时任务、定时任务状态触发则是当某个前置条件满足后自动拉起下游任务。比如上游同步任务执行成功后发一个事件ax调度收到事件后立刻评估下游任务是否可以变为 ready 状态。同时还要解决三个实际问题第一全局可见。任何一个任务现在处于什么状态、由哪个 worker 执行、已经重试了几次都要能随时查出来。第二资源可控。每个任务有优先级每个队列有并发水位调度器不会因为一个无限循环的坏任务把整个系统打垮。第三失败可处理。任务挂了不是直接放弃而是按照策略重试、降级、或者触发人工补偿通道。这套东西做完后我们在内部把“ax调度”直接当成一个基础设施服务在用业务方不需要关心任务被调度到哪台机器只需要在页面上或者通过 SDK 注册任务并声明依赖关系即可。2. ax调度整体设计思路拆解2.1 调度模型选型中心化 vs 去中心化先选了一个最基础的问题到底用中心化调度器还是让每个 worker 自己去抢任务纯去中心化的方案看起来很美每个 worker 从消息队列里拉任务天然支持横向扩展。但任务编排里有一个致命需求全局依赖判定。比如一个任务 B 要等到 A1、A2、A3 三个任务全部成功后才会触发如果每个 worker 各抢各的那谁来判断 A1、A2、A3 全完成了呢除非搞一个独立的一致性存储来保存依赖状态实际上还是要有一个中心决策点。所以 ax调度最终采用中心化调度器 可水平扩展 worker 的模型。调度器只负责任务状态的推进和分发不执行具体业务逻辑。这里最担心的是单点压力我做了分桶处理把任务按照 ID 哈希分成若干个桶每个调度器实例只负责一部分桶同时调度器之间通过 leader 选举选出一个 active 节点只有 active 节点才会跑调度循环。这样既保留了中心化决策的全局视野又不会把所有任务的状态计算都压在一个进程里。2.2 任务依赖关系的表达方式任务之间如果有依赖最自然的方式是画一张有向无环图DAG。ax调度的核心数据模型里每一个任务实例对应一个节点节点之间有 parent 和 child 的边关系。调度器每次扫描时只需要判断一个任务实例的父任务列表是否全部处于终态且成功如果满足就把它从 pending 推到 ready。实现细节上我用了两张表一张ax_task存任务定义一张ax_task_instance存一次具体的运行记录。依赖关系可以放在任务定义里也可以放在一次实例的触发参数里。最开始的版本把依赖关系存成 JSON 字符串后来发现要查询某个任务的完整上游链条时特别费劲于是拆了一张ax_task_dep表专门记录 task_id、parent_task_id、dep_typesuccess / fail / finish。这样做的好处是可以通过一条 SQL 把下游所有任务一次性捞出来配合内存里的 DAG 缓存调度扫描的速度可以做到毫秒级。2.3 资源配额与优先级控制调度不只是“决定谁先跑”还要决定“同时跑多少”。ax调度里每个任务定义都可以配置priority和max_concurrency另外每个 worker 分组还能配置总并发上限。举个例子某个数据同步通道最多允许同时跑 5 个任务电商订单催付任务在活动大促时需要优先执行那么在资源紧张的时候调度器会把max_concurrency算成一个桶桶空余时优先把高优任务投递给 worker。我是用一个内存中的资源账本加上 Redis 的原子扣减来实现的。调度器准备派发一个任务前先检查对应 worker 组当前的并发水位如果低于阈值就通过INCR一个并发计数器占坑任务执行完成后再把计数器递减。之所以不用纯数据库行锁是因为调度循环的扫描频率太高如果用SELECT FOR UPDATE逐行锁数据库瞬间就成了瓶颈。内存账本只负责决策Redis 计数器负责跨节点一致实测下来性能非常稳。3. 核心细节解析与实操要点3.1 任务状态机的关键设计ax调度里任务实例的状态流转是最大的坑也是最值得讲的部分。我定义的状态有这些pending、ready、running、success、failed、retrying、timeout、canceled。每个状态之间不是随意跳转的必须符合严格的状态机规则。比如一个任务从 pending 变成 ready 之后调度器会把它投递给 worker。worker 接收时先将状态改为 running然后执行业务逻辑。这里最容易出问题的是“投递失败”。如果调度器把任务发给 worker 后网络抖动导致 worker 没收到或者 worker 收到了但回调结果丢了任务会一直卡在 running。后来我加了一个“投递中”的中间状态叫 dispatching调度器发出任务时先把状态改成 dispatchingworker 确认接收后再改成 running如果超过一定时间还没确认调度器会主动把状态回滚到 ready重新投递。这个细节帮我们避免了大量“僵尸任务”。还要强调状态变更日志。我一开始只在任务实例表里记录当前状态排查问题时发现根本不知道这个任务是什么时候从 pending 变成 ready 的更不知道有没有发生过重试。后来加了一张ax_task_instance_log表每次状态变更都写一行包含 from_state、to_state、operator、trigger_time、extra_info。线上排查随意查一条链路就知道“卡在哪个节点了”强烈建议你从一开始就做这件事。3.2 延迟触发与超时控制调度系统里面最常用的一类需求是延迟触发比如下单后 30 分钟未支付就自动关单任务提交后 5 分钟还没执行就需要超时重试。这种场景如果每次扫描都去遍历全表效率很低。我调研过常见方案一种是用消息队列的延迟消息比如 RocketMQ 的定时消息但缺点是延迟级别有限另一种是用 Redis 的 ZSET把到期时间作为 score用一个线程轮询头部元素复杂度低且精度可控。ax调度的定时任务模块就是基于 Redis ZSET 实现的分层时间轮。我并没有自己从零写复杂的时间轮而是用 ZSET 做了两层分钟级任务用 ZSET 存放未来 30 分钟内需要触发的任务每秒钟轮询一次超过 30 分钟的任务放到单独的表里每分钟扫一次到期范围到期后刷入 ZSET。这样既避免了大跨度时间任务的轮询压力也保证了秒级精度。对于超时控制则是给每个任务定义 timeout 字段调度器在 running 状态上做定期扫描如果当前时间减去 start_time 已经超过 timeout就会强制将任务标记为 timeout并按照配置触发重试或告警。3.3 调度器的高可用实现高可用是整个系统能不能稳定跑下去的基础。ax调度采用多实例部署所有实例连接同一个 MySQL 和 Redis。每个实例启动时会尝试在ax_scheduler_node表插入一条心跳记录同时尝试获取一个分布式锁只有拿到锁的实例会成为 active 调度器。这里要特别注意active 节点如果挂了其他节点要能够在较短时间内顶上。我用的是 Redis 的SET key value EX 10 NX作为租约active 节点每 3 秒续约一次如果超过 10 秒没有续约其他节点就能获取到锁并成为新的 active。这套机制简单但有效。worker 节点同样通过心跳上报自己的存活状态和当前并发数调度器只把任务投递给那些心跳正常且并发未满的 worker。如果 worker 心跳超时调度器会将其标记为离线并把该 worker 上正在 running 的任务重新置为 pending等待其他可用 worker 执行。4. 实操过程与核心环节实现4.1 从零搭一个ax调度的最小闭环这部分我直接讲怎么把一个最简单的调度跑起来最小闭环只需要三个部分一个任务定义表、一个调度循环、一个 worker 处理逻辑。任务定义表结构非常简单核心字段是 task_id、handler_name、trigger_type、cron_expr、priority、max_concurrency、timeout、retry_count。trigger_type 区分时间触发time和事件触发event。调度循环的主流程我用 Go 的伪代码来描述大概是这样的func (s *Scheduler) loop() { ticker : time.NewTicker(500 * time.Millisecond) for { select { case -ticker.C: // 1. 将到期的定时任务刷入待处理队列 s.flushDueTasks() // 2. 扫描可重新投递的 dispatching 超时任务 s.rollbackDispatchingTimeouts() // 3. 扫描 running 超时任务 s.handleRunningTimeouts() // 4. 根据 DAG 依赖情况推进任务状态 s.advanceReadyTasks() // 5. 尝试派发 ready 任务给可用 worker s.dispatch() } } }实际项目里这四个步骤不是简单顺序执行每一步都要加分布式锁保护但最小闭环可以先忽略并发问题跑通全流程。worker 端就简单得多启动时向调度器注册 handler然后通过长轮询或者 WebSocket 接受任务执行完回调调度器更新状态。4.2 关键参数计算与配置调度系统里最容易被忽略的是参数设置。比如 task timeout设置太短会让正常执行较慢的任务反复重试设置太长又会导致故障任务长时间占用并发名额。我是按“P99 执行时间 缓冲时间”来算的。先看这个任务之前 7 天的 P99 耗时比如是 30 秒那么 timeout 建议设置为30 * 1.5 15也就是 60 秒左右。第一次接入没有历史数据时可以先放一个偏保守的值比如 3 分钟跑一周后再根据实际分布调整。重试次数的计算也有门道。不能盲目设置成 3 次我一般会结合失败原因来判断。如果任务失败是因为下游接口 5xx那重试间隔要阶梯递增比如 1 分钟、5 分钟、15 分钟如果失败是因为业务校验失败那重试多少次都没用应该直接走人工告警。ax调度的 retry_interval 支持配置成一个数组比如[1m, 5m, 15m]调度器在重试时依次取下一个间隔非常灵活。并发水位 max_concurrency 也不是越大越好。建议根据 worker 的资源情况设置为可用 CPU 核数的 2 倍以内如果任务中是大量 IO 操作可以适当放大到 4 倍如果任务里全是 CPU 密集计算设置成核数即可。我用一个简单公式max_concurrency min(worker 数量 * 2, 目标队列允许的最大积压数 / 平均执行时间)。4.3 一个真实业务场景的调度编排示例拿一个再常见不过的场景举例订单模块每天凌晨需要跑对账逻辑是对接支付渠道下载对账单然后解析、核对、汇总、发送邮件。这四个步骤是有依赖的必须串行执行。在 ax 里面我会定义四个任务download_bill、parse_bill、reconcile、send_report。任务定义里都配置了父任务依赖。调度器会在每天凌晨 1 点创建download_bill实例执行成功后发事件调度器收到事件后把parse_bill从 pending 推到 ready后续任务依次推进。如果download_bill因为渠道接口晚上 10 分钟才成功那后面的任务都会自动顺延不需要人为调整 cron 时间。这里最关键的是“事件驱动”而非“轮询判断”。调度器维护一个事件通道事件类型是task_success负载中包含 task_instance_id。收到事件后调度器拿着任务实例 ID 去查依赖表中谁是它的下游然后通过 DAG 算法判断下游的所有父任务是否都成功了都成功则立即变更状态。这个细节让 ax调度在网络抖动导致的乱序场景下也不会出问题因为依赖判定始终看的是终态而不是谁先通知。5. 常见问题与排查技巧实录5.1 任务重复执行和幂等控制这个几乎是每个调度系统都会遇到的坑。网上很多说法是“通过分布式锁保证只有一个 worker 执行”但实际上即使加了锁网络分区也可能导致一个任务被两个 worker 同时执行。ax调度给出的对策不是“不让重复发生”而是“重复发生之后不影响业务”。具体做法是给每个任务实例生成一个唯一的 biz_key比如orderId taskType然后在业务代码里用数据库唯一索引或者 RedisSETNX做幂等拦截。我见过不少团队把幂等控制放在调度器层结果调度器防住了百分之九十九的并发重复但遇到极端情况还是有问题后来学乖了统一要求业务 handler 自己保证幂等ax调度只负责在开始执行时生成幂等键在回调结果时校验实例状态是否合法。5.2 调度延迟突然变大的排查如果你发现一个任务明明是整点触发但实际执行时间晚了十几秒不要先怀疑 worker先去查调度器日志。我们有一次遇到所有任务大面积延迟原因是某个 bucket 里的任务特别多而负责该 bucket 的调度器节点负载过高。排查套路很简单先看调度器节点的 CPU 和 GC再看扫描数据库的时间最后看 Redis 操作耗时。另外还有一个容易被忽略的原因是“时间轮的精度”。如果你用的是 ZSET 方案score 是未来时间戳的毫秒值那没问题但如果 score 设置成了秒级那触发精度就只有秒。ax调度统一用毫秒作为时间单位并且每秒轮询一次 ZSET 头部基本可以实现 100ms 以内的触发精度。5.3 慢任务阻塞后续任务的处理任务执行很慢本身不一定有问题问题在于它占着并发名额不放导致同队列的其他任务全部阻塞。ax调度里的处理方式是“线程池隔离 超时熔断”。每个 worker 内部根据 handler_name 分桶不同任务使用不同的线程池这样慢任务只会消耗它自己那个线程池的线程不会拖垮其他类型的任务。另一个小技巧是给任务设置“最大运行时间比例”。如果一个任务在过去 24 小时内的实际执行时间经常超过 timeout调度器会自动把这个任务的并发水位调低并发出告警。这个机制虽然简单但救我很多次因为很多问题不是靠人工盯配置盯出来的而是靠系统自动规避的。5.4 问题排查速查表现象可能原因排查方法任务一直 pending 不触发依赖任务失败了DAG 没有推进查ax_task_instance_log看父任务终态任务状态卡在 dispatching调度器发出任务后 worker 没接收查 Redis 中的待确认队列检查 worker 心跳任务重复执行上次执行回调丢失调度器重新投递检查业务侧幂等键看启动日志里的 instance_id调度延迟明显调度器节点负载高、时间轮精度不足查看调度器 GC 时间与 Redis 耗时某类任务全部失败handler 抛错或 worker 线程池耗尽查看对应线程池活跃线程数和异常日志重启后任务丢失缺少重启恢复机制检查是否开启了recover_running_to_pending配置我个人在实际操作中的体会是调度系统出问题百分之八十都不是代码逻辑复杂而是“状态不一致”。只要你在状态流转的每个环节都留痕在投递和回调之间设置超时兜底在业务侧做好幂等基本就能覆盖绝大多数故障。最后再分享一个小技巧所有任务实例的状态变更日志一定要多留存一段时间至少 30 天。我遇到过一个非常诡异的任务错乱问题最后是靠三天前的 dispatch 日志定位出来的。ax调度如果未来要继续扩展我会把这项能力开放成标准的审计接口让业务方也能自助查询而不是每次都要我们手动翻数据库。