自研分布式任务调度引擎 ax：事件驱动与时间轮的工程实践

1. 从一段混乱的定时任务说起做后端有些年头的人大概率都经历过这样的阶段业务代码里到处散落着Scheduled注解一个电商项目里能找出四五十个定时任务。每天凌晨跑批的时候日志里全是任务重叠执行“同一订单被两个 Job 处理”的报错。我上一家公司就是这样每逢大促前夜运维同事就守在机房盯着任务调度面板生怕某个批处理卡死拖垮整个订单中心。当时我们先试过引入现成的分布式任务调度框架折腾了将近一个月却发现最痛苦的不是任务跑不起来而是几个硬伤没法绕过去一是任务量和调度频率稍高调度中心自身就成了瓶颈二是对任务之间复杂的依赖关系支持很弱一个订单支付后 5 分钟通知仓库发货的场景要写大量胶水代码三是无论你怎么调参多个节点抢同一个任务时总会出现偶发重复执行幂等逻辑越写越重。后来团队决定自研一套调度引擎代号就叫ax。从命名上看ax 取自 Async X核心诉求是极致异步、超高吞吐、毫秒级触发。现在这套调度引擎在线上稳定运行一年多承载着订单履约、库存同步、用户分群、对账跑批等上百个核心任务日均调度量超过 3000 万次。这篇文章就把我在设计、实现和运维 ax 过程中的经验完整拆出来从核心原理到落地配置再到典型事故排查尽量说透希望给正在做任务调度选型或自研的朋友一些参考。2. ax 的整体设计思路为什么不能继续用定时框架凑合2.1 从定时触发到事件驱动的转变传统定时任务框架的核心模型是 Cron 表达式——到了某个时间点就触发一次。这套模型在业务量小的时候够用但一旦任务变多、依赖变复杂问题会迅速积累。比如一个数据同步任务上游接口的数据通常凌晨 1 点才稳定可用Cron 写 1 点执行今天上游延迟到 1 点 20 分怎么办要么任务失败重试要么让任务内部轮询等待。前者浪费调度资源后者把业务逻辑和调度逻辑搅在一起。ax 从一开始就换了一个思路调度不负责猜时间只负责在条件满足时把任务送出去。任务触发来源可以是 Cron 到点、上游任务完成回调、外部请求推送、数据积压水位触发这几种来源统一抽象成事件。调度引擎维护一张事件队列消费者拿到事件后根据任务定义去匹配触发规则。这个设计让订单支付 5 分钟后通知仓库变得非常自然支付完成事件进入队列延迟 5 分钟投递到任务执行器而不是靠某个每分钟扫描一次的定时器轮询数据库。2.2 三级解耦调度器、执行器、注册中心各干各的ax 的架构上做了彻底的三级拆解。调度器Scheduler只负责维护事件的优先级队列、生成调度指令执行器Worker只负责接收指令、执行任务回调、上报状态注册中心Registry负责管理任务元数据、执行器节点列表、任务与执行器的路由关系。三者之间全部通过内置的轻量级消息通道通信没有共享数据库状态。这样做的好处非常明显。调度器是无状态的可以水平扩展执行器可以独立重启不影响调度器注册中心即使短暂不可用调度器也能依靠本地缓存继续工作一段时间。对比原来用数据库行锁抢任务的方案没有任何高频轮询和锁竞争单次调度的资源开销小了一个数量级。实际压测中一台 4C8G 的调度器节点可以支撑每秒 2000 次以上的任务触发而使用数据库锁的方案同配置节点每秒能稳定处理的调度量往往不到 300 次差距就出在锁竞争和连接开销上。2.3 时间轮加分层存储内存与磁盘的配合任务调度最常见的场景是延迟一定时间后执行。ax 没有直接用数据库轮询或传统延迟队列而是采用了时间轮Timing Wheel 分层存储的方式。时间轮驻留在内存中负责秒级和分钟级的短延迟任务超过分钟级的长延迟任务则落盘到本地 KV 存储中由后台线程在合适的时机重新装载回时间轮。这个设计是借鉴了网络框架中连接超时管理的思路把高频短延迟保留在内存把低频长延迟下放到磁盘。分层的好处是既保证了短延迟任务的触发精度又不至于让所有时间刻度都挤在内存里。我们的触发精度实测可以控制在 10 毫秒以内而原来使用数据库轮询时的触发误差经常到秒级甚至分钟级。对于订单超时自动关闭这类业务10 毫秒和 1 分钟的差异直接决定了用户在前端感知到的等待时间是否合理。3. 核心机制拆解任务、事件与一致性3.1 任务定义要语义化不是一行 Cron 就完了我在设计 ax 的任务模型时刻意避开了任务就是一个 Cron 表达式的简化。每个任务在 ax 里是一份完整的语义化描述包括触发条件、执行策略、超时时间、重试规则、资源配额、所属业务域。举个例子task: name: order_sync_warehouse domain: fulfillment trigger: type: event event: order.paid delay: 300s timeout: 60s execution: worker_tag: warehouse max_retry: 2 retry_interval: 30s allow_concurrent: false resource: max_running: 10这份配置表达的意思是当订单支付成功事件触发后延迟 300 秒投递到warehouse标签对应的执行器执行超时 60 秒则判定失败最多重试 2 次重试间隔 30 秒同一个订单同一时刻只允许一个任务实例在跑。这种配置方式把调度策略和任务逻辑彻底分离业务开发不用关心任务底层怎么分发只负责填写自己的业务执行代码。Cron 表达式也没有被抛弃而是作为一种特殊的事件生成器存在。系统内置一个 Cron 事件源每秒扫描一次把到期的 Cron 表达式转换成对应的事件写入事件队列。这样整套模型就统一了无论是定时任务还是消息触发任务对执行器来说都是收到一个任务指令然后干活处理逻辑完全一样。3.2 事件去重与有序性任务不丢不重不乱的基石事件驱动模型必须解决三个问题不丢、不重、不乱。不丢靠事件持久化ax 在事件进入队列前先写入预写日志Write-Ahead Log确认落盘成功才返回生产者不乱靠分区顺序同一个业务主键比如订单号的事件永远进入同一个分区消费者按顺序处理不重是最难的因为消费方执行完任务后可能还没来得及上报状态调度器就认为任务超时并重新投递了。这里我踩过一个很深的坑最初版本去重依赖任务执行器自己实现幂等结果线上出现了一次重复发券事故——补偿任务把已经发送过的优惠券又发了一遍。后来 ax 引入了两层去重机制调度器侧根据事件唯一 ID 做投递去重同一事件不会在短时间内投递两次执行器侧根据任务实例 ID 结合 Redis 做执行去重同一个任务实例在有效期内只能被成功执行一次。两侧都加了防重线上重复执行的问题才真正收敛。3.3 分布式锁的正确用法只锁资源不锁任务很多调度框架在任务触发时先拿一把分布式锁防止多个节点同时执行同一个任务。ax 也用了分布式锁但锁的作用域刻意做得很窄只锁执行资源不锁任务本身。什么叫锁资源就是一个执行任务前先判断该任务在所有节点上的总运行数量是否超过配额超过则等待这个判断和加扣的过程用锁保护防止并发时超跑。什么叫不锁任务就是一个任务来了不会傻等一个全局锁释放而是立即投递给空闲的执行器节点。实际上这个设计主要是为了应对突发流量。比如上游大批量数据同步任务同时到达如果全局锁保护任务触达会导致任务全部排队处理延迟飙升。而只控制每个任务最大并发数让不同任务并行执行系统吞吐反而更高。从实际效果来看ax 的高吞吐能力一半靠时间轮事件队列另一半就靠这个窄锁策略锁的范围越小系统能并行处理的事情就越多。4. 实操记录把 ax 调度引擎跑起来4.1 部署形态与基础配置ax 本身的部署非常简单因为它的核心不依赖外部存储注册中心使用 Raft 协议在三个节点间同步元数据。我建议的最小部署是三台调度器加三台注册中心执行器按业务域横向扩。调度器最关键的配置是事件队列的分区数和预写日志的刷盘策略# scheduler.yaml 核心配置 scheduler: port: 9770 event_partitions: 16 wal_flush: batch # batch 批量刷盘性能优先 timing_wheel_ticks: 512 timing_wheel_interval: 10msevent_partitions决定事件并行处理的粒度一般按节点的 4 到 8 倍设置。wal_flush有两个选择batch和fsync。如果业务能容忍极端情况下丢失最近几秒的事件用batch如果是资金对账类的任务建议用fsync每次写入强制落盘性能会低一些换来的是更高的可靠性。真实场景中我们大部分任务用batch只有少部分核心链路任务单独起一个高可靠调度域用fsync。4.2 执行器接入三行代码执行器的接入设计走的极简路线在 Spring Boot 工程里加一个注解即可Component AxTask(taskName order_sync_warehouse, workerTag warehouse) public class OrderSyncWarehouseTask implements AxTaskHandler { public AxTaskResult execute(AxTaskContext context) { // 业务处理逻辑 String body context.getPayload(); boolean ok syncWarehouse(body); return ok ? AxTaskResult.success() : AxTaskResult.fail(sync error); } }任务被投递过来时ax 执行器会根据workerTag找到对应的 Bean调用execute方法。这里比较贴心的一点是AxTaskContext里除了带业务负载还带了一个attempt字段表示当前是第几次重试。业务侧可以根据attempt判断是否需要做更保守的处理比如第 2 次重试时可以切换到备用通道而不是每次都盲目重跑。我建议所有任务处理逻辑都遵循小任务原则一个任务只干一件事大任务拆成多个小任务通过编排串联。ax 支持在任务配置中声明depends_on比如库存快照生成依赖订单数据抽取完成调度器会检查前置任务的全部实例状态全部成功后才投递下游任务。没有这个能力时你写代码要自己轮询上游任务状态有了编排能力这层胶水代码彻底删掉了。4.3 压测数据与容量规划参考部署并跑通后我做的第一件事是压测。模拟环境是三台调度器4C8G、三台注册中心、十台执行器任务粒度为 1 分钟延迟触发。压测结果显示单调度器峰值可以达到每秒 2500 次投递投递延迟 P99 是 35 毫秒P999 是 120 毫秒。这个水平应对大部分业务系统的日常调度需求都足够了。如果要更高吞吐横向加节点即可调度器无状态扩展几乎没有上限。这里的容量规划经验公式是每 1000 次/秒的投递量配置一台 4C8G 调度器执行器数量则看任务耗时而定假设单个任务平均耗时 200 毫秒单执行器每秒能处理 5 个任务那么 1000 QPS 的调度量就需要 200 个执行器实例。实际中不可能所有任务都同时到达按高峰值的三分之一规划即可。5. 真实环境里的棘手问题与排查实录5.1 现象部分任务在高峰期延迟飙升第一个生产事故出现在上线后第二周。当时是大促前夕流量开始上涨监控发现部分任务延迟从 10 毫秒飙升到 300 多毫秒而且持续了十几分钟才自行恢复。排查时我第一反应是调度器负载过高但看监控 CPU 和内存都平稳。又怀疑是执行器处理不过来积压了事件后来发现执行器侧队列空转问题出在调度器侧的事件分区分配上。定位过程比较曲折。一开始确实怀疑是磁盘 IO 抖动因为批量刷盘在高并发下磁盘压力会陡增。我看了预写日志的写入延迟确实有毛刺但不足以解释几十倍的延迟增长。逐层看完事件队列、时间轮、投递线程池三个环节后才在一段日志里看到某个分区消费线程触发了垃圾回收——GC 停顿导致该分区的事件积压而分配到其他分区的事件是正常的。原因是某个分区的事件里混入了几千个负载很重的任务这类型任务会把后续所有事件堵住。解决办法是给不同重要级的任务分配不同的分区组让重负载任务不影响普通任务。这里也讲点经验排查延迟问题不能只看平均延迟要看分位延迟和分桶延迟P99、P999 能暴露少数分区出问题的时间点。5.2 现象任务重复执行幂等策略失效另一个让我印象深刻的事故是缓存数据更新任务重复执行导致用户看到临时数据错乱。前面的两层去重机制虽然挡住了大部分重复投递但有一种情况挡不住任务执行到一半执行器节点宕机重启此时调度器判定任务超时并重新投递到另一个节点而原节点其实已经完成了数据库写入只是状态没有上报。这种情况下业务数据库里数据已经是对的但缓存更新又执行一遍由于业务逻辑不是天然幂等出现了覆盖问题。这类问题本质上不是调度器能完全解决的而是需要业务侧配合。ax 提供了一把实例租约锁任务开始执行时先尝试获取租约拿到租约后写入本次执行的时间戳标识如果任务真正执行完成后发现租约被抢占说明有另一个实例已经执行过当前实例直接丢弃结果。这是一个通用方案我强烈建议所有执行器接入。接入后这一类半执行完成的重复问题被彻底避免虽然释放租约时还有极端情况但实践下来已足够可靠。5.3 现象任务依赖闭环死锁不触发还有一次是业务组反馈订单通知下游任务突然不跑了一直处于等待状态。我去看任务依赖关系发现一个典型的新手错误任务 A 配置了depends_onB同时 B 也配置了depends_onA。这是一个环形依赖调度器检测到这个环就不投递下游事件了但任务状态显示在等待表面上看起来一切正常。这种情况下调度器做得比较务实不做隐式解环而是直接把环在页面上高亮标注为异常。对于大型系统里的任务编排人眼很难检查出竞争条件我建议在创建任务时加一个依赖深度校验超过 10 层的依赖链也要告警因为过深的链意味着链路上任何一个环节抖动都会导致末端任务延迟被放大。环形依赖和超深链路是编排功能上线后最容易遇到的问题尽早发现比事后调试要省得多。5.4 常见问题速查表现象可能原因排查手段解决方案任务延迟飙升但 CPU 空闲单个分区被重负载任务阻塞看每个分区的消息积压和消费耗时按任务重要级拆分分区组任务偶发重复执行执行器宕机重启状态未上报查看执行器重启日志与任务实例状态接入实例租约锁任务一直等待不触发任务依赖形成环形依赖检查依赖关系图看是否有关闭环去掉闭环依赖链路精简调度器频繁 Full GC时间轮中短延迟任务过多内存碎片看 GC 日志和事件队列长度调大分片数量长延迟任务下沉磁盘执行器收到任务但处理慢业务线程池满任务内再发同步请求等待看执行器线程池队列和依赖的服务耗时拆分任务粒度业务侧增加超时熔断6. 一番对比后为什么最终选择自研 ax6.1 主流开源任务调度框架的短板在设计 ax 之前团队里有人提出直接用现成的开源调度平台确实省事。但我盘点了一圈后发现它们各自的边界很明显。Quartz 单机能力很强但天生不擅长分布式集群集群模式下靠数据库锁做触发量一上去就出现严重性能拐点XXL-Job 适合中小团队快速接入管理界面成熟不过调度器和执行器的耦合度偏高对事件模型和复杂拓扑编排的支持比较弱Elastic-Job 用了 Zookeeper 做分布式协调在大规模任务场景下如果 ZK 抖动整个调度集群都要跟着抖。它们的共同问题是核心模型都是定时触发 任务分片更适合批处理场景而不是高吞吐的事件型任务。可现在的业务系统里用户操作后延迟触发“上游完成事件驱动下游”这类需求占比越来越高用定时触发去模拟事件触发绕路而且费劲。6.2 自研的取舍与收获自研 ax 的取舍很明确放弃开源项目的生态和文档换取完全可控的调度模型和极致的性能空间。这个选择不是所有团队都适合如果任务量在每天百万级以下以 Cron 为主、事件调度为辅我仍然推荐直接用开源方案省时省力。但如果你已经遇到了三个信号——任务调度量日破千万、大量依赖触发和延迟触发需求、频繁被重复执行问题折磨——那么自研一套调度能力投入产出比是划算的。ax 这套引擎我们从立项到核心跑通花了大约六周后续边接入业务边打磨又用了两个月。现在回看真正值钱的不是把任务按时触发这么简单而是靠事件模型统一了定时任务、延迟任务、依赖任务三种形态让研发在写业务逻辑时不用再关心调度这层的事。团队内部现在新增一个任务平均能在半个小时内接入并上线。7. 运营 ax 一年后我的实际体会与建议调度引擎这类基础组件稳定运行只是及格线真正的挑战是适应业务形态的变化。我在 ax 上线后做的最大一次调整是把事件队列从固定分区改成动态分区这个改动挽回了每个大促高峰期调度器节点数量需要临时扩容时分区重新分配导致的延迟抖动。如果一开始就用固定分区每次扩容调整都要停机维护这种灵活性的内在价值是压测数据看不出来的。另外想给计划做调度引擎自研的团队一句实在话先把事件的存储和去重做扎实再去想花哨的编排功能。调度框架表面上是在算时间本质上是在处理可靠性和一致性的边界问题。我们早期把精力过多放在 Cron 表达式解析和任务编排界面上结果上线一周就被两个重复执行事故打回原形。后来集中精力把事件日志、去重、租约这套底子做稳一切才真正顺起来。最后分享一个小技巧ax 的调度日志一定要记录事件 ID、任务实例 ID、执行节点、执行耗时这四个字段并且是结构化输出。排查线上问题的时候这些字段的价值无可替代。我见过太多团队调度日志只是打了一句task executed出了事故连哪次执行成功、哪次执行失败都对不上账。好的日志设计平时看着不起眼出事的时候能省下半天查证时间这两条信息谁用谁知道。