1. 从ax到ax调度这个听起来很简短的名字到底藏在什么需求背后我第一次听到ax调度这个词是在一个技术群的闲聊里。有人问你们定时任务用的什么框架下面冒出来一句ax调度。我当时第一反应是又双叒叕来了个xx-job的变体。结果聊深了才发现这不是单纯的任务调度而是一套把任务调度、资源分配、执行器管理揉在一起的综合方案。先给下定义ax调度是一套面向分布式场景的轻量级任务调度与执行框架。它解决的不只是某个cron表达式能不能按时跑起来这种基础问题而是把一批任务怎么注册、怎么分配、怎么执行、怎么追踪、怎么容错做成了一条完整的链路。你可以把它理解成一个快递中转场调度中心是分拣台执行器是快递员任务就是包裹。分拣台决定哪个包裹交给哪个快递员快递员拿到包裹去派送并把结果回传给分拣台。如果快递员突然请假分拣台还要知道怎么把包裹重新分配给其他人。这个框架的核心价值可以拆成三部分任务调度什么时候跑、资源调度让哪台机器跑、状态调度跑挂了怎么办。如果你只是需要单机定时任务Linux自带的crontab就够了如果你需要微服务之间互相调度的能力或者你的业务已经拆成了几十个服务每个服务里都有需要指定时刻执行的任务那么一套独立的调度系统就非常必要了。ax调度最合适的场景就是这种任务多、机器多、调用关系复杂的后端环境。适合谁来参考我建议这样判断如果你当前的项目里定时任务还散落在各个微服务里通过Scheduled直接硬写调度时间一多就开始管理混乱如果你需要把任务从一个节点平滑迁移到另一个节点但又不想改业务代码如果你是运维同学需要同时监测几百个任务的执行成功率和超时情况——那你非常适合花点时间把ax调度这套思路吃透。就算最终不采用它理解它背后的方案对你的架构选型也有帮助。写这篇文章前我又把ax调度的源码和文档翻了一遍同时也回想了之前基于Quartz和XXL-JOB的老项目发现这类系统在实现上有很多共性也有很多坑是不踩一遍根本发现不了的。下面我按从设计到落地再到排障的顺序把我这几天的实操过程完整记下来希望能帮你少走一些弯路。2. 先想清楚再动手ax调度的整体设计思路2.1 为什么不能用每台机器自己跑cron来代替很多团队最开始都是这样干的业务服务里直接写Scheduled(cron 0 0 2 * * ?)数据库也直接连数据也直接算。这在单机时代没什么问题但一旦服务部署到多个节点同一个定时任务就会在每个节点上同时执行一遍。如果你的任务是统计前一天的订单数据并生成报表那你会得到三份一模一样的报表其中两份是脏数据。解决办法看起来也简单加个分布式锁。比如基于Redis的setnx抢到锁的节点才执行。但锁的过期时间怎么设任务执行时间超过锁的过期时间怎么办任务节点宕机后锁没有释放怎么办这些问题一个个追问下去你会发现最后还是需要一套专门的调度系统来做谁能执行、什么时候执行的决定。ax调度的思路是把决定和执行彻底分开调度中心负责决定执行器只负责执行。这样任何执行节点宕机、扩容、缩容都不会影响调度逻辑的正确性。2.2 核心模块划分与一次完整任务的处理流程从宏观视角来看ax调度由两个角色组成调度中心admin和执行器executor。调度中心是一个独立部署的Web应用负责管理任务定义、触发调度、记录日志、监控执行器状态。执行器则是嵌入到你的业务服务里的一个组件它启动后会自动向调度中心注册并暴露一个HTTP端点用于接收调度指令。一次任务的完整生命周期大概是这样的任务创建在调度中心里填写josn配置包括任务名称、cron表达式、执行器分组、路由策略、失败重试次数等。调度触发调度中心的调度线程池按时间轮询把到期的任务变为待执行状态。路由分配调度中心根据路由策略比如轮询、一致性哈希、故障转移从注册表里选出一个执行器实例。任务下发调度中心通过HTTP调用执行器的回调接口把任务ID和业务参数传过去。业务执行执行器收到请求后用独立的线程池运行任务处理器执行真正的业务逻辑。结果上报执行器在任务结束后把执行状态和时间戳回传给调度中心调度中心记录到日志表。这个流程和我之前用过的XXL-JOB非常像但ax调度的几个细节不太一样。比如它的执行器注册不是简单的心跳上报而是带着一组环境标签。什么意思呢你可以在一个执行器分组里继续打上envprod、regionhz这种标签调度路由时就能精准把任务发到指定环境或指定区域的机器上这在多机房部署时非常有用。2.3 为什么选调度中心执行器而不是执行器之间互相通信有同学可能会问为什么不直接让各个执行器之间通过消息队列来传递任务非要造一个中心我的理解是中心化带来的可观测性收益远大于单点风险。调度中心虽然是个单点但可以通过部署多个实例依赖数据库锁来保证高可用。更重要的是所有调度状态都汇总在中心任务列表、执行日志、失败告警都能在一个界面里查看。这对运维来说太关键了。我见过很多用MQ做任务分发的项目任务一多根本说不清某个任务到底有没有触发、在哪台机器上执行的、为什么失败了。因为消息一旦发出去如果没有完善的追踪链路基本等于失控。ax调度的中心化设计让查询任务执行历史变成了一次简单的数据库查询。不过成也中心败也中心调度中心一定要做好持久化和告警机制。我下面会专门讲这块的坑。3. 核心机制拆解调度策略、路由策略与任务生命周期3.1 任务怎么注册执行器启动时的自描述上报执行器启动后会向调度中心发送一个注册请求。注意这里不是简单的我上线了而是带着一组能力描述信息包括执行器名称、IP端口、所属分组、环境标签、最大并行执行数量、线程池配置。调度中心收到后会写入注册表并定期检查心跳。如果你在本地调试可能会遇到执行器一直显示离线的情况。常见的原因是IP写错了。服务器可能有多个网卡InetAddress.getLocalHost().getHostAddress()拿到的未必是你希望暴露出来的那个内网IP。ax调度在配置里有个ax.executor.ip选项建议部署时显式指定别依赖自动探测。另一个原因是防火墙拦了执行器暴露出来的端口。调度中心去调用执行器的某个HTTP接口用的端口是你在配置里指定的那个不是Spring Boot默认的8080防火墙规则别拦错了。执行器注册成功后可以在调度中心界面看到一组注册实例列表。这里有个细节执行器分组和注册实例是1对N的关系同一个分组下允许同时存在多个实例。调度中心下发任务时根据你在任务上选择的路由策略决定到底发给组里的哪一个。3.2 触发机制时间轮还是轮询扫表调度中心内部怎么知道现在该执行哪个任务了最简单粗暴的办法是开一个无限循环每隔一秒扫描一遍任务表把满足条件的任务全部捞出来触发。但任务数量一旦上万这种扫表方式的性能和耦合度都很难看。ax调度采用的是时间轮DB补偿的混合实现。内存里维护一个时间轮在调度中心启动时把未来一段时间内要触发的任务都放进时间轮的槽位里。时间轮转动到某个时刻把该时刻的所有任务取出来触发。同时任务表里还保留着下一次触发时间作为持久化状态。如果调度中心因故重启启动时会根据DB里的下一次触发时间重新加载时间轮保证错过的时间点能被补偿执行只要配置了超时补偿。时间轮的好处是触发精度高、内存查找速度快不再受数据库轮询延迟的影响。但代价是调度中心必须保持多实例的时钟一致。如果两台调度中心实例的系统时间偏差超过几百毫秒同一任务在极端情况下可能被触发两次。所以部署调度中心的机器一定要开启NTP时间同步这个我放在后面排障章节细说。3.3 路由策略轮询、一致性哈希、分片广播与故障转移任务下发到执行器组时有四种路由策略可以选择。轮询最简单依次把任务轮流分发给每个实例。适合任务执行时长大体一致的场景能让负载均匀铺开。一致性哈希则是让同一个业务ID的任务始终落在同一个执行器实例上。你可以在任务参数里带上一个shardingId调度中心对它的hash值取模决定由哪个实例来执行。这种策略很适合数据分片类任务比如你有10个用户分片每台机器只处理自己哈希分配的区间不需要分布式锁就能避免冲突。分片广播是另一种思路。任务被广播给组内所有实例每个实例都拿到一个分片序号和总分片数自己计算该处理哪部分数据。举个常见例子你有500万个用户要批量发推送一共有5台执行器每台执行器收到广播后知道自己处理第1~5片里的哪一片于是只扫userId % 5 本机分片号的那部分用户。这样速度快也不会重复处理。故障转移则是在分配前先检查实例的健康度。调度中心会对注册表里的实例做探活如果某个实例连续心跳异常就直接跳过它把任务发给下一个可用实例。这个策略适合对实时性要求高的任务。我自己实际用下来如果任务是纯计算型耗时在秒级轮询就够用如果任务涉及大数据扫描且可拆分分片广播最佳如果任务必须保证顺序或幂等一致性哈希更稳。路由策略不是一个无所谓的配置它直接决定任务执行的并发冲突概率和资源利用率。3.4 失败重试与超时控制别死循环也别直接放弃任务执行过程中一定会遇到失败。失败了到底重不重试重试几次间隔多久这里有个很关键的权衡重试能够自愈但也会放大压力。ax调度里任务可以配置重试次数和重试间隔。我的经验是重试只适合网络抖动、分布式锁冲突、临时存储不可用这类瞬时故障。如果任务本身逻辑有bug重试一万次也会继续失败反而会把日志和告警淹没。比较好的实践是设置最多3次重试重试间隔逐步加大比如1s、5s、10s。同时开启失败告警让调度中心在连续失败一定次数后通知到钉钉或企业微信机器人。我在原来项目里吃过一次亏某个任务在凌晨2点因为数据库连接池耗尽失败重试设置了99次结果整晚都在反复打数据库把其他业务也拖垮了。后来改成最多重试3次告警反而更干净。超时控制同样重要。执行器通过HTTP接收任务后如果业务代码里出现了死循环或异常卡顿任务会一直不结束。ax调度限制每次任务最大执行时长超时后执行器会主动中断任务线程并标记为失败。但要注意不是所有任务都能优雅中断。比如你在任务里调用了阻塞队列的take()直接interrupt线程可能没有效果。所以任务代码本身也要配合使用带超时时间的API。4. 实操全过程从部署调度中心到跑通第一个任务4.1 环境准备与配置说明我这里用的是ax调度v2.3版本的部署方式依赖MySQL和Spring Boot 2.x。先建库再初始化SQL脚本。调度中心默认需要两张核心表ax_task_info任务定义表和ax_task_log执行日志表。另外还有执行器注册表、分片信息表、锁表。建好表后进入调度中心的配置文件application.propertiesax.api.port18080 ax.admin.usernameadmin ax.admin.passwordyour-password ax.ds.urljdbc:mysql://127.0.0.1:3306/ax_schedule?useUnicodetruecharacterEncodingutf8 ax.ds.usernameroot ax.ds.passwordyour-db-password ax.threadpool.core-size20 ax.threadpool.max-size100 ax.schedule.max-misfire-count3ax.threadpool.core-size和ax.threadpool.max-size是调度中心用来触发任务时使用的线程池大小。如果一个任务的处理时间比较长比如调用了外部接口而调度线程池里的线程都被占满了新的任务触发就会排队等待整体调度延迟变大。我建议把core-size按任务量估算一般20到50比较稳。4.2 快速部署调度中心调度中心本身是一个独立的Spring Boot应用打包后直接用java -jar ax-admin.jar --spring.config.additional-locationapplication.properties启动。启动成功后访问http://localhost:18080登录后台。第一次登录后建议先去执行器组管理里建一个分组。我习惯按业务模块分组比如order-server、user-server、report-server一个执行器组就对应一个业务集群。后续新增任务时直接选对应的组。4.3 业务服务集成执行器组件在业务项目的pom.xml里引入依赖这里用Maven坐标示意dependency groupIdcom.ax/groupId artifactIdax-executor-spring-boot-starter/artifactId version2.3.0/version /dependency然后配置ax: executor: app-name: order-server ip: 172.16.0.10 port: 19999 admin-addresses: http://172.16.0.5:18080启动业务服务后执行器就自动注册到调度中心了。你可以在调度中心的执行器组里看到这个实例的在线状态。关于端口这里要多说一句执行器是在你的业务服务里开一个独立的HTTP端口比如19999用来接收调度中心下发的任务。别把它和业务服务的端口搞混。如果业务服务本身是8080执行器端口再开19999需要确保防火墙放通19999。4.4 定义第一个任务订单超时自动关闭场景假设我们有一个需求下单后30分钟未支付自动把订单状态改为已关闭。传统做法是在订单表里按时间扫但更合理的方式是通过延迟任务。ax调度没法直接处理基于具体业务时间的延迟任务它适合定时批量扫描所以这里我改成每隔5分钟扫描一次未支付且超过30分钟的订单。在调度中心新建任务执行器组order-server任务名称order-auto-closecron0 */5 * * * ?路由策略轮询任务参数{operate:closeOverdueOrder}失败重试3次告警开启保存后任务就进入运行状态了。执行器那边要写对应的处理器Component public class OrderAutoCloseHandler implements AxJobHandler { Override public void execute(AxJobContext context) throws Exception { // 从context中拿到参数 String param context.getParam(); if (!param.contains(closeOverdueOrder)) { // 非本任务关心的事件直接返回 return; } // 核心业务逻辑扫描30分钟前未支付的订单批量关闭 ListOrder overdueOrders orderMapper.selectOverdueOrders(30); for (Order order : overdueOrders) { order.setStatus(OrderStatus.CLOSED); orderMapper.updateById(order); // 记录一条操作日志方便排查 log.info([ax-schedule] closed order id{}, order.getId()); } } }处理器需要实现AxJobHandler接口并在execute方法里写业务逻辑。执行器收到调度指令后会从Spring容器里找到对应的Bean并在独立线程池里执行。4.5 测试触发与日志跟踪任务配好后可以先在后台点一下手动触发试试。手动触发不会等待cron立刻执行一次。然后到调度日志里看这条任务的执行状态、调度时间、执行耗时、返回信息。这一步能验证执行器注册是否正常、参数是否解析正确、业务代码是否跑通。我实际操作时先手动触发了一次发现任务状态变成了成功但业务里的订单没有关闭。排查日志发现执行器收到了请求但没有执行到具体逻辑原因是任务参数里的operate字段名和Java代码里处理的方式不匹配导致直接走了return分支。这种问题多亏日志里能看到返回值否则根本想不到是参数问题。用这种调度日志业务日志对照的方式排查是ax调度下最有效率的debug手段。5. 常见问题与排查技巧实录5.1 任务迟迟不触发先看时间轮再看数据库锁我遇到过一种现象在后台新建了一个每小时执行的任务到点了却不跑调度日志里也没有记录。检查发现调度中心有两个实例其中一个实例的数据库锁表里锁记录被另一个实例占着而持有锁的实例因为GC停顿导致调度线程阻塞。等GC结束后任务已经过了触发时间又因为max-misfire-count设置为0错过了就不再补偿。这类问题的处理思路分两步第一确保调度中心的多实例部署不是一主一备闲置模式而是通过抢锁的方式互相兜底第二misfire策略不要设为忽略最好设为立即补偿一次避免漏单。另外调度中心的JVM内存不要省任务多的机器至少给2G以上堆内存GC停顿越少错过调度的概率越低。5.2 同一任务被重复执行时钟偏差与路由策略的共同作用有一次用户反馈凌晨的报表任务生成了两份数据。排查发现执行器组里有三台机器路由策略是故障转移。三台机器中的一台因为NTP服务停了系统时间比另外两台快了几分钟。调度中心下发任务时那台时钟偏慢的机器上的执行器没有及时处理调度中心认为它超时了于是又转发给了另外一台机器。重复执行的根本原因是任务本身没有做幂等而不是调度框架的问题。但框架层面能做的是利用路由策略分片尽量保证单实例处理对必须只执行一次的任务参数里带上一个全局唯一批次ID执行器根据批次ID在数据库里做唯一约束。我后来把优雅关闭的时间也加了进去执行器在收到停止信号时先将正在执行的任务标记为可重跑再停止接收新任务这样调度中心在检测到节点不可用后可以安全地把未完成任务转交给其他节点。5.3 执行器线程池被打满避免任务内嵌套调用执行器内部的业务任务线程池默认只有10到20个线程。如果你一个任务里又批量调用其他任务接口或者线程里又起子线程去处理数据很容易把线程池占死。表现就是任务都在运行中状态但没有任何一个结束新的任务全部排队。我的经验是不要在ax任务处理器里再开异步线程。任务本来就该是同步执行、同步返回结果。如果业务逻辑里有可异步部分应该拆成两个独立任务由调度中心来编排先后顺序而不是在任务内部自己并发。否则你调试的时候会陷入为什么所有任务都卡住了的泥潭。5.4 调度日志的字段怎么看调度日志是排查线上问题的第一手资料。重点关注四列字段含义排查要点调度时间调度中心触发任务的时间点与期望时间差过大说明时间轮或线程池阻塞执行时间执行器实际开始执行的时间与调度时间差大说明网络有延迟或执行器线程池排队执行耗时从开始到结束的时间超过预期抓线程栈分析业务卡点执行结果成功、失败、超时、错过失败看失败信息超时调整任务最大执行时长如果执行结果状态是超时但业务里明明跑完了可能原因是执行器回调调度中心时网络不稳定调度中心认为没收到回执。这种情况可以把任务的最大执行时长值调大一点同时检查调度中心与执行器之间的网络质量。5.5 分布式锁表的重要性多调度中心实例必须保证互斥ax调度虽然可以多实例部署调度中心但同一时刻只允许一个实例真正进入调度循环。它通过数据库里一张ax_schedule_lock表实现。每个实例启动时都尝试插入或更新某条记录并带上自己的实例ID和当前时间。如果另一个实例在等待一定时间后仍拿不到锁就进入空闲状态定期抢锁。有一个坑值得提醒如果你把调度中心的数据库账号权限设置得过于严格导致更新锁表的语句失败实例会直接启动失败或者始终认为自己是备节点。建议原子类型字段检查和写入分开时一定要确认数据库账号有UPDATE权限。6. 实用心得用ax调度时我最在意的几个配置最后分享几个我在实际项目中反复调优后觉得最值得关注的配置点而不是泛泛而谈的框架介绍。第一任务量与线程池的配比。如果你的任务执行耗时不长比如几百毫秒到一秒调度线程池和任务线程池都不需要太大但是任务耗时长、数量又多就得认真做容量估算。我曾经跑过3000个周期任务每个任务执行平均20秒一开始线程池只有50结果后一批任务比计划时间晚了整整8分钟。后来把线程池加到200并把部分任务拆成更细粒度批量配合分片广播才把延迟控制到秒级。建议你上线前做一次压力测试别直接拍脑袋定线程数量。第二任务参数一定要做成版本化。ax调度允许你更新任务参数但如果任务业务代码逻辑也随版本变化会很容易出现旧参数新代码的组合问题。我的做法是在任务名称里带上预期行为关键字比如order-close-v2参数里再带一个version字段。这样日志和告警里能明确看到是不是新版本任务也方便回滚。第三告警必须分级。不是所有任务失败都需要打电话。我把任务分成核心交易链路、常规数据统计、辅助运维脚本三类。核心任务失败立刻告警常规任务失败合并后每小时发一次辅助任务失败只在第二天日报里出现。这样既不影响业务响应又不会让告警噪音淹没真正的问题。不同任务在ax调度的告警等级字段里可以直接区分成本很低。第四合理利用分片广播处理大数据量任务。我之前一直觉得分片广播复杂直到有一次任务要处理2000万行数据单机跑要40分钟改成10台机器分片广播后缩到5分钟。实现上并不复杂在处理器里通过context.getShardIndex()拿分片号然后用取模圈定数据范围即可。需要注意的是分片广播模式下每个执行器都会收到任务所以要确认你的业务逻辑本身是支持分片的否则会重复处理。关于ax调度的接入我这里没有给太多源码细节因为我觉得这套框架最大的学习价值在于它的调度与执行分离思想。你在实际项目里不管最终选择成熟的重量级调度平台还是基于自己的想法撸一个轮子理解任务从注册、触发、路由、执行、日志到补偿的完整链路才是真正的收获。我在跑通这套流程后最大的感触是任务调度看起来是件杂活但把它系统化之后整个服务集群的行为会变得非常可预期。希望这篇实操记录能帮你更快攻下这个基础组件。