第一次意识到需要正经做一套调度系统是在一次线上故障复盘会上。那会儿我们服务里的定时任务已经涨到了四十多个分散在六个微服务里有的用Spring的Scheduled有的塞在Linux的crontab里还有一个跑在一台临时服务器上——发起人离职之后没人知道它为什么在那里。凌晨大促压测一开多个任务同时触发数据库连接池被打满告警群炸了一整夜。那次之后我才下决心把任务调度从业务代码里抽出来做了一个代号叫ax的调度平台。这篇文章就围绕ax调度这套系统的设计与落地来写聊聊它解决了什么问题、核心架构怎么拆、业务方怎么接入以及我在实操和踩坑过程中总结出来的经验。ax调度说白了就是一个分布式任务调度平台解决的是“定时任务散落各地、无人统一管理”的乱象。它把分散在业务代码里的定时任务统一收口到一个平台提供可视化的任务管理、可靠的调度触发、失败重试、分片执行和DAG依赖编排能力。如果你是个后端工程师正在被任务管理混乱、定时任务不敢动、告警全靠肉眼的场景折磨这篇文章应该能对得上如果你在选型阶段纠结“要不要自研调度系统”前两章的分析也能帮你想清楚边界。1. 为什么要把调度抽出来背景、痛点与设计目标1.1 散落的定时任务到底哪里疼先说个真实感受定时任务这事一开始真的不起眼。业务起步阶段写个Scheduled(cron 0 */5 * * * ?)三行代码搞定和业务逻辑放在一起还挺顺手的。但任务量一旦超过二三十个问题就开始冒头了。散落的形式各有各的坑。写在业务代码里的定时任务最大的问题不是不能用而是“不敢动”。你想改一个任务的执行频率得先找到它在哪个服务的哪个类里你想知道它上次执行成功没有得翻日志你想加个失败重试得改代码发版。更麻烦的是它和业务线程混在一起遇到慢接口或死循环整个服务的线程池都会被拖垮。我用crontab管理任务也踩过坑换机器、迁移环境的时候crontab列表经常忘拷某些任务就这么悄无声息地消失了等业务方来问“为什么今天没数据”才发现。中间件里的延迟消息做简单的延时触发还行但要做“每天凌晨两点跑一次”这种周期调度就不太合适——要么得自己维护一个循环投递的逻辑要么就是投递次数和状态管理变得非常拧巴。更贵的代价是那些“人肉触发”的脚本放在某台机器上平时静悄悄一坏就是大事。这些场景汇总起来就一句话任务调度不应该和业务代码耦合在一起它需要被当成一个独立的基础设施来设计。调度的核心职责就是“到点触发、可靠执行、结果可查”这三点塞在业务代码里永远是配角只有抽出来独立成系统才能做到可管理、可观测、可恢复。1.2 为什么不直接换一个现成调度中间件做ax调度之前我其实先过了一遍开源的调度方案。毕竟自研是有成本的能用现成的就没必要重复造轮子。当时主要对比了几个方向方案优点主要问题Quartz经典、稳定、文档多没有管理界面集群模式下分布式锁性能一般任务编排能力弱XXL-Job轻量、易上手、UI完善DAG依赖编排弱复杂工作流场景支持有限Elastic-Job分片机制强、调度模型灵活接入和学习成本偏高社区活跃度一般DolphinScheduler工作流编排强、功能全面整体偏重对只想管定时任务的团队来说有点杀鸡用牛刀看了一圈发现这些工具各有各的侧重。有的重编排、轻触发有的重触发、弱编排有的功能很全但部署成本高得吓人。我之前在另外一个项目里用过Quartz加JDBCJobStore做集群调度任务量一上来多节点抢锁导致的调度延迟问题特别头疼。所以我心里很清楚纯靠开源方案不一定能完美匹配我们的使用场景——我们需要的是一个轻量、可控、能按自己节奏迭代的调度核心。这就是ax调度的出发点不是推翻什么而是把“任务管理”“可靠触发”“DAG编排”三件事做扎实同时保持非常低的业务接入成本。公司内部已有的监控系统、告警系统、配置中心、注册中心都可以直接集成进来。自研不等于从零发明而是把技术选型的主动权握在自己手里。1.3 ax调度要解决的三件事设计目标定得很收敛就三件事。第一是统一。所有定时任务不管原来写在哪个服务里最终都要收敛到ax调度平台上来。统一带来一个最大的好处就是“可观测”——任务的注册情况、执行历史、成功失败率、耗时曲线在一个地方全部看得到。之前那种“任务跑没跑、跑到哪里、为什么挂了”全靠猜的尴尬局面直接终结。第二是可靠。调度平台最怕的就是“该跑的时候没跑”和“不该跑的时候跑了”。前者要靠高可用部署、分布式锁、失败补偿来兜底后者要靠幂等设计、唯一索引、路由策略来防重。ax调度在触发链路的每一层都做了可靠性设计调度中心多活部署触发时拿分布式锁保证单点触发任务执行结果上报时带幂等键DB层再加唯一索引做最终兜底。第三是可编排。业务上真正复杂的不是单个定时任务而是“一组任务按顺序执行、有依赖关系”的场景。比如每天凌晨的数据同步链路先拉取原始数据再做清洗转换最后写入数仓中间任何一步失败都可能需要重跑或跳过。ax调度用DAG来表达这种依赖关系任务之间可以串行、并行、条件触发失败传播规则也由用户自己定义。这三件事听起来都很基础但真正落地的时候每一个都要在架构设计上做不少取舍。2. 核心架构与关键模块拆解2.1 整体形态调度中心、执行器与存储ax调度的整体架构走的是经典的“中心调度 执行器”模式和市面上主流调度系统的思路一致区别在于每一层的实现细节和取舍方式不同。调度中心ax-admin负责任务管理、cron解析、触发调度、路由分片、日志聚合和告警触发。它本身是无状态的可以多节点部署节点之间通过数据库和Redis协调触发权。执行器ax-worker以SDK方式嵌入业务服务接收调度中心下发的执行指令在线程池里跑业务代码并把执行日志、结果、耗时上报给调度中心。存储层MySQL存任务元数据、调度记录、执行日志摘要Redis承担分布式锁、执行器心跳、注册信息缓存等轻量数据。整个调度流程可以描述为调度中心每秒扫描一遍时间轮和到期的任务命中之后加锁、生成调度记录、按路由策略选出目标执行器然后通过HTTP长连接或RPC下发给执行器。执行器拿到指令后创建任务上下文参数、分片索引、超时配置提交到内部线程池执行。执行完成后执行器把结果异步上报给调度中心调度中心更新任务日志并触发告警或依赖节点。这套形态的好处是调度逻辑和业务逻辑彻底分离。调度中心不跑任何业务代码执行器不关心cron怎么解析、路由怎么选只负责“接单干活”。两边通过统一协议通信新增一种任务类型只需要在业务服务里实现一个Handler接口不需要改动调度中心。2.2 任务模型怎么设计任务模型是调度平台的地基字段设计一旦没想清楚后面加需求就会很痛苦。ax调度对任务元数据的设计基本遵循“够用 可扩展”的原则核心表job_info的关键字段和设计意图如下CREATE TABLE job_info ( id bigint(20) NOT NULL AUTO_INCREMENT, job_group varchar(64) NOT NULL COMMENT 任务分组, job_name varchar(128) NOT NULL COMMENT 任务名称, cron varchar(64) DEFAULT NULL COMMENT cron表达式, job_desc varchar(255) DEFAULT NULL COMMENT 任务描述, handler_name varchar(128) NOT NULL COMMENT 执行器Handler标识, handler_param varchar(512) DEFAULT NULL COMMENT 任务参数, route_strategy tinyint(4) DEFAULT 0 COMMENT 路由策略 0轮询 1随机 2一致性Hash, shard_count int(11) DEFAULT 1 COMMENT 分片数量, timeout int(11) DEFAULT 0 COMMENT 任务超时时间(秒), retry_times int(11) DEFAULT 0 COMMENT 失败重试次数, retry_interval int(11) DEFAULT 0 COMMENT 重试间隔(秒), alarm_users varchar(255) DEFAULT NULL COMMENT 告警联系人, status tinyint(4) DEFAULT 0 COMMENT 0停止 1运行, create_time datetime DEFAULT CURRENT_TIMESTAMP, update_time datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_group_status (job_group, status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;设计任务模型时我特别注意几个点。第一是handler_name——业务侧只需要通过这个标识找到对应的Handler实现调度中心完全不用关心业务代码长什么样这就是“调度与业务解耦”的最小契约。第二是route_strategy——当同一个任务有多个执行器节点时到点该派给谁跑轮询、随机、一致性哈希分别适用不同场景比如一致性哈希适合想把同一任务固定到同一节点的场景。第三是shard_count——针对大数据量任务设计的“分片执行”能力一个任务切成多片每片分给不同的执行器并行跑类似MapReduce的Map阶段听过的朋友应该秒懂。除了job_info还有一张job_log表记录每一次调度的详细信息调度时间、执行器地址、响应结果、开始/结束时间、日志详情、触发类型手动/自动/补偿。job_log是排查问题的主战场后面第四章会重点讲。2.3 触发机制从Quartz到时间轮调度平台的核心是“按时触发”触发机制选型直接决定了系统的性能和可扩展性。最初我认真考虑过Quartz它确实成熟稳定但在集群模式下有个绕不开的问题当调度中心多节点部署时Quartz的JDBCJobStore通过数据库行锁实现集群节点之间的互斥任务量大之后锁竞争和数据库压力会非常明显调度延迟肉眼可见。ax调度最终选型是“时间轮 独立调度线程池”。时间轮的核心思想不复杂你可以把它想象成一个带有指针的圆盘圆盘被等分成若干格每走一个刻度对应一个时间单位要延迟执行的任务被放进对应的格子里指针转到达个格子时取出执行。比起Quartz每次都要查数据库、抢锁、排序、遍历时间轮是纯内存运算触发性能高一个量级。核心示意图大致是这样的逻辑环形数组 当前指针 每个槽位持有任务队列。public class SimpleTimeWheel { private final long tickDuration; // 每个槽位的时间跨度单位ms private final int wheelSize; // 槽位数量 private final AtomicLong currentTick; // 当前指针从0开始递增 private final QueueScheduledTask[] slots; SuppressWarnings(unchecked) public SimpleTimeWheel(long tickDuration, int wheelSize) { this.tickDuration tickDuration; this.wheelSize wheelSize; this.currentTick new AtomicLong(0); this.slots new Queue[wheelSize]; for (int i 0; i wheelSize; i) { slots[i] new ConcurrentLinkedQueue(); } } public void add(ScheduledTask task) { long delayMs task.getDelayMs(); long targetTick (currentTick.get() delayMs / tickDuration); int index (int) (targetTick % wheelSize); task.setTargetTick(targetTick); slots[index].add(task); } public void advance() { long tick currentTick.incrementAndGet(); int index (int) (tick % wheelSize); QueueScheduledTask bucket slots[index]; while (!bucket.isEmpty()) { ScheduledTask task bucket.poll(); if (task.getTargetTick() tick) { // 到期任务提交到调度线程池执行 dispatch(task); } else { // 相差超过一个轮次的场景使用多层轮处理 reAdd(task); } } } }这个实现属于单层时间轮的简化版。实际上当任务延迟时间超过一圈比如槽位100个、每格100ms超出10秒的任务单层时间轮就装不下了所以ax调度在实现时加了“圈数”的概念任务除了记录目标槽位还要记录需要转多少圈才执行每次指针经过就把圈数减一减到零才真正取出执行。更复杂的场景还可以做多层时间轮类似钟表的时、分、秒三层不同层处理不同量级的延迟这里就不展开codings了。作为一个参考xxl-job用的是“时间轮 预取”的思路xxl-job本身在触发性能和集群一致性上就经过了大流量验证。ax调度在触发机制上和它思路接近但我们在任务模型和依赖编排上做了很多自己的扩展。重点是想说明触发性能的瓶颈往往不在“cron解析”上而在“如何把海量到期任务高效地分发给执行器”时间轮是目前实践下来比较划算的答案。2.4 依赖编排DAG调度的实现思路单个定时任务好做任务之间有依赖关系才是难点。ax调度的依赖编排基于DAG有向无环图节点是任务边是依赖关系。用一句话概括就是“我能跑的前提是我的上游都跑成功了。”实现DAG调度我拆成了三步。第一步是建图。控制台创建DAG的时候用户选好任务A、B、C然后定义A是B和C的前置任务。调度中心把这张图解析成一个真正的图结构核心就是两个Map一个记录每个节点的入度一个记录每个节点的所有下游节点。第二步是环检测。有向图一旦出现环调度就完了——A等B、B等A永远转不出来。所以在保存DAG的第一时间就要做一次拓扑排序。如果拓扑排序能排出来的节点数小于图里实际节点数说明存在环直接拒绝保存。这个校验必须在入口处就做掉不能等运行时才发现那时候排障成本就高了。第三步是触发和状态推进。DAG调度开启后先触发所有“根节点”入度为0每一个任务执行完成之后调度中心根据结果更新下游节点的依赖状态。当某个下游节点的所有上游都成功它就进入可触发状态放到调度队列里等待执行如果有上游失败按用户配置的策略决定是跳过还是标记失败。这里最反直觉的是“等待”这个动作。如果每个下游节点都靠轮询去问“我的上游好了没”效率会非常低。我的做法是事件驱动一个任务结束之后调度中心能立刻定位到它的所有下游节点然后做减入度、判状态、触发下一轮。因为所有信息都存在内存的DAG实例里这一套状态流转跑得非常快也不需要额外引入消息队列。用做饭来类比DAG就是一张做菜流程图洗菜切菜是并行的两个任务它们都完成之后才能进入炒菜环节炒菜出锅之后才能装盘。如果洗菜失败了炒菜再厉害也只能干等。这张图的价值就是把这个“先后顺序”显式表达出来而不是靠人肉记在Excel里。3. 实操从零落地一套ax调度平台3.1 技术选型与工程结构这里先交代一下技术栈和相关考量。ax调度整体基于Java生态服务端核心用Java 17 Spring Boot 3存储用MySQL 8.0缓存和分布式锁用Redis 6.x。选择Java没有特别复杂的理由主要是团队的技术栈一致以及调度平台对稳定性要求高Java的生态成熟度和可维护性更好。工程分成三个模块ax-core核心领域层包括任务模型、cron解析、时间轮、DAG引擎、路由算法等不依赖Spring方便单元测试和复用。ax-admin调度中心服务端Spring Boot应用提供REST API和控制台页面。ax-worker执行器SDK嵌入业务服务的jar包提供Handler接口和自动注册能力。这个结构的好处是边界干净。ax-core是纯算法和模型ax-admin专心做调度交互ax-worker对业务方只暴露最小接入面。如果后续要做调度平台给外部团队用把ax-admin的接口权限和租户模型做一下就能复用核心引擎不用动。3.2 初始化数据库核心表设计落地数据库初始化是在搭建ax调度时最需要重视的环节表结构设计的合不合理直接决定后续开发和排障的体验。除了前面讲到的job_info还需要几张辅助表。job_log表记录每一次调度的执行历史是排查问题的第一现场CREATE TABLE job_log ( id bigint(20) NOT NULL AUTO_INCREMENT, job_id bigint(20) NOT NULL COMMENT 任务ID, trigger_type tinyint(4) NOT NULL COMMENT 触发类型1自动 2手动 3补偿, executor_address varchar(64) DEFAULT NULL COMMENT 执行器地址, handler_name varchar(128) DEFAULT NULL COMMENT Handler标识, handler_param varchar(512) DEFAULT NULL COMMENT 实际执行参数, shard_index int(11) NOT NULL DEFAULT 0 COMMENT 分片索引, shard_total int(11) NOT NULL DEFAULT 1 COMMENT 分片总数, start_time datetime DEFAULT NULL, end_time datetime DEFAULT NULL, status tinyint(4) NOT NULL COMMENT 0待执行 1执行中 2成功 3失败 4超时 5忽略, result_msg varchar(512) DEFAULT NULL COMMENT 结果摘要, trace_id varchar(64) DEFAULT NULL COMMENT 链路追踪ID, PRIMARY KEY (id), KEY idx_job_time (job_id, start_time), KEY idx_status_time (status, start_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;job_registry表负责执行器的在线状态管理CREATE TABLE job_registry ( id bigint(20) NOT NULL AUTO_INCREMENT, app_name varchar(64) NOT NULL COMMENT 应用名, executor_address varchar(64) NOT NULL COMMENT 执行器地址, update_time datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_app_addr (app_name, executor_address) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;job_registry的数据在实际运行中不一定每次都实时查MySQL执行器启动时向调度中心注册并上报心跳调度中心把在线地址缓存到Redis只有心跳异常时才去刷新DB。这样一个设计MySQL的读压力非常低。3.3 搭建调度中心调度中心本质是一个Spring Boot应用核心配置如下server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/ax_schedule?useSSLfalseserverTimezoneAsia/Shanghai username: your_mysql_user password: your_mysql_password redis: host: localhost port: 6379 password: your_redis_password ax: scheduler: # 时间轮刻度单位毫秒 tick-duration: 100 # 时间轮槽位数量 wheel-size: 512 # 调度线程池核心线程数 scheduler-core-pool-size: 8 scheduler-max-pool-size: 16 admin: # 控制台登录账号建议接入公司SSO username: admin password: ${AX_ADMIN_PASSWORD}配置里最值得解释的是时间轮相关参数。tick-duration: 100表示时间轮每100ms走动一格。wheel-size: 512表示有512个槽位相乘得到单层轮能覆盖51200ms约51秒的延迟。如果任务延迟超过一圈还是能处理只是会走多圈逻辑性能差一些。对于绝大多数分钟级甚至小时级的cron任务时间轮的主要作用不是“精确到毫秒”而是避免大量定时任务的频繁扫描和建连。启动调度中心之后验证也很简单。访问http://localhost:8080/ax-admin能看到登录页面用配置好的管理员账号登录。接着调一下健康检查接口curl http://localhost:8080/ax-admin/api/health返回{status:UP}就说明调度中心起来了。整个搭建过程大概十来分钟因为调度中心本身不依赖其他内部服务只有MySQL和Redis两个基础设施部署成本很低。3.4 业务方接入执行器调度中心搭好之后最重要的事就是让业务服务接入执行器。ax-worker被设计成一个轻量SDK接入过程分三步。先在业务服务的pom.xml里引入依赖dependency groupIdcom.yourcompany/groupId artifactIdax-worker-spring-boot-starter/artifactId version1.0.0/version /dependency然后在配置文件里声明执行器信息ax: worker: # 应用名必须与调度中心里配置的任务分组一致 app-name: order-service # 执行器暴露给调度中心的地址 executor-address: ${EXECUTOR_ADDRESS} # 注册心跳间隔秒数 heartbeat-seconds: 10 # 执行线程池大小 executor-pool-size: 8紧接着编写任务Handler。开发者只需要实现AxHandler接口并注册一个标识名称Component AxJobHandler(syncOrderHandler) public class SyncOrderHandler implements AxHandler { Override public AxResult execute(AxContext context) { // 拿到调度中心下发的任务参数 String param context.getParam(); // 拿到分片上下文分片索引和总分片数 int shardIndex context.getShardIndex(); int shardTotal context.getShardTotal(); // 假设我们要同步订单数据分片模式下按订单ID取模分散到不同节点 ListLong orderIds fetchOrderIds(shardIndex, shardTotal); for (Long orderId : orderIds) { syncOrder(orderId); } return AxResult.success(同步完成共处理 orderIds.size() 条订单); } }这样一个Handler就写好了。你可能会问调度中心怎么知道我导出了这个Handler的这里就走到了ax调度里很关键的一个自研设计——执行器启动时SDK会把当前应用下注册的所有AxJobHandler的Handler名称列表打包通过HTTP接口上报到调度中心。调度中心会比对数据库里的任务配置与执行器上报的Handler列表不一致就直接告警。这个设计可以理解为“服务注册”机制在调度场景里的应用如果调度中心向某个业务服务分发了一个不存在的Handler后果就是任务静默失败而这种设计能提前把这种低级别的错误挡在运行时之前。3.5 创建任务、配置DAG与调度验证执行器接入完成后接下来的环节就是创建任务。在控制台选择“新建任务”配送参数时用提示信息举例任务分组选order-service对应执行器的app-name。Handler选syncOrderHandler下拉框里可以直接选数据来源就是执行器上报的Handler列表。cron表达式填0 0 2 * * ?告别之前crontab那种每次迁移机器都要重新配置的历史。路由策略选“轮询”因为同一个订单服务有多台节点希望任务可以轮流分布在各机器上执行。失败重试次数填3次重试间隔填60秒。超时时间填300秒防止任务死循环卡死执行器线程池。创建完成后先别急着启用先在任务操作栏点“手动触发一次”。这次手动触发会走完整个调度链路调度中心下发指令、执行器接单、线程池执行、结果上报、日志落库。手动触发成功之后再去“调度日志”页面看执行记录重点看status是否为2成功start_time和end_time之间的耗时有没在合理范围。如果任务需要编排成DAG控制台的操作也很直观。比如“订单数据同步链”建三个任务pullRawOrder、cleanOrder、writeToWarehouse。在DAG编辑页里依次选择这三个节点然后建立两条边pullRawOrder指向cleanOrdercleanOrder指向writeToWarehouse。保存前系统自动做环检测确认通过后就能启动。这时候再手动触发整个DAG执行器日志和调度日志会呈现严格的依赖推进顺序完全不用人肉协调。3.6 关键参数与性能调优ax调度跑起来不难但要跑得稳参数调优很关键。我把核心参数和调优经验整理成一张表这也是我反复实战之后用得最多的配置参考。参数默认值建议值理由调度线程池核心线程数8调度量每秒500时建议16时间轮命中后的分发任务提交到调度线程池全局并发分发的瓶颈在这个池子执行线程池大小8任务平均耗时1秒时建议至少16执行器线程池太小会导致任务排队只能通过加节点或加线程解决任务超时时间0必须设置没有超时某个任务发了一次外部请求一直挂起线程池很快被占满失败重试次数0设置2~3次很多失败是瞬时的比如网络抖动、数据库锁等待重试能救回来重试间隔0建议按指数退避固定间隔重试在依赖下游服务时会对下游产生集中压力分片数量1大数据量任务按节点数倍数设置分片数太少并行度不够太多则单次执行处理数据量过少网络调度开销占比变大特别说明一下“任务超时”这个参数。很多人习惯不设置但这是我在生产环境踩过最大的一次坑。有一个任务调用第三方接口第三方接口一直挂起不返回客户端连接也没设置超时结果一个个任务堆在执行器线程池里最终整个服务不可用。设置超时本质上是在告诉执行器“这个任务最多跑多久超过这个时间就直接终止并重新调度。”这是保护业务服务自身安全的重要防线。线程池调优还有一个细节scheduler-core-pool-size和executor-pool-size之间是相互独立的。前者管“调度中心内部的分发”后者管“执行器内部的业务执行”。很多人会把这两个参数混在一起调导致调度中心线程池很大但执行器线程池很小任务全部积压在执行器侧。更合理的做法是根据任务的平均耗时和期望的并发数来估算执行线程池大小。比如你期望同时并发执行64个任务每个任务耗时2秒那么执行线程池至少32个线程加上队列缓冲基本能满足需求。4. 常见问题与排查技巧实录4.1 重复调度分布式锁失效先说一个让我头疼了很久的问题任务被重复调度。ax调度中心是支持多节点部署的一开始我天真地认为只要每个节点都跑一遍时间轮同一时刻只有一个节点会去触发任务纯靠时间轮自身的指针不就有天然互斥吗显然是错的。多节点部署的最大难题就是“同一时刻必须只有一个节点触发同一个任务”否则订单同步这类任务会重复执行产生脏数据甚至资损。排查过程很典型。现象是job_log里同一秒出现了两条同一个任务的记录一条来自executor-1一条来自executor-2。我先查了所有调度中心节点的服务器时间发现有一台机器和NTP服务器同步失败时间偏差了大概3秒。时间偏差直接导致两个节点的“当前时间”不同A节点已经触发任务B节点由于时间落后也认为“到点了”于是两台节点同时下发。这种问题在Redis分布式锁小于任务执行时间时也会出现锁自动过期了另一个节点拿到锁又触发了一次。最终的解决方法是双保险第一Redis分布式锁不再用简单的SETNX而是用Redisson的看门狗机制延长锁有效期避免任务没跑完锁就过期第二job_log表里增加唯一索引字段是job_id trigger_time handler_name即使极端情况下两次触发都进来了第二次插入会被数据库拒绝从根上杜绝重复记录。使用Redisson看门狗后再叠加数据库兜底效果稳定多了。4.2 执行器线程池耗尽大促真实案例这是我在大促压测时遇到的最严重的一次线上故障。现象是告警群突然刷屏订单服务的执行器线程池拒绝新任务相关的数据处理任务大面积失败。我跑过去看监控发现执行线程池的活跃线程数一直打满等待队列里的任务数到了几千。根因也很直接大促期间执行器不仅要跑定时任务还要响应日常的业务流量而ax调度的执行线程池和业务线程池是独立的我们没有限制定时任务的并发度。有一个任务恰好是一次批量数据补偿任务一次要跑半小时但它内部又分了很多个小批次每个小批次都会占用一个线程。结果就是定时任务线程池被这一个任务的高并发子批次占满其他任务全部排队。这次之后我做了三个调整。第一个所有任务设置超时时间和最大并发数不允许一个任务无限占用线程。第二个给执行线程池引入“按任务分组隔离”的机制重要任务和普通任务使用不同的线程池避免普通任务拖垮重要任务。第三个把监控指标补齐执行器上报线程池活跃度、队列积压数、拒绝次数等指标调度中心侧按阈值触发告警。压测这次教给我的道理是调度平台不能只关注调度成功率执行器侧的资源隔离能力同样重要。4.3 任务堆积与背压处理调度快、执行慢就会出现任务堆积。比如一个任务cron设置的是每5秒一次但实际执行需要30秒调度中心已经把下一次触发建好记录并下发了但执行器里上一轮还没跑完。这种情况下如果执行器是无脑接单线程池队列会被撑爆。ax调度在处理这个问题上引入了“调度预检”机制。执行器在执行业务逻辑前先做一次背压检查当前任务队列里待执行的任务数超过阈值了可以直接返回“繁忙”给调度中心调度中心收到繁忙响应后根据策略决定是稍后重试还是跳过本轮。这本质上是一种“限流”和消息消费里的拉模式有点像我能在单位时间内处理多少任务调度器就必须尊重这个速率。对于周期任务来说“跳过本轮”往往是正确的选择因为下一轮马上又会来对于DAG链路上的任务则不适合跳过而应该等待重试。这也是我在做DAG状态机时特意把“跳过”和“重试”区分开的原因。除了执行器侧做背压调度中心侧还可以配置“调度限流”比如同一任务的最大并发调度数。这个参数单位时间内只允许生成N次调度记录多余的触发直接丢弃并告警。这两个机制双管齐下任务堆积的概率会低很多。4.4 日志缺失与问题定位调度平台日常使用中最让人痛苦的就是日志缺失。业务方来问“我的任务为什么失败了”你打开job_log一看status是3失败但result_msg是空的——执行器上报结果的时候日志丢了。没有日志排查就要靠猜。日志丢失主要有两个原因。一个是执行器进程发生OOM或直接被强杀日志还没来得及上报调度中心另一个是日志上报走了异步通道结果通道积压或网络异常数据丢了。我们当时根本没想过要持久化全部日志设计的就是执行器把结果摘要上报给调度中心详细日志留在执行器本地。解决思路是“结构化日志 双通道采集”。业务Handler执行时自动产生结构化日志包含本次调度的trace_id、job_id、shard_index和业务自定义信息。执行器端把日志同时写本地文件并异步上报摘要到调度中心。当摘要缺失时运维人员可以直接凭trace_id去执行器的日志文件里查完整链路。后来我又接了公司内部的日志平台ax-worker直接把结构化日志推送到日志平台不依赖调度中心的存储这样日志的完整性和查询便利性都得到了保障。经验是调度平台一定要把“日志可追踪”当成一等公民来设计不要等线上出问题再补。trace_id贯穿调度中心到执行器的整条链路排查问题时效率会提升好几倍。5. 一些经验心得和后续改进方向5.1 这套系统最值回票价的三个设计如果让我总结ax调度里最值回票价的三个设计我会选这三个。第一个是“Handler注册上报机制”。业务方接入ax调度本质上只做两件事引入SDK、写一个Handler方法。Handler名称自动上报调度中心新增任务时下拉框直接选不需要任何代码改动。这个设计让“业务接入调度平台”的成本低到了一个极限。第二个是“调度中心无状态”。调度中心节点之间没有任何会话状态挂掉一台节点不影响其他节点继续工作。触发权通过分布式锁协调锁的粒度是按任务维度加的即每个任务独立加锁锁竞争范围非常小。不像有些方案锁整个调度器全局互斥导致性能急剧下降。这也为后续做弹性伸缩铺平了路。第三个是“DAG依赖的事件驱动推进”。之前用轮询式调度一个任务结束要等下一个心跳周期才知道现在任务节点结束后立即推进下游状态依赖链整体的执行效率和体验都接近实时工作流。尤其在几十个节点的复杂链路里这个设计带来的体感差异极其明显。5.2 自研调度平台要冷静评估边界这套系统做了这么久我也越来越清楚地意识到自研调度平台不是万能的。如果你面临的情况是团队只有几台机器、定时任务不超过20个、也没有复杂的依赖编排需求直接用crontab或者XXL-Job完全够用。自研平台的优势要到任务量级上来、管理半径变大之后才会体现前期搭平台耗费的精力客观上也不少。另一个边界是平台能力不能一味求全。我曾经动过念头要给ax调度加上工作流审批、报告生成、定时SQL查询等业务功能后来忍住了。调度平台的天职是“稳定、可靠、易接入”功能堆得越多出问题的面就越大。把复杂留给自己把简单留给业务方这个原则让我少走了很多弯路。5.3 下一版本我打算怎么做除了修修补补我还有几个明确想做的改进方向。第一个是联邦调度让多个机房或多个团队的同名执行器自动做跨集群的任务调配进一步提升极端故障下的容灾能力第二个是任务流量灰度验证新上线一个任务可以先在低流量节点上试跑确认稳定后再全量放量这个能力对业务方来说是刚需第三个是任务成本分析通过job_log里的执行耗时、调度频率、资源占用做统计报表帮业务方找到成本最高的任务做优化。开发这个系统的过程让我最深的一点体会是调度平台表面上拼的是功能实际上拼的是细节设计。每一个参数的默认值、每一条日志的格式、每一个异常分支的处理都可能在大流量和极端场景下被放大成焦点问题。希望这篇文章里的经验能帮到正在或将要面对同样问题的你。
