1. 从一个内部代号聊起ax调度到底是什么“ax”这名字我第一次听到时也愣了下组里脚手架工程起了个代号叫ax后来做的任务调度模块沿用这个名字内部就叫“ax调度”。它不是某个开源框架的封装也不是标准行业术语而是我们自己的一套轻量级定时任务与延迟消息调度引擎。如果你在项目里见过类似“每天晚上三点同步订单状态”“用户下单三十分钟后未支付自动关单”这种需求那你就在跟ax调度这类东西打交道。先定义清楚它做什么ax调度负责把“某个时刻要做的事”在正确时间点触发并且把触发后的任务可靠地派发给执行端。听起来像“定时任务框架”但传统定时任务和真正的调度引擎之间差别不小。多用cron表达式挂任务的场景里服务重启、任务积压、分布式重复执行都是让人头疼的问题。ax调度在设计时重点解决了三件事时间到点后任务不丢、同一个任务在集群中不重复执行、执行失败后能自动补偿。适合谁来用后端开发、平台工具链维护者、架构偏执狂只要你在做ToB系统、电商交易链路、订单履约流程搞一套内部分布式调度是迟早的事。这套东西不依赖中间件有多高级MySQL Redis 一套服务进程就能跑起来。后面我会把关键设计、核心代码思路、踩过的坑都摊开讲按我的实操经验一步步带你把调度模块搭起来。我引入这个话题想表达的是调度引擎最核心的不是“到点触发”这个动作而是“触发之后如何保证任务状态可靠流转”。ax调度在这块的取舍很接地气不搞复杂的编排DAG但把单层任务触发、重试、幂等、监控做扎实了反而比一堆花哨功能更耐用。接下来我从架构选型开始讲讲为什么ax调度会走“轻量自研”这条路。2. 架构设计与选型思路2.1 实现调度任务的四代演进路线先说一个常见的后端设计误区很多人一上来就喜欢分布式事务、消息队列、工作流编排全家桶其实多数业务场景根本撑不起那么重的架构。ax调度在设计之前我对比了四代调度模型真实项目里踩过不同代际的坑后来才确定哪一种组合最合适。第一代是进程内Timer/ScheduledExecutorService只能单机用服务一重启内存里的调度就全丢了。第二代是引入xxl-job这样的现成中间件功能全但依赖注册中心、需要管理调度中心和控制台团队维护成本不低。第三代是“消息延迟队列 消费者触发”模式用RocketMQ延迟消息或Redis键空间通知问题在于前端触发到后端消费之间链路长时间误差动不动就是分钟级。第四代是ax调度的方案数据模型用MySQL存任务明细和状态触发核心在服务端用时间轮维护内存级倒排索引到点后把任务写入Redis延迟队列再由执行器线程池拉出并执行。这条演进路线反映的是“触发与执行分离”的设计哲学。触发层负责算时间执行层负责干体力活。把两者拆开之后每层都能独立扩缩容任务触发不依赖执行端是否健康执行端挂掉之后任务也不会只停留在内存里。ax调度在第四代方案里还加了补偿扫描器每隔几十秒扫一次MySQL里“已到触发时间但迟迟没进入执行状态”的任务保证哪里有漏网之鱼都能捞回来。2.2 存储选型别一上来就迷信Redis我见过不少团队做调度时所有状态直接往Redis里塞理由是“快”。但任务调度跟缓存场景不一样任务不是读了就完事的它需要生命周期、审计日志、失败原因留痕。如果核心信息只在Redis里一旦Redis宕机或者被淘汰所有任务状态全部归零这个代价比多几次数据库IO高得多。ax调度最终选择了MySQL为主存储Redis做辅助队列。MySQL里三张表撑起全部逻辑task_define存任务定义、task_instance存每次触发产生的任务实例、task_log存执行日志。Redis里存两类数据一类是即将到期的任务ID集合用有序集合按触发时间戳排名另一类是分发中的执行消息用列表结构暂存。MySQL保住最终可靠状态Redis保住触发的实时性。哪怕是Redis全挂最坏结果只是补偿扫描器多花几十秒把任务补触发业务侧几乎无感。这么设计还有个好处运维排查问题时可以直接对着数据库和执行日志看不用在缓存里翻半天。遇到任务没执行这种事第一反应永远是“去MySQL查task_instance的状态”而不是“去Redis的key里捞数据”。这个习惯能够让定位时间缩短一半以上。2.3 为什么核心触发用时间轮而不是死循环扫库很多轻量调度方案是直接ScheduledExecutorService每隔几秒扫一次数据库把到点任务捞出来。这种方案在小规模场景下没问题但任务量上去之后每次全表扫描的数据库压力会非常恐怖。ax调度没有走这条路而是用了一个常驻内存的时间轮结构。时间轮的原理说白了像一个时钟拨盘拨盘分成多个槽位每个槽位对应未来一个时间刻度。任务注册时根据延迟秒数计算放进哪个槽位一个线程负责推进指针指针指向哪个槽位就把槽位里的任务统一取出来处理。不是扫全库只是取当前刻度对应的任务时间复杂度无限逼近O(1)。生活化类比就是餐厅叫号机等位的人按预估等候时长放进对应的号池叫号员到了时间点只从当前号池里叫人不会满餐厅喊一遍。实际落地时时间轮只存任务ID和触发时间戳不存任务详情内存占用非常有限。任务真正到点触发后执行器拿到任务ID再去MySQL加载完整定义这样时间轮的职责非常单一不跟业务逻辑耦合。刚开始实现时间轮时最容易犯的错是把任务详情全塞进去结果任务量大时内存直接顶不住后来统一改成存ID瞬间清爽很多。3. 核心机制与实操要点3.1 触发模块时间轮两大细节别写错第一细节是时间轮的槽位跨度。槽位跨度可以固定为1秒也可以动态调整。ax调度落地时我选择固定1秒跨度理由很简单业务场景里调度任务最小粒度就是秒级不管是订单超时关单的30分钟还是报表任务每天凌晨3点到秒就够了。如果你做的是毫秒级高频调度时间轮的存储和CPU开销会上去几个量级必须重新评估方案固定每秒一个槽位带来的误差在绝大多数业务中都能接受。第二个细节是关于“槽位中的任务如何处理”。ax调度在时间轮指针推进到某个槽位后不是直接同步执行任务而是先把任务ID批量写入Redis延迟队列。这个设计有两个考量其一任务执行过程可能比较慢如果直接在时间轮线程里执行业务逻辑时间轮推进就会卡住后面的任务全部延迟其二把任务投递给队列后执行端可以按自己的消费能力拉取形成天然的削峰填谷。你看到的代码结构是这样的时间轮线程只负责enqueue完全没有执行逻辑的痕迹执行端单独一组worker线程在队列中消费。实现时间轮时另一个容易踩的坑是“槽位计算越界”。延时小时数超过时间轮可覆盖范围时要么做多级时间轮要么把超长任务落入数据库扫描补偿逻辑中。ax调度选择了后者超过两小时的长延时任务不等内存时间轮直接依赖补偿扫描器这样内存时间轮拨盘长度始终可控不会因为一个周级任务导致整个轮盘溢出。3.2 执行模块worker线程模型的关键参数执行端是ax调度的体力活部分设计目标只有一个任务从Redis队列中拉出来后必须在有限时间内被处理完且不能因为并发度设置不当把下游依赖服务打挂。worker线程池的参数值得多花几句话讲清楚。核心线程数我用的是Math.max(4, 处理器核心数 / 2)最大线程数是核心线程数的2倍队列容量取1000拒绝策略用CallerRunsPolicy。这个参数组合来源于一次线上事故之前把最大线程数调到核心数4倍结果下游数据库连接池先顶不住一个本来只需要毫秒级响应的事务接口被打成长时间阻塞整个链路的P99从50ms飙到4秒。CallerRunsPolicy的作用是当线程池满且队列也满时新任务不抛出异常丢弃而是让提交任务的线程自己去执行。这个策略特别适合调度场景因为它天然带背压能力任务永远不会无声无息地丢最多就是触发端速度降下来等执行端消化完再把队列跑起来。实际运行中触发量再大也不能把执行端线程池无限调大宁可多等几秒也不能让下游承载不住。执行端还要做一层“任务超时保护”。整个执行过程包在一个future里设置一个自适应的超时时间默认30秒如果任务类型声明为“长任务”则抬到10分钟。超时后立即中断线程同时把任务实例状态置为失败。不写这层保护的话一旦业务代码里藏着慢SQL或者死循环worker线程会被占住不放越积越多最终线程池全被拖死。3.3 补偿机制失败重试与幂等设计调度里最怕的不是任务失败而是失败后任务被静默丢弃。ax调度补偿体系分成两个维度任务实例失败后的重试和时间轮漏触发后的补扫。先讲失败重试。任务定义里带有retryCount、retryIntervalSeconds两个字段默认分别是3和10。执行失败时不是立刻重试而是先把任务实例状态标记为RETRYING同时计算下一次执行时间重新塞进延迟队列。这里严格做到了指数退避之外的“固定间隔快速失败”由于大多数任务失败原因在短时间内无法恢复比如下游服务重启、依赖数据库主从切换所以固定间隔10秒给下游留恢复时间。如果你重试间隔设置太短一秒内连续重试三次大概率三次全失败然后进入死循环对下游造成持续的无效压力。再讲幂等。调度系统天然存在重复执行的可能执行端超时了但业务其实已经成功补偿扫描器又触发一次接着就要考虑同一任务实例是否会被执行两次。ax调度的做法是每个任务实例有一个唯一执行ID执行端拿到任务后先通过Redis执行SETNX写入lock:exec:{executionId}只有拿到锁才能执行。每次真正执行前还会在MySQL里检查任务实例状态如果已经是SUCCESS就跳过。这样哪怕网络抖动、消息重复投递也不会产生重复的订单回写或者重复发短信。补偿扫描器是最后一道安全网只维护一个简单的逻辑轮询task_instance表中状态为CREATED但触发时间已过去 60 秒以上的记录将其重新提交到触发通道。这个扫描器运行频率很低60秒跑一次每次用批量查询限制一次最多捞500条不会对数据库产生大压力。4. 上手实操5分钟接入一个业务任务4.1 环境准备与依赖引入ax调度不算一个开箱即用的开源中间件而是工程内部封装的模块。你在自己项目中复现这套东西时环境需要一个MySQL数据库一个Redis实例版本无硬性要求以及一个Java服务进程。保证这三个基础模块都有之后就可以在工程的pom.xml里引入调度SDK一般的做法是打成内部依赖包用ax-scheduler-core命名。运行时需要的表结构其实不多但别偷懒精简。我强烈建议task_define和task_instance两张表分开建。以前为了少建一张表把任务定义跟每次执行状态混在一起最终的结果就是排查问题时根本分不清“这个任务本来长什么样”和“它这次执行得怎么样”。分开后逻辑非常清晰定义表里只放任务编码、cron表达式或者延迟秒数、重试参数、回调的bean名称实例表里放执行ID、任务编码、预期触发时间、实际触发时间、执行状态、错误信息、重试次数。Redis不需要初始化额外结构直接用普通的key操作即可但建议提前在配置里规划好延迟队列和锁的key前缀比如ax:delay:task和ax:lock:exec避免跟其他业务key冲突导致误删。到这里基础设施就绪。4.2 定义一个任务并注册到调度器核心操作分三步。第一步写一个业务执行器实现统一的TaskHandler接口。接口里只有一个方法handle(TaskContext context)你在这个方法里写自己的业务逻辑比如调用订单服务把超时订单置为关闭。第二步注册定义在数据库的task_define表中插入一条记录指定任务编码orderCloseTask延迟秒数1800重试次数3执行器bean名orderCloseHandler。第三步启动服务注入调度器客户端并调用loadTask把该任务的定时配置加载进时间轮。服务启动阶段会有一个对账动作检查数据库中已有的任务定义比内存中加载的任务多哪些自动补齐确保新加一个任务不需要重启整个集群。我实际用的注册代码大致长这样把关键条件说清楚SchedulerClient client SchedulerClient.getInstance(); TaskDefine define new TaskDefine(); define.setTaskCode(orderCloseTask); define.setDelaySeconds(1800); define.setRetryCount(3); define.setRetryIntervalSeconds(10); define.setHandlerBean(orderCloseHandler); client.register(define);注册完只是定义了任务具体要让它跑起来有两种方式一是立即调用client.trigger(taskCode)手动触发一次二是等下一次时间轮匹配。如果你的任务不是固定延迟而是带cron表达式的周期任务就改用define.setCronExpression(0 0 3 * * ?)同时内部会自动把cron拆解成下一次触发时间戳塞入时间轮。这个周期任务模式对写日报汇总、定时对账之类需求非常贴近。4.3 关键配置参数逐个拆解配置项不算多但每个都值得知道为什么这么设。我挑几个最容易改出问题的说明scheduler.scan.interval.ms补偿扫描器运行间隔作用于“漏触发后补捞”的频率。默认60000调小到10000会让任务恢复更快但会增加MySQL查询频率生产环境建议保持默认或15秒。scheduler.timewheel.tick.ms时间轮指针推进间隔默认1000。不建议低于500否则CPU空转明显任务秒级误差完全能接受。scheduler.worker.core.pool.sizeworker线程池核心线程数按前面Math.max(4, CPU核心数 / 2)设置即可。不要看着机器核数多就无脑调大线程上下文切换开销是隐形成本。scheduler.task.max.execute.ms单任务执行最大耗时默认30000。需要支持长任务的可以调大或者让任务实现方在定义里单独声明长任务类型。scheduler.batch.pop.sizeworker一次从Redis队列批量拉取的任务数默认100。调大可以提升吞吐但处理不过来时反而增加任务在worker内等待的时间。这套参数配好后基本不需要频繁改动真正需要调优的点是对高峰期积压任务的处理这个放在第5章说。5. 性能优化与调参实战5.1 线程池怎么配才不会冤枉背锅真实业务中线程池的配置永远是“看起来在用但不知道什么时候会爆”。我在ax调度里观察到的负载曲线是典型的锯齿状任务成批到达时线程池一下冲到峰值业务低谷时段又几乎全部空闲。假如给最大线程数设置一个过大的值比如64在网络带宽和下游连接数有限的情况下跑起来的效果反而不如16个线程。因为每个线程都在争抢同一个下游连接池大部分时间花在线程等待和上下文切换上。最稳的调参方式是先拿一个固定的任务批量做压测压测目标不是“每秒钟能拉多少任务进线程池”而是“下游接口可承载的最大QPS是多少”。比如你的下游接口能扛住400 QPS任务平均耗时200毫秒那线程数基准就可以粗略估算为400 * 0.2 80但这只是一个上限参考实际生产建议打六折留出buffer给其他调用方。ax调度默认不把最大线程数调满而是留出30%水位就是为了防止突发流量打满线程池后整个worker模块出现连环雪崩。另一个从线上事故里学到的心得必须给线程池设置一个监控开关。通过定时记录activeCount、queueSize、completedTaskCount三个指标能够提前判断任务是否积压。当queueSize连续一分钟超过队列容量一半时说明消费速度跟不上生产速度这时候要看的不是线程池而是下游到底哪个环节慢了。这条排查思路救了我好几次每次问题根源都不在线程池本身要么是数据库连接池打满要么是第三方接口超时时间设得太长。5.2 高峰期积压任务的三层处理策略先定义什么是积压任务已经到点进入Redis队列但worker线程消费不过来导致队列长度持续上升。ax调度的第一层策略是“削峰”把最耗时的业务任务分批分片不是说所有任务都必须绑在同一个时间点触发。比如每天凌晨3点的数据统计任务把全量数据按用户ID哈希分成16片每片间隔5秒触发这样下游数据库和缓存的压力被均匀摊开整体完成时间反而更早。第二层策略是“限流提交”。触发端在批量投递任务到执行队列前先查看当前队列长度如果超过阈值就把剩余任务放入本地缓冲队列每次只放行固定比例。这相当于给水管装了一个限流阀底层扛得住多少就放多少进来不会因为触发端集中爆发造成下游雪崩。有很多工程问题不是靠队列本身解决的而是在生产者那端就控制了节奏。第三层策略是“流量兜底”。如果积压已经发生且持续了很久就要考虑直接把局部慢任务的路由调配到其他空闲执行节点。ax调度在集群部署模式下执行节点会周期性上报自身的队列水位和线程池活跃度调度器据此把新任务分发到更空闲的节点。这个能力不是初期必备的单机模式先跑通之后再在集群模式下加这一层复杂度会低很多。三层策略叠加下来ax调度面对瞬时大批量任务时不会像裸奔一样直接炸。实测在一次双11预售场景的压测里原本单机每秒只能消化600条任务通过分片削峰和队列限流这两个策略之后稳定提升到1800条每秒下游数据库的抖动也显著减少。调优时先改分片逻辑再看队列限流一般就能解决绝大多数积压问题。6. 常见问题与排查技巧实录6.1 任务“消失”了到底去哪了新手最容易遇到的现象是“我明明注册了任务也到了触发时间但啥也没执行”。这时候不要碰Redis不要看时间轮日志第一条排查命令永远是去MySQL查task_instance表看这条记录当前是什么状态。如果实例记录明确存在且状态是SUCCESS说明执行端已经跑完了业务回调却报错了定位方向是handler内部逻辑如果实例记录压根没有说明任务从未被正式触发问题出在注册或时间轮装载环节如果实例记录存在但状态是CREATED说明触发环节卡住了大概率漏进补偿扫描器的时间窗等下一轮扫描就会自动补上。在排掉上面三类可能性之后剩下最隐蔽的情况是“任务被同一个业务标识的重复定义覆盖了”。比如一个订单关闭任务你既有按30分钟延迟配置的版本又有按45分钟延迟配置的版本新版本注册时会按taskCode覆盖旧版本导致部分订单在实际运行时拿到的是新配置看起来就像一单任务“消失”了。这不是调度器的问题是业务配置治理的问题所以规范里一定要用一个的任务码唯一映射一个业务场景不允许一个业务存在多个相同任务码的定义。6.2 重复执行问题定位链路重复执行是调度系统的二等公民问题。ax调度只在两个位置设计了防重逻辑任务实例状态检查和执行锁。如果线上依旧出现重复执行排查一定要先把“两个位置”的日志时间线拉出来对比某个执行ID是否同时出现了两次合法的锁请求还是说第一次执行超时导致锁自动释放后另一轮补偿触发了。有一种常见成因是执行超时配置太短比如业务任务实际耗时50秒但max.execute.ms只给了30秒执行线程被超时中断但业务方法内部压根不响应中断继续在后台跑直到自然结束。同时状态已经标记失败补偿扫描器又会重新生成执行导致前后两笔业务逻辑重叠。解决办法是把超时时间调长更稳妥的做法是在业务代码里增加“执行开始时间”的落库标记真正的task handler在进入业务逻辑前先判断当前时间是否在允许执行的窗口内从而主动规避重复执行。还有一类重复来自时间轮推进逻辑的误用多个调度器实例同时加载了同一个任务定义如果没做好集群内的选举机制每个节点的时间轮都各自推进任务自然会被触发多次。ax调度的止损方案是在执行端统一用Redis锁做互斥但根治方案必须是调度器实例在启动时抢一把分布式leader锁只有leader节点能加载并推进时间轮其他节点处于热备状态。规模再大一点还可以引入一致性哈希将不同任务组分布到不同节点但高可用的绝对前提仍然是“同一时刻只有一个推进者”。6.3 任务时间不太准误差来源有哪些调度任务的时间误差可以归纳为四个来源触发误差、队列延迟、执行等待、重试间隔。触发误差来自时间轮的槽位跨度固定1秒最多误差1000毫秒。队列延迟来自Redis写入和worker拉取之间的时间差高峰期可能从几十毫秒膨胀到几秒。执行等待是任务进入worker后排在前的任务没跑完后续任务排队的时间这个误差在长任务场景下最明显。重试间隔则是失败重试场景中刻意等待的10秒。如果你发现线上任务时间整体偏移超过可接受范围按误差来源一个个排查。先看是不是高峰期积压导致通过队列长度监控即可验证再看是不是某个长任务把worker占住太久借助耗时统计找出拖后腿的handler最不应该先怀疑的是时间轮精度因为它在固定1秒跨度下的表现几乎恒定。系统性的实践是让业务对时间精度建立预期秒级任务不要期待精确到100毫秒分钟级任务要预留至少1~2秒的安全裕度。把调度时间当作“近似触发时间”业务逻辑再自行判断“是否已超过截止时间”会比一味追求零误差可靠得多。6.4 故障速查表高频问题一页纸整理一份高频问题对照表方便你在踩坑时快速定位。表格里不追求穷举只覆盖真正的日常疑难问题每项都来自实战记录按出现频率排优先级。故障现象优先排查项兜底处理方案任务到点没执行查task_instance实例状态等待补偿扫描器补扫最坏情况手动触发一次任务重复执行查执行超时时间与锁状态日志加执行窗口校验彻底解决需完善leader选举时间延后较多查Redis队列长度与worker积压调大worker线程数或启用分片削峰调用下游失败后重试仍失败查下游是否恢复、重试间隔是否过短调大重试间隔、配置熔断降级策略服务重启后任务丢失查启动对账逻辑是否生效确认服务启动时执行了SchedulerClient的加载方法调度器集群脑裂查多节点是否同时推进时间轮引入leader选举或一致性哈希线程池队列打满查下游慢调用与长任务占比加限流提交、拆分长任务平时监控告警最少要覆盖三类指标延迟最久的任务、队列积压数量和实例失败率。这三项能把绝大多数隐患提前暴露在爆发前。当初把调度模块的告警接入企业微信群后第一次实战就发现一个数据同步任务在下游数据库切换主从那几天失败率激增到35%排查后发现是连接池里的旧连接没有自动回收重试也救不回来最终给执行器增加了连接池预热和断线重连逻辑才稳住。最后分享一个个人经验调度引擎这个小东西技术方案在不同团队间大同小异真正拉开差距的是“任务状态流转是否每一步都能被追踪”。如果把任务定义、实例、执行日志三块数据维护好这套系统再运行两年也不会让你头疼。调度的复杂度永远不在算法上而在你愿不愿意把每个中间状态都设计成可观测的持久数据。
分布式任务调度引擎核心设计：时间轮、MySQL存储与可靠触发
1. 从一个内部代号聊起ax调度到底是什么“ax”这名字我第一次听到时也愣了下组里脚手架工程起了个代号叫ax后来做的任务调度模块沿用这个名字内部就叫“ax调度”。它不是某个开源框架的封装也不是标准行业术语而是我们自己的一套轻量级定时任务与延迟消息调度引擎。如果你在项目里见过类似“每天晚上三点同步订单状态”“用户下单三十分钟后未支付自动关单”这种需求那你就在跟ax调度这类东西打交道。先定义清楚它做什么ax调度负责把“某个时刻要做的事”在正确时间点触发并且把触发后的任务可靠地派发给执行端。听起来像“定时任务框架”但传统定时任务和真正的调度引擎之间差别不小。多用cron表达式挂任务的场景里服务重启、任务积压、分布式重复执行都是让人头疼的问题。ax调度在设计时重点解决了三件事时间到点后任务不丢、同一个任务在集群中不重复执行、执行失败后能自动补偿。适合谁来用后端开发、平台工具链维护者、架构偏执狂只要你在做ToB系统、电商交易链路、订单履约流程搞一套内部分布式调度是迟早的事。这套东西不依赖中间件有多高级MySQL Redis 一套服务进程就能跑起来。后面我会把关键设计、核心代码思路、踩过的坑都摊开讲按我的实操经验一步步带你把调度模块搭起来。我引入这个话题想表达的是调度引擎最核心的不是“到点触发”这个动作而是“触发之后如何保证任务状态可靠流转”。ax调度在这块的取舍很接地气不搞复杂的编排DAG但把单层任务触发、重试、幂等、监控做扎实了反而比一堆花哨功能更耐用。接下来我从架构选型开始讲讲为什么ax调度会走“轻量自研”这条路。2. 架构设计与选型思路2.1 实现调度任务的四代演进路线先说一个常见的后端设计误区很多人一上来就喜欢分布式事务、消息队列、工作流编排全家桶其实多数业务场景根本撑不起那么重的架构。ax调度在设计之前我对比了四代调度模型真实项目里踩过不同代际的坑后来才确定哪一种组合最合适。第一代是进程内Timer/ScheduledExecutorService只能单机用服务一重启内存里的调度就全丢了。第二代是引入xxl-job这样的现成中间件功能全但依赖注册中心、需要管理调度中心和控制台团队维护成本不低。第三代是“消息延迟队列 消费者触发”模式用RocketMQ延迟消息或Redis键空间通知问题在于前端触发到后端消费之间链路长时间误差动不动就是分钟级。第四代是ax调度的方案数据模型用MySQL存任务明细和状态触发核心在服务端用时间轮维护内存级倒排索引到点后把任务写入Redis延迟队列再由执行器线程池拉出并执行。这条演进路线反映的是“触发与执行分离”的设计哲学。触发层负责算时间执行层负责干体力活。把两者拆开之后每层都能独立扩缩容任务触发不依赖执行端是否健康执行端挂掉之后任务也不会只停留在内存里。ax调度在第四代方案里还加了补偿扫描器每隔几十秒扫一次MySQL里“已到触发时间但迟迟没进入执行状态”的任务保证哪里有漏网之鱼都能捞回来。2.2 存储选型别一上来就迷信Redis我见过不少团队做调度时所有状态直接往Redis里塞理由是“快”。但任务调度跟缓存场景不一样任务不是读了就完事的它需要生命周期、审计日志、失败原因留痕。如果核心信息只在Redis里一旦Redis宕机或者被淘汰所有任务状态全部归零这个代价比多几次数据库IO高得多。ax调度最终选择了MySQL为主存储Redis做辅助队列。MySQL里三张表撑起全部逻辑task_define存任务定义、task_instance存每次触发产生的任务实例、task_log存执行日志。Redis里存两类数据一类是即将到期的任务ID集合用有序集合按触发时间戳排名另一类是分发中的执行消息用列表结构暂存。MySQL保住最终可靠状态Redis保住触发的实时性。哪怕是Redis全挂最坏结果只是补偿扫描器多花几十秒把任务补触发业务侧几乎无感。这么设计还有个好处运维排查问题时可以直接对着数据库和执行日志看不用在缓存里翻半天。遇到任务没执行这种事第一反应永远是“去MySQL查task_instance的状态”而不是“去Redis的key里捞数据”。这个习惯能够让定位时间缩短一半以上。2.3 为什么核心触发用时间轮而不是死循环扫库很多轻量调度方案是直接ScheduledExecutorService每隔几秒扫一次数据库把到点任务捞出来。这种方案在小规模场景下没问题但任务量上去之后每次全表扫描的数据库压力会非常恐怖。ax调度没有走这条路而是用了一个常驻内存的时间轮结构。时间轮的原理说白了像一个时钟拨盘拨盘分成多个槽位每个槽位对应未来一个时间刻度。任务注册时根据延迟秒数计算放进哪个槽位一个线程负责推进指针指针指向哪个槽位就把槽位里的任务统一取出来处理。不是扫全库只是取当前刻度对应的任务时间复杂度无限逼近O(1)。生活化类比就是餐厅叫号机等位的人按预估等候时长放进对应的号池叫号员到了时间点只从当前号池里叫人不会满餐厅喊一遍。实际落地时时间轮只存任务ID和触发时间戳不存任务详情内存占用非常有限。任务真正到点触发后执行器拿到任务ID再去MySQL加载完整定义这样时间轮的职责非常单一不跟业务逻辑耦合。刚开始实现时间轮时最容易犯的错是把任务详情全塞进去结果任务量大时内存直接顶不住后来统一改成存ID瞬间清爽很多。3. 核心机制与实操要点3.1 触发模块时间轮两大细节别写错第一细节是时间轮的槽位跨度。槽位跨度可以固定为1秒也可以动态调整。ax调度落地时我选择固定1秒跨度理由很简单业务场景里调度任务最小粒度就是秒级不管是订单超时关单的30分钟还是报表任务每天凌晨3点到秒就够了。如果你做的是毫秒级高频调度时间轮的存储和CPU开销会上去几个量级必须重新评估方案固定每秒一个槽位带来的误差在绝大多数业务中都能接受。第二个细节是关于“槽位中的任务如何处理”。ax调度在时间轮指针推进到某个槽位后不是直接同步执行任务而是先把任务ID批量写入Redis延迟队列。这个设计有两个考量其一任务执行过程可能比较慢如果直接在时间轮线程里执行业务逻辑时间轮推进就会卡住后面的任务全部延迟其二把任务投递给队列后执行端可以按自己的消费能力拉取形成天然的削峰填谷。你看到的代码结构是这样的时间轮线程只负责enqueue完全没有执行逻辑的痕迹执行端单独一组worker线程在队列中消费。实现时间轮时另一个容易踩的坑是“槽位计算越界”。延时小时数超过时间轮可覆盖范围时要么做多级时间轮要么把超长任务落入数据库扫描补偿逻辑中。ax调度选择了后者超过两小时的长延时任务不等内存时间轮直接依赖补偿扫描器这样内存时间轮拨盘长度始终可控不会因为一个周级任务导致整个轮盘溢出。3.2 执行模块worker线程模型的关键参数执行端是ax调度的体力活部分设计目标只有一个任务从Redis队列中拉出来后必须在有限时间内被处理完且不能因为并发度设置不当把下游依赖服务打挂。worker线程池的参数值得多花几句话讲清楚。核心线程数我用的是Math.max(4, 处理器核心数 / 2)最大线程数是核心线程数的2倍队列容量取1000拒绝策略用CallerRunsPolicy。这个参数组合来源于一次线上事故之前把最大线程数调到核心数4倍结果下游数据库连接池先顶不住一个本来只需要毫秒级响应的事务接口被打成长时间阻塞整个链路的P99从50ms飙到4秒。CallerRunsPolicy的作用是当线程池满且队列也满时新任务不抛出异常丢弃而是让提交任务的线程自己去执行。这个策略特别适合调度场景因为它天然带背压能力任务永远不会无声无息地丢最多就是触发端速度降下来等执行端消化完再把队列跑起来。实际运行中触发量再大也不能把执行端线程池无限调大宁可多等几秒也不能让下游承载不住。执行端还要做一层“任务超时保护”。整个执行过程包在一个future里设置一个自适应的超时时间默认30秒如果任务类型声明为“长任务”则抬到10分钟。超时后立即中断线程同时把任务实例状态置为失败。不写这层保护的话一旦业务代码里藏着慢SQL或者死循环worker线程会被占住不放越积越多最终线程池全被拖死。3.3 补偿机制失败重试与幂等设计调度里最怕的不是任务失败而是失败后任务被静默丢弃。ax调度补偿体系分成两个维度任务实例失败后的重试和时间轮漏触发后的补扫。先讲失败重试。任务定义里带有retryCount、retryIntervalSeconds两个字段默认分别是3和10。执行失败时不是立刻重试而是先把任务实例状态标记为RETRYING同时计算下一次执行时间重新塞进延迟队列。这里严格做到了指数退避之外的“固定间隔快速失败”由于大多数任务失败原因在短时间内无法恢复比如下游服务重启、依赖数据库主从切换所以固定间隔10秒给下游留恢复时间。如果你重试间隔设置太短一秒内连续重试三次大概率三次全失败然后进入死循环对下游造成持续的无效压力。再讲幂等。调度系统天然存在重复执行的可能执行端超时了但业务其实已经成功补偿扫描器又触发一次接着就要考虑同一任务实例是否会被执行两次。ax调度的做法是每个任务实例有一个唯一执行ID执行端拿到任务后先通过Redis执行SETNX写入lock:exec:{executionId}只有拿到锁才能执行。每次真正执行前还会在MySQL里检查任务实例状态如果已经是SUCCESS就跳过。这样哪怕网络抖动、消息重复投递也不会产生重复的订单回写或者重复发短信。补偿扫描器是最后一道安全网只维护一个简单的逻辑轮询task_instance表中状态为CREATED但触发时间已过去 60 秒以上的记录将其重新提交到触发通道。这个扫描器运行频率很低60秒跑一次每次用批量查询限制一次最多捞500条不会对数据库产生大压力。4. 上手实操5分钟接入一个业务任务4.1 环境准备与依赖引入ax调度不算一个开箱即用的开源中间件而是工程内部封装的模块。你在自己项目中复现这套东西时环境需要一个MySQL数据库一个Redis实例版本无硬性要求以及一个Java服务进程。保证这三个基础模块都有之后就可以在工程的pom.xml里引入调度SDK一般的做法是打成内部依赖包用ax-scheduler-core命名。运行时需要的表结构其实不多但别偷懒精简。我强烈建议task_define和task_instance两张表分开建。以前为了少建一张表把任务定义跟每次执行状态混在一起最终的结果就是排查问题时根本分不清“这个任务本来长什么样”和“它这次执行得怎么样”。分开后逻辑非常清晰定义表里只放任务编码、cron表达式或者延迟秒数、重试参数、回调的bean名称实例表里放执行ID、任务编码、预期触发时间、实际触发时间、执行状态、错误信息、重试次数。Redis不需要初始化额外结构直接用普通的key操作即可但建议提前在配置里规划好延迟队列和锁的key前缀比如ax:delay:task和ax:lock:exec避免跟其他业务key冲突导致误删。到这里基础设施就绪。4.2 定义一个任务并注册到调度器核心操作分三步。第一步写一个业务执行器实现统一的TaskHandler接口。接口里只有一个方法handle(TaskContext context)你在这个方法里写自己的业务逻辑比如调用订单服务把超时订单置为关闭。第二步注册定义在数据库的task_define表中插入一条记录指定任务编码orderCloseTask延迟秒数1800重试次数3执行器bean名orderCloseHandler。第三步启动服务注入调度器客户端并调用loadTask把该任务的定时配置加载进时间轮。服务启动阶段会有一个对账动作检查数据库中已有的任务定义比内存中加载的任务多哪些自动补齐确保新加一个任务不需要重启整个集群。我实际用的注册代码大致长这样把关键条件说清楚SchedulerClient client SchedulerClient.getInstance(); TaskDefine define new TaskDefine(); define.setTaskCode(orderCloseTask); define.setDelaySeconds(1800); define.setRetryCount(3); define.setRetryIntervalSeconds(10); define.setHandlerBean(orderCloseHandler); client.register(define);注册完只是定义了任务具体要让它跑起来有两种方式一是立即调用client.trigger(taskCode)手动触发一次二是等下一次时间轮匹配。如果你的任务不是固定延迟而是带cron表达式的周期任务就改用define.setCronExpression(0 0 3 * * ?)同时内部会自动把cron拆解成下一次触发时间戳塞入时间轮。这个周期任务模式对写日报汇总、定时对账之类需求非常贴近。4.3 关键配置参数逐个拆解配置项不算多但每个都值得知道为什么这么设。我挑几个最容易改出问题的说明scheduler.scan.interval.ms补偿扫描器运行间隔作用于“漏触发后补捞”的频率。默认60000调小到10000会让任务恢复更快但会增加MySQL查询频率生产环境建议保持默认或15秒。scheduler.timewheel.tick.ms时间轮指针推进间隔默认1000。不建议低于500否则CPU空转明显任务秒级误差完全能接受。scheduler.worker.core.pool.sizeworker线程池核心线程数按前面Math.max(4, CPU核心数 / 2)设置即可。不要看着机器核数多就无脑调大线程上下文切换开销是隐形成本。scheduler.task.max.execute.ms单任务执行最大耗时默认30000。需要支持长任务的可以调大或者让任务实现方在定义里单独声明长任务类型。scheduler.batch.pop.sizeworker一次从Redis队列批量拉取的任务数默认100。调大可以提升吞吐但处理不过来时反而增加任务在worker内等待的时间。这套参数配好后基本不需要频繁改动真正需要调优的点是对高峰期积压任务的处理这个放在第5章说。5. 性能优化与调参实战5.1 线程池怎么配才不会冤枉背锅真实业务中线程池的配置永远是“看起来在用但不知道什么时候会爆”。我在ax调度里观察到的负载曲线是典型的锯齿状任务成批到达时线程池一下冲到峰值业务低谷时段又几乎全部空闲。假如给最大线程数设置一个过大的值比如64在网络带宽和下游连接数有限的情况下跑起来的效果反而不如16个线程。因为每个线程都在争抢同一个下游连接池大部分时间花在线程等待和上下文切换上。最稳的调参方式是先拿一个固定的任务批量做压测压测目标不是“每秒钟能拉多少任务进线程池”而是“下游接口可承载的最大QPS是多少”。比如你的下游接口能扛住400 QPS任务平均耗时200毫秒那线程数基准就可以粗略估算为400 * 0.2 80但这只是一个上限参考实际生产建议打六折留出buffer给其他调用方。ax调度默认不把最大线程数调满而是留出30%水位就是为了防止突发流量打满线程池后整个worker模块出现连环雪崩。另一个从线上事故里学到的心得必须给线程池设置一个监控开关。通过定时记录activeCount、queueSize、completedTaskCount三个指标能够提前判断任务是否积压。当queueSize连续一分钟超过队列容量一半时说明消费速度跟不上生产速度这时候要看的不是线程池而是下游到底哪个环节慢了。这条排查思路救了我好几次每次问题根源都不在线程池本身要么是数据库连接池打满要么是第三方接口超时时间设得太长。5.2 高峰期积压任务的三层处理策略先定义什么是积压任务已经到点进入Redis队列但worker线程消费不过来导致队列长度持续上升。ax调度的第一层策略是“削峰”把最耗时的业务任务分批分片不是说所有任务都必须绑在同一个时间点触发。比如每天凌晨3点的数据统计任务把全量数据按用户ID哈希分成16片每片间隔5秒触发这样下游数据库和缓存的压力被均匀摊开整体完成时间反而更早。第二层策略是“限流提交”。触发端在批量投递任务到执行队列前先查看当前队列长度如果超过阈值就把剩余任务放入本地缓冲队列每次只放行固定比例。这相当于给水管装了一个限流阀底层扛得住多少就放多少进来不会因为触发端集中爆发造成下游雪崩。有很多工程问题不是靠队列本身解决的而是在生产者那端就控制了节奏。第三层策略是“流量兜底”。如果积压已经发生且持续了很久就要考虑直接把局部慢任务的路由调配到其他空闲执行节点。ax调度在集群部署模式下执行节点会周期性上报自身的队列水位和线程池活跃度调度器据此把新任务分发到更空闲的节点。这个能力不是初期必备的单机模式先跑通之后再在集群模式下加这一层复杂度会低很多。三层策略叠加下来ax调度面对瞬时大批量任务时不会像裸奔一样直接炸。实测在一次双11预售场景的压测里原本单机每秒只能消化600条任务通过分片削峰和队列限流这两个策略之后稳定提升到1800条每秒下游数据库的抖动也显著减少。调优时先改分片逻辑再看队列限流一般就能解决绝大多数积压问题。6. 常见问题与排查技巧实录6.1 任务“消失”了到底去哪了新手最容易遇到的现象是“我明明注册了任务也到了触发时间但啥也没执行”。这时候不要碰Redis不要看时间轮日志第一条排查命令永远是去MySQL查task_instance表看这条记录当前是什么状态。如果实例记录明确存在且状态是SUCCESS说明执行端已经跑完了业务回调却报错了定位方向是handler内部逻辑如果实例记录压根没有说明任务从未被正式触发问题出在注册或时间轮装载环节如果实例记录存在但状态是CREATED说明触发环节卡住了大概率漏进补偿扫描器的时间窗等下一轮扫描就会自动补上。在排掉上面三类可能性之后剩下最隐蔽的情况是“任务被同一个业务标识的重复定义覆盖了”。比如一个订单关闭任务你既有按30分钟延迟配置的版本又有按45分钟延迟配置的版本新版本注册时会按taskCode覆盖旧版本导致部分订单在实际运行时拿到的是新配置看起来就像一单任务“消失”了。这不是调度器的问题是业务配置治理的问题所以规范里一定要用一个的任务码唯一映射一个业务场景不允许一个业务存在多个相同任务码的定义。6.2 重复执行问题定位链路重复执行是调度系统的二等公民问题。ax调度只在两个位置设计了防重逻辑任务实例状态检查和执行锁。如果线上依旧出现重复执行排查一定要先把“两个位置”的日志时间线拉出来对比某个执行ID是否同时出现了两次合法的锁请求还是说第一次执行超时导致锁自动释放后另一轮补偿触发了。有一种常见成因是执行超时配置太短比如业务任务实际耗时50秒但max.execute.ms只给了30秒执行线程被超时中断但业务方法内部压根不响应中断继续在后台跑直到自然结束。同时状态已经标记失败补偿扫描器又会重新生成执行导致前后两笔业务逻辑重叠。解决办法是把超时时间调长更稳妥的做法是在业务代码里增加“执行开始时间”的落库标记真正的task handler在进入业务逻辑前先判断当前时间是否在允许执行的窗口内从而主动规避重复执行。还有一类重复来自时间轮推进逻辑的误用多个调度器实例同时加载了同一个任务定义如果没做好集群内的选举机制每个节点的时间轮都各自推进任务自然会被触发多次。ax调度的止损方案是在执行端统一用Redis锁做互斥但根治方案必须是调度器实例在启动时抢一把分布式leader锁只有leader节点能加载并推进时间轮其他节点处于热备状态。规模再大一点还可以引入一致性哈希将不同任务组分布到不同节点但高可用的绝对前提仍然是“同一时刻只有一个推进者”。6.3 任务时间不太准误差来源有哪些调度任务的时间误差可以归纳为四个来源触发误差、队列延迟、执行等待、重试间隔。触发误差来自时间轮的槽位跨度固定1秒最多误差1000毫秒。队列延迟来自Redis写入和worker拉取之间的时间差高峰期可能从几十毫秒膨胀到几秒。执行等待是任务进入worker后排在前的任务没跑完后续任务排队的时间这个误差在长任务场景下最明显。重试间隔则是失败重试场景中刻意等待的10秒。如果你发现线上任务时间整体偏移超过可接受范围按误差来源一个个排查。先看是不是高峰期积压导致通过队列长度监控即可验证再看是不是某个长任务把worker占住太久借助耗时统计找出拖后腿的handler最不应该先怀疑的是时间轮精度因为它在固定1秒跨度下的表现几乎恒定。系统性的实践是让业务对时间精度建立预期秒级任务不要期待精确到100毫秒分钟级任务要预留至少1~2秒的安全裕度。把调度时间当作“近似触发时间”业务逻辑再自行判断“是否已超过截止时间”会比一味追求零误差可靠得多。6.4 故障速查表高频问题一页纸整理一份高频问题对照表方便你在踩坑时快速定位。表格里不追求穷举只覆盖真正的日常疑难问题每项都来自实战记录按出现频率排优先级。故障现象优先排查项兜底处理方案任务到点没执行查task_instance实例状态等待补偿扫描器补扫最坏情况手动触发一次任务重复执行查执行超时时间与锁状态日志加执行窗口校验彻底解决需完善leader选举时间延后较多查Redis队列长度与worker积压调大worker线程数或启用分片削峰调用下游失败后重试仍失败查下游是否恢复、重试间隔是否过短调大重试间隔、配置熔断降级策略服务重启后任务丢失查启动对账逻辑是否生效确认服务启动时执行了SchedulerClient的加载方法调度器集群脑裂查多节点是否同时推进时间轮引入leader选举或一致性哈希线程池队列打满查下游慢调用与长任务占比加限流提交、拆分长任务平时监控告警最少要覆盖三类指标延迟最久的任务、队列积压数量和实例失败率。这三项能把绝大多数隐患提前暴露在爆发前。当初把调度模块的告警接入企业微信群后第一次实战就发现一个数据同步任务在下游数据库切换主从那几天失败率激增到35%排查后发现是连接池里的旧连接没有自动回收重试也救不回来最终给执行器增加了连接池预热和断线重连逻辑才稳住。最后分享一个个人经验调度引擎这个小东西技术方案在不同团队间大同小异真正拉开差距的是“任务状态流转是否每一步都能被追踪”。如果把任务定义、实例、执行日志三块数据维护好这套系统再运行两年也不会让你头疼。调度的复杂度永远不在算法上而在你愿不愿意把每个中间状态都设计成可观测的持久数据。
