1. 从需求倒推“ax调度”的定位不止一个定时器先讲个背景。我在实际项目里接手过一个遗留系统里面散落着三十多处 cron 表达式有的写在代码里有的躺在数据库表中还有几处藏在 shell 脚本里。每次上线都要人工检查“这次改动会不会把哪条定时任务给改了”每次任务没跑起来都要先猜“这个任务到底谁在管”。后来我们决定做一轮收敛把分散的触发逻辑统一到一个调度组件里代号就是 ax。没错取名没什么深意就是顺手敲的两个字母写着写着叫顺口了干脆当正式名字用。这个项目想要解决的事情说穿了就是三件第一把散落各处的定时任务收编到一处管理第二让任务触发之后有人盯、有人管、失败了能自动兜底第三调度系统自身不能成为新的单点故障。所以“ax调度”这个热词如果放到实战语境下指的就是一套具备集中管理、可靠触发、失败重试、运行监控的轻量级任务调度平台。它跟单纯在代码里写一个Scheduled注解或者加个 quartz 依赖完全是两个量级的事情。我之所以不建议你在项目早期就盲目追求 K8s CronJob 或者引入一套重型工作流引擎是因为大多数团队的实际诉求根本没有到“工作流编排”那个程度。你需要的核心能力其实就是把“什么时候该跑什么任务、跑完结果如何、失败了怎么处理”这三件事理顺。而要理顺这三件事完全可以基于一套轻量调度框架自己搭建ax 就是我们落地这套思想的产物。下面我把每个模块的设计思路、踩过的坑、以及可复现的做法展开讲透。适合读这篇文章的人我预设是这样的你维护过至少一个跑批业务被“任务没跑”“任务跑重了”“任务卡死了但没人知道”这三座大山压过你想从零搭建一套调度体系但不确定从哪里下手或者你已经在用某个调度框架却总觉得弹性不够、监控缺失、运维麻烦。接下来讲的每一步都是我们实际跑过一年以上、稳定承接日均几十万次调度请求之后留下来的经验。2. 触发引擎的设计时间精度、时间轮与延迟队列的取舍2.1 先定语义你需要的到底是 cron 还是延迟任务调度系统第一步不是写代码而是把“任务触发”的语义定义清楚。我们当时盘了一下实际业务发现真正需要 cron 这种周期性表达式的地方只占全部任务的三分之一。剩下三分之一是“指定时间跑一次”的一次性定时任务另外三分之一是“某个事件发生后延迟一段时间再执行”的延迟任务。这三类需求如果都硬塞给 cron会很别扭。一次性定时任务用 cron 表达你得在跑完之后手动禁用它一旦忘记禁用第二天就会重复执行。延迟任务用 cron 表达就更离谱了因为 cron 是绝对时间点的周期表达而延迟任务关心的是相对时间。所以我们在 ax 里一开始就把调度语义拆分成了三个维度周期任务用 cron 表达式描述适合每天凌晨跑批、每小时同步这类固定节奏的场景。一次任务指定一个绝对时间点到点触发触发后自动销毁不用管“要不要禁用”。延迟任务任务注册时带一个delay参数表示从注册时刻起多少秒后触发适合下单后 30 分钟未支付自动关闭这类业务。这个拆分看着简单却让整个系统的设计清晰了很多。有些调度框架把所有东西都抽象成“cron 或者 API 触发”到了延迟场景就要额外开发折腾一圈不如一开始就把语义分层。2.2 时间轮实现到期触发数据库轮询只做兜底确定了三类触发语义之后核心问题变成了怎么在几万甚至几十万个待触发任务里快速找出“现在该跑哪个”。最朴素的做法是定期扫描数据库把next_run_time小于当前时间的任务捞出来但这有三个毛病空转扫表浪费数据库连接时间精度受扫描间隔限制做不到秒级精细触发一旦任务量大慢查询直接把库拖垮。ax 的解法是引入内存时间轮。具体来说我们提前把未来需要触发的任务按触发时间排序放进以秒为刻度的时间轮槽位里。一个长度为 60 的秒级时间轮配合一个指针每秒转动一次指针指向哪个槽位就执行这个槽位里的任务列表。为了支持超过 60 秒的延迟再加一层更粗粒度的轮子比如分钟级时间轮到点了再把任务降级到秒级轮子中。这就是经典的层级时间轮思想HashedWheelTimer 就是这么干的。实际效果非常明显从“定时扫表发现任务”变成了“指针转过来主动出队”触发延迟控制在毫秒级。但内存时间轮有个天然的软肋进程重启后内存里的任务全没了。所以数据库表不能丢它承担的是“恢复现场”和“兜底扫描”两个职责。每当调度节点启动先扫一遍库把未来五分钟之内需要触发的任务重新加载进时间轮然后再接着按秒跑。这样既保证了触发实时性又保证了重启不丢任务。2.3 时间精度够用就好别追求毫秒级强制触发我要强调一点调度系统不是实时交易系统绝大多数场景下秒级触发精度已经完全够用。你想想业务侧能感知的差异一个批处理任务早一秒晚一秒执行对业务结果几乎没有任何影响。真正影响业务体验的是“该触发的时候没触发”或者“不该触发的时候触发了”。所以我们在 ax 里统一把触发精度定在秒级不在毫秒级较劲。这带来一个额外好处任务表里trigger_time字段只需要精确到秒索引体积小、查询更快分布式环境下各节点之间的时间同步要求也降低了。不需要引入专门的时钟同步方案各节点用服务器自带的 NTP 一致到秒就够了。如果哪个场景死磕毫秒级——比如证券交易的定时抢单——那就不应该用通用调度系统承载而是走业务系统自己的高精度定时器。工具选型要匹配场景这是我在这个项目里体会最深的一点。3. 执行器与任务分发一个任务到底该由谁跑3.1 调度节点和执行节点分离防止“调度器被任务拖死”时间轮解决了“什么时候触发”接下来要解决“触发之后谁来执行”。很多自研调度系统死在把调度和执行放在同一个进程里调度线程负责扫描时间轮一旦某个任务的执行逻辑里有个慢 SQL、网络超时或者死循环执行线程池被占满调度线程也跟着遭殃最后表现就是所有任务整体停摆。ax 从设计之初就把这两个角色分开了。调度节点只做三件事扫描时间轮、把到期任务投递到消息队列、记录任务触发日志。至于任务本身怎么执行是执行节点的事。执行节点启动时向调度中心注册声明自己“能跑哪些类型的任务”然后从消息队列里拉取投递过来的执行指令跑完再把结果回写。这种角色分离带来一个很务实的好处调度节点可以保持非常轻的负载哪怕某个执行节点上的业务代码把 JVM 堆内存撑爆了调度节点也毫发无损。我们线上跑了一年调度节点的 CPU 使用率长期在 5% 以下反而是执行节点经常因为业务代码写得糙而抖动。如果没有这一层隔离那些业务代码的锅就得调度系统来背排查起来会痛苦得多。3.2 同一个任务类型跑在多个执行节点上靠分布式锁防重复角色分离之后自然衍生出另一个问题一个调度触发指令发到消息队列多个执行节点都能消费那到底让谁跑如果让大家都跑一遍扣款型任务就惨了——多扣一次可没法跟财务解释。所以必须保证同一个任务的同一个触发批次只会被一个执行节点真正执行。我们用的方案是数据库分布式锁。任务触发时生成一个全局唯一的批次 ID执行节点消费指令后先去任务表里尝试把task_run_id对应的记录状态从“待执行”改成“执行中”。这个更新操作的WHERE条件里带上了status 待执行而任务表本身有唯一索引兜底所以哪怕两个执行节点同时更新也只有一个能成功另一个更新影响行数为 0自动放弃本次执行。这个方案的好处是直观、可靠、不需要引入强一致的协调组件。缺点是每次执行都要多一次数据库写操作对执行频率极高的短任务来说会有一定开销。我们当时的取舍是执行频率高于每秒 10 次的任务不做分布式锁直接让单个执行节点消费低频但重要的任务全部走锁宁可多一次数据库交互也不能承担重复执行的后果。3.3 执行超时与心跳上报不能被一个死循环拖垮整个节点执行节点消费了一个任务之后理论上应该在一定时间内结束。但如果业务代码里写了死循环或者外部依赖一直不返回这个执行线程就永久占用了。所以 ax 给每个执行任务都设了超时时间任务配置时由业务方申明“我这个任务最多跑多久”超时之后执行节点直接中断线程并上报失败。为了区分“节点还活着但任务卡住”和“节点整个宕了”这两种情况执行节点每 5 秒向调度中心上报一次心跳心跳内容包含节点自身状态、当前正在执行的任务 ID 列表。调度中心拿着心跳数据就能判断如果某个任务超时未结束且它的执行节点心跳还正常那就是业务代码卡住了标记失败并尝试重试或转人工如果某个节点心跳消失那它上面所有未完成的任务都不能立刻重试得等一个观望期防止节点其实还活着、网络抖动导致双跑。这块有个让我印象很深的坑。早期我们定义观望期为 30 秒结果有一次机房交换机例行重启花了约两分钟将近 20 个节点同时掉心跳恢复之后 20 个节点上的任务被重复执行了一大半。后来我们把观望期跟重试策略绑定重试次数为 1 的任务观望期拉到 3 分钟重试次数为 0 的任务可以直接重跑。在“不丢任务”和“不重任务”之间我们选择了给高重试任务更多观望时间因为重复执行的代价通常比延迟执行更高。4. 重试、补偿与失败策略怎么处理“任务真的挂了”4.1 三类失败要分开处理不能一个策略走天下任务执行失败这件事我们把它分成三类可重试的瞬时失败网络抖动、依赖服务 5xx、数据库连接池打满后超时这类失败重试大概率能成功。不可重试的业务失败参数校验不过、业务状态不允许操作这类失败重试一万次也白搭甚至会因为反复重试放大对下游系统的压力。环境性失败磁盘满了、配置缺失、依赖服务彻底下线这类失败重试没有意义必须人工介入。ax 的做法是让任务在注册时就声明自己的失败类型。业务方在执行逻辑里捕获异常后主动抛出RetryableException或者NonRetryableException框架根据异常类型决定后续动作。只有RetryableException才走重试策略NonRetryableException直接标记失败并发送告警。早期我们没做这个区分对所有的异常一视同仁地重试三次结果有个任务因为代码 bug 每次都抛不可重试异常每次失败都重试三遍把一个并不重要的外部接口打到半死——那种故障纯粹是调度策略设计失误造成的业务方其实完全没责任。4.2 指数退避加抖动让重试流量不扎堆重试间隔的设计也有讲究。最简单的固定间隔 5 分钟重试一次听上去没问题但假设一个时刻有 1000 个任务同时失败每个都按相同的固定间隔重试那么每隔 5 分钟就会有 1000 个重试请求同时打向下游系统。这就是重试风暴对下游的伤害比一次失败大得多。ax 参考了业内成熟方案采用指数退避加随机抖动第 n 次重试的间隔时间为min(初始间隔 * 2^(n-1), 最大间隔) random(0, 初始间隔)。举个例子初始间隔 1 分钟最大间隔 30 分钟那么第一次重试在 1~2 分钟之间随机触发第二次在 2~3 分钟之间第三次在 4~5 分钟之间以此类推。抖动的那部分随机量非常关键它让同一批失败任务的重试时间点自然错开不再出现整齐划一的“重试洪峰”。4.3 失败任务要有“人工处理台”不能只发告警了事只发告警不管处理是很多调度系统虎头蛇尾的地方。告警发出去之后值班人员打开了监控后台结果只想看到“哪条任务失败了、异常信息是什么、可不可以直接重新执行”却发现后台只能看到失败数和时间戳还得翻日志找堆栈。ax 在落地时就要求每个执行结果都保存完整的执行上下文包括入参、异常堆栈、执行节点 IP、整个执行链路耗时并在管理端提供一个“失败任务重试”按钮。这个按钮不是简单的“再跑一次”而是重新投递一条一模一样执行指令到消息队列。这样设计的好处是值班人员处理失败时不需要登录执行节点手工跑脚本直接在页面上操作操作记录也会完整留存方便事后审计。我们内部有个不成文的规定任何任务连续失败超过三次且没人点击“强杀”或“改参重试”系统会自动升级为电话告警。这个兜底机制在几次深夜故障里真的救了场。5. 高可用与一致性调度系统自身不能变成新的单点5.1 调度节点多活靠“抢锁”决定谁是真的调度者调度节点不能只有一个实例否则它一挂所有定时任务集体沉默。但也不能所有实例都同时跑时间轮否则每个任务会被触发多遍。两种极端之间需要一种折中多个调度节点同时在线但任意时刻只有一个“主调度节点”在跑时间轮其余节点作为热备。ax 用数据库行锁实现选主任务表或者专门的状态表里维护一行scheduler_master记录每个调度节点启动时尝试更新这一行更新条件里带last_heartbeat_time距今不超过 10 秒成功更新则成为主节点并循环续期。主节点挂了之后心跳不再续期其余节点经过 15 秒等待后抢锁自动接管时间轮。这个方案的实现成本很低性能也足够——每 5 秒一次数据库心跳更新对任何数据库都构不成压力。运行时主节点每 5 秒也要扫描时间轮把任务投递到消息队列所以主备切换最多造成一个心跳周期的延迟业务完全无感。5.2 执行指令走消息队列削峰消费端要做幂等时间轮到点后调度器不直接调执行节点的接口而是把执行指令投递到一个内部消息队列。这一层削峰非常重要假设某个时间点集中触发了 5000 个任务如果全部直接发 HTTP 调用执行节点瞬间被打爆而且超时重试的语义也不好做。消息队列天然带缓冲执行节点按自己的消费能力拉取指令处理不过来就慢慢消费谁也不会被压垮。消息队列场景下消费端的幂等是铁律。消费端不能单纯“收到消息就执行”而要用消息里的唯一批次 ID 去任务表里做状态流转待执行到执行中只有一次能成功。因为这个幂等判断在消费端做即使消息被重复投递、消费者重启回溯也不会造成重复执行。每次有人问我“为什么引入 MQ 之后还有重复消息”我的回答都是一句话消息重复不可怕可怕的是你默认消息不会重复。5.3 时间轮状态持久化重启不丢最近窗口的任务内存时间轮最怕进程重启。如果正在跑时间轮的节点突然宕机内存里已经加载的所有待触发任务就全部丢失了。等新的主节点选出来之后如果不知道这些任务的存在它们就不会被触发。ax 的解法分成两层。第一层是保存“最近触发记录”。每投递一个任务就写一条触发日志日志里包含任务 ID 和计划触发时间。新主节点接管之后扫描最近五分钟内的触发日志凡是投递时间超过两分钟却没有收到执行节点确认的任务重新投递一次。第二层是数据库的next_run_time字段兜底新主节点启动时扫描未来五分钟内需要触发的周期任务补录进时间轮。这两层一配合任何一次崩溃最多造成几分钟级别的触发延迟理论上不会丢任务。实际运维中我们的切换验证做过十几次最差的一次任务整体延后了 20 秒没有出现任务消失的情况。6. 监控大盘与排障三板斧调度系统怎么“看到”自己健康6.1 核心指标就七个延迟、积压、成功率、失败率、节点心跳、任务超时、重试次数调度系统的监控不需要上来就搞上百个指标那只会让人不知道看什么。ax 长期只盯七个核心指标。其中“触发延迟”衡量的是任务计划触发时间和实际投递时间之间的差值正常情况下应该稳定在 5 秒以内如果延迟超过 30 秒说明时间轮扫描或者消息队列投递出现了瓶颈。“消息积压”直接看队列的未消费数量执行节点消费能力跟不上的时候它最先上涨。剩余几个指标比较常规成功率、失败率、节点心跳、任务超时、重试次数全部按任务维度和节点维度两个口径分别统计。我把这七个指标在 Grafana 上做成两屏第一屏全局概览适合值班瞄一眼第二屏任务明细适合定位“到底哪个任务在拖后腿”。监控的价值不在于指标多花哨而在于“异常能被看见”并且看见之后能顺着一条线索往下追。6.2 排障场景一任务没跑先查“触发链”而不是查执行日志这是最常见的排障动作。任务没跑很多人第一反应是登进执行节点翻日志但正确的排查顺序应该是从前往后查触发链先看任务表里next_run_time是否更新了没更新说明调度器根本没有执行它再看触发日志如果连触发日志都没有说明任务可能不在时间轮里需要关注它是不是新注册的、调度器有没有加载到如果触发日志有、但执行节点没消费到就得看消息队列里有没有消息、消息是不是卡在积压里了。按照这个链路排查绝大多数“任务没跑”的问题在五分钟内就能定位根本不需要翻业务代码。我们内部管这个方法叫“触发链三段式”任务表状态 - 调度触发日志 - 消息队列积压。任何一次“任务没跑”的工单值班同事都会先按这个顺序走一遍再决定要不要找业务开发看代码。这套流程跑了一段时间之后被业务方吐槽“调度系统黑盒”的声音基本消失了因为排查路径清晰可见。6.3 排障场景二任务跑重了先查“消费确认时序”而不是怪消息队列重复执行的事故是另一种典型。很多人一遇到重复执行就归咎于“消息队列保证不了精确一次”其实大部分重复执行都是因为消费确认的时序设计有缺陷。ax 的消费流程规定执行节点拿到指令之后先做幂等状态流转再执行业务逻辑最后才向消息队列提交确认。这三个步骤的顺序一旦颠倒——比如先提交确认再执行任务——就会导致执行中途节点崩溃时消息已被确认无法重新投递任务既丢了也没人知道或者确认操作因为网络原因失败被队列重投任务又重复执行。如果确认顺序完全正确但问题依旧那就要回过头查task_run_id的状态流转是否真正做到了原子化。有一种隐蔽的写法是先查任务状态如果状态是“待执行”就去执行业务逻辑执行完再更新状态。这个写法在高并发下必然出问题因为两次数据库操作之间有时间窗口两个消费者可能同时查到“待执行”状态。正确做法必须用一条带条件的 UPDATE 语句完成状态抢占让数据库保证只有一个消费者能抢到执行权。我们在代码评审时把这个列为调度相关代码的红线出现一次打回一次。6.4 排障场景三任务偶发超时先看 GC 日志和网络 I/O 再优化业务代码偶发超时往往比稳定超时更难排查因为现象时好时坏不具备稳定复现条件。我的经验是这类问题先不看业务逻辑而是看两个基础指标执行节点的 GC 耗时和网络 I/O 波动。曾经有个任务每周总有那么一两次超时业务方坚持认为代码没问题结果加了 GC 日志后一查老年代 GC 导致安全点停顿最长一次停了 4 秒多任务就是这么被拖超时的。调完堆内存参数之后超时现象消失。另外如果任务涉及跨机房调用或者访问外部接口出问题先确认目标服务的响应耗时——网络上偶发的 TCP 重传和连接排队都可能让一个本应几十毫秒的调用拖到几十秒这种锅真不该让业务代码来背。7. 从 ax 项目沉淀下来的几条经验法则项目做了一年多从最初的一堆散装定时任务演进成带调度中心、执行集群、消息队列、监控大盘的完整体系踩过的坑挺多但沉淀下来的经验其实很收敛就几条。第一调度系统的核心价值是“可靠性”而不是“高性能”。无论你用什么框架、什么架构先回答“节点挂了我怎么办、执行失败了我怎么办、消息重复了我怎么办”再考虑每秒钟能支撑多少触发量。可靠性靠的是状态流转设计的严谨而不是代码写得快。第二语义分清楚比功能花哨重要。周期、一次、延迟是三类完全不同的触发语义混在一起只会让边缘情况爆炸。宁可多做几个分支也不要强行抽象成一个万能模型。第三任何关于任务状态的变更都要用一条原子 SQL 完成。查了再改、改了再查的两段式写法在并发下必出事故。这是调度系统里最高优先级的编码纪律没有之一。第四监控和排障链路必须从第一天就设计不能等上线了再补。在我接手项目以前调度系统没有触发日志出了问题只能靠猜那种“猜不出来就手工跑一遍看看”的运维方式在任务量上来之后完全行不通。哪怕只是简单地把每次触发的关键信息写到一张表里也会让后续的排障效率提升一个量级。最后如果让我给准备做同类系统的团队一个建议我会说不要一上来就调研市面上的开源框架然后做选型对比先把自己业务里的调度需求完整梳理一遍把任务清单、执行条件、失败容忍度列出来再回头做技术选型。很多团队最后发现自己需要的不是一个功能强大的工作流引擎而是一套能管住“什么时候跑、跑了没有、跑挂了怎么处理”的轻量体系。ax 就是沿着这个思路长出来的我希望这篇文章里讲的判断逻辑和踩坑经验也能帮你少走几段弯路。
