企业官网建设流程全解析

项目代号ax，对外说的“ax调度”，其实就是我带着几个后端同学从零搭出来的一套分布式任务调度平台。折腾了几个月，踩了不少坑，也沉淀了不少可以复用的经验。如果你正好在做定时任务、批量处理或者工作流编排，这篇文章值得先码后看。

1. ax调度到底解决什么问题

1.1 从crontab到调度平台，我们经历了什么

最早的时候，团队里的定时任务基本都是crontab + 一堆shell脚本，散落在不同机器上。每个业务线自己维护一套，谁改谁心里有数，但出了问题谁都脱不了干系。典型的几个场景：

• 数据同步任务挂在某台跳板机上，机器重启任务就丢，没人发现。
• 凌晨跑批的脚本互相抢资源，谁先谁后靠人工改cron表达式协调。
• 任务挂了只能靠同事“早上进群艾特我”来发现，日志还要去机器上一行行翻。
• 想临时跑一次历史数据，得手动改脚本参数，跑完再改回来。

这些场景堆到一定规模后，靠人工已经撑不住了。我们统计了一下，高峰期光定时脚本就有两百多个，每天人工盯着看都看不完，更别提排查历史执行记录和做数据回溯。所以当项目立项时，我们把“调度”当作一个独立系统来做，代号就叫ax。

ax解决的并不是“怎么写任务”，而是“任务怎么被管理、被触发、被执行、被追踪”。按我的理解，它把原来散落在脚本里的调度逻辑全部收拢到一个平台，让任务从提交、触发、执行、重试到告警的整个生命周期都在掌控之中。

1.2 核心场景与边界

ax调度能覆盖的场景包括：

• 定时执行类：每天凌晨跑数据统计，每小时刷缓存，每周生成报表等，对应cron触发。
• 延时触发类：订单支付后15分钟未支付自动关单，用户注册后延时发送欢迎短信等，对应延时队列。
• 依赖编排类：A任务跑完才能跑B任务，B和C并行跑完再跑D，对应DAG工作流。
• 手动补跑类：数据修复时需要把之前失败的历史任务重新执行，对应手动触发与重跑。

边界也很清楚：ax不负责业务逻辑，业务流程是任务自身的代码；ax也不做分布式计算，它只负责把任务“正确地、按顺序地、不重不漏地”调度起来。想明白这条边界，后面做架构设计时就不会给自己挖坑。

2. 整体架构拆解：调度中心如何撑起分布式任务

2.1 三大核心模块

ax整体拆成三块：调度中心、执行器、管理端。

调度中心是大脑，负责解析触发规则、生成调度指令、分发任务、接收心跳与执行结果。执行器是手脚，部署在业务机器上，收到调度指令后创建任务线程执行，执行过程中上报日志和状态。管理端是脸面，提供Web页面让用户创建任务、查看执行记录、配置告警。

模块划分的原则是“调度与执行分离”。如果调度和执行都在一台机器上，任务一多机器就扛不住，且无法做到高可用。分离之后，调度中心可以独立横向扩展，执行器也可以按业务线分批部署，互不干扰。

2.2 调度中心的选型逻辑：为什么用时间轮

调度引擎最核心的数据结构，我们对比过最小堆和定时扫描两种方案。最小堆按触发时间排序，每次取堆顶即可，复杂度O(1)取任务，O(logN)插入，效率高但实现难度大，且处理“取消任务”时需要遍历定位。定时扫描则简单粗暴：每秒钟扫一遍所有任务，把到期任务拿出来跑，但任务量一大，这每秒一次的全表扫描既是CPU杀手，也扛不住毫秒级触发需求。

我们最终选了时间轮方案。时间轮本质是一个环形数组，每个槽位挂一个任务链表。指针按固定间隔跳动，跳动到哪个槽位，就把槽位上的所有任务取出来执行。我举个例子方便理解：设定槽位数为60，每个槽位代表1秒，那么指针转一圈就是1分钟。一个任务5秒后触发，就挂在第5个槽位；1分半后触发，就挂在第2圈的某个槽位并记录剩余圈数。查询和插入都是O(1)，非常适合延迟一秒级的定时调度。

当然时间轮也不是万能的，它的短板在于不太方便实现“每天凌晨3点执行”这类绝对时间cron。我们的做法是双重判断：外层用cron表达式生成下一次触发时间，内层把“当前时间到下次触发时间”换算为相对延迟，塞进时间轮。这样既保留了cron的灵活性，又享受了时间轮的效率。

2.3 为什么坚持用数据库存任务而不是纯内存

第一批版本我们偷懒，任务注册信息全放在内存Map里，结果一升级重启全丢，还得手动重新注册。后来改成MySQL持久化元数据，Redis只做缓存和分布式锁，才彻底解决这个问题。

任务表里记录了任务ID、名称、cron表达式、执行器定位信息、超时时间、重试策略、创建人、启用状态等。每次调度指令生成前，先查库拿任务元数据，再交给执行器去处理。数据库也就是任务事实的唯一来源。

这里有个小经验：调度记录和任务元数据可以放一张表，但执行日志一定要单独放。任务元数据是“现在该怎么办”，执行日志是“当时发生了什么”。两者生命周期完全不同，日志量级大、查询频率高，混合在一起会让主表的索引和写入性能快速恶化。

3. 实操落地：从零部署一套ax调度平台

3.1 环境准备与依赖清单

部署ax前，先把依赖列清楚。我们用的是经典组合：JDK 1.8+、MySQL 5.7+、Redis 5.0+，构建工具Maven，部署方式推荐Docker Compose，便于快速拉起一套测试环境。

依赖项清单如下：

如果只是本地体验，MySQL和Redis可以用官方镜像跑起来。生产环境建议MySQL主从、Redis哨兵，调度中心至少部署两个节点，这是高可用的底线。

3.2 配置要点：调度中心

调度中心的核心配置文件是application.yml，我把关键项和对应的坑一起说明。

server: port: 8080 spring: datasource: url: jdbc:mysql://127.0.0.1:3306/ax_scheduler?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: ax_user password: ax_pass hikari: maximum-pool-size: 32 minimum-idle: 8 connection-timeout: 30000 ax: scheduler: # 调度线程池大小，建议为CPU核心数的2倍 thread-pool-size: 16 # 触发精度，单位秒，时间轮每个槽位的时间跨度 tick-size: 1 # 任务结果回调超时时间，单位秒 callback-timeout: 30 # 执行器心跳超时时间，单位秒，超过则标记为离线 heartbeat-timeout: 60 alarm: webhook: https://your-alarm-webhook.example.com

有一点必须提醒：HikariCP的maximum-pool-size不要盲目调大。很多同学觉得数据库连接池越大越好，其实连接数一旦超过数据库本身能承受的并发，排队耗时反而会拖垮任务回调。我们的32路连接足够支撑几千个调度任务，实际数据库负载一直很低。

3.3 创建任务的三种触发方式

第一次用ax的人，最容易把“定时任务的写法”和“调度任务的配置方式”搞混淆。在ax里，你不需要在业务代码里写while循环加sleep，只需要在管理端配置一条任务记录。

cron触发是最常见的用法。界面里选择cron类型，填上表达式，例如0 30 2 * * ?表示每天凌晨2点30分触发。要注意的是，ax的cron是基于Quartz语法，星期和月之类的字段规则与Linux crontab不同。比如Linux里周日是0，Quartz里则是1，写错一个数字就是整个任务的调度偏移，这种问题排查起来特别费劲。

延时触发适用于延迟任务场景。配置时填延迟秒数，调度中心会在指定时间后下发执行指令。这个能力替换掉了我们原来自己维护的Redis延迟队列，省了好几次事故。

依赖触发则是通过任务组实现。我们在管理端新建任务时，可以勾选上游任务ID，只有上游全部执行成功，下游任务才进入待调度状态。比如同步订单数据之后才做汇总统计，就用这种方式编排。

3.4 参数与资源估算：线程池、超时、重试

初次部署时最容易犯的错，是线程池和超时时间全凭感觉填。我给出我们测下来的参考逻辑：

线程池大小与任务类型强相关。如果是IO密集型（比如调用远程接口、读写数据库），线程可以多一些，公式为CPU核心数 * 2 + 1；如果是CPU密集型（比如大量计算、压缩解压），则建议CPU核心数 + 1。我们机器是8核，IO密集任务居多，所以就设了16。

超时时间按任务执行时长的P95来定，而不是P999。取P95是为了覆盖绝大多数正常情况，如果直接按最大耗时设置，任务挂死时会拖很久才能被判定失败，告警不实时。我们有个数据同步任务平时2秒跑完，偶尔网络抖动跑15秒，超时设置的是30秒。真挂死时，30秒后能收到告警，刚好来得及人工介入。

重试策略默认是失败后重试2次，每次间隔3秒。这个场景多数用于网络抖动导致的临时失败。但重试必须配合幂等，否则任务执行到一半失败，重试时又会重复插入数据。我们内部在SDK层做了幂等检查，以任务实例ID为幂等键，这样即使同一任务重跑多次，也不会产生脏数据。

4. 调度系统的十大常见问题与排查实录

这里分享一下我们上线以来持续处理的几类高频问题，很多都是数据库和线程层面的细节，不深入排查根本看不到。

4.1 任务不执行或延迟执行

现象：任务配置没问题，时间到了却不执行，或者比预期时间晚了几分钟。

排查思路按照先看调度日志、再看执行器日志、最后看数据库的顺序。如果调度中心日志里根本没有生成调度指令，说明问题出在调度引擎本身。常见原因有两个：

一是调度线程池被打满，时间轮指针在跳动，但线程全被长时间运行的任务占用，新任务只能排队。这种情况要把调度任务和执行任务的线程池彻底分开，调度中心的线程只负责分发指令，不负责执行业务代码。

二是任务被管理员误操作禁用，或者执行器被标记为离线。有一个很容易被忽略的点：执行器时间与调度中心时间不一致。比如调度中心按当前时间比较cron的触发点，如果执行器时钟慢了5分钟，日志上看就会延迟执行。我们在所有机器上统一配置NTP同步，并监控各机器的时间偏移，这是花钱最少但收益很稳的一步。

4.2 同一任务重复执行

现象：任务明明只配置了一次，执行记录里却出现了两条，且执行时间非常接近。

根源多半出在调度中心集群节点同时抢到同一个任务上。在没有分布式锁的情况下，两个节点同时扫描数据库，都判断当前时间大于等于触发时间，于是各自发出调度指令，任务就执行了两次。

解决方案是在Redis里加一个分布式锁，锁的key是任务ID加触发时间，value是机器标识，加锁成功的节点才能下发指令。注意锁的过期时间必须大于调度指令下发到执行器的整个链路耗时，否则锁提前过期，另一个节点又会抢进来。我们设定锁过期时间为30秒，实际链路耗时一般几百毫秒，余量足够。

另外补一个细节：执行器收到指令后，执行前也要做幂等判断，以任务实例ID为核心，判断当前实例是否已经执行过。双重判断可以把风险压到最低。

4.3 任务堆积与队列阻塞

现象：某个上游任务卡住，下游积压了一堆任务，整个链路持续拥堵。

这里容易犯的错是只看到“任务积压”这个表象，拼命加大线程池，结果线程越来越多，数据库连接先被抢光，整个系统雪崩。

正确的做法是梳理任务依赖和执行顺序，给每个执行器配置独立的队列容量，超出的部分直接拒绝并告警，而不是无限排队。比如一个执行器的队列容量设为线程池大小的5倍，数据超出这个量说明系统已经过载，需要人工介入而不是让任务继续堆积。

另外，在DAG编排里设置阻塞策略：上游任务失败，下游任务可以选择跳过、等待或者触发告警，不要让其无限等待挂起。我们默认策略是失败即停，快速暴露问题。

4.4 日志文件与磁盘占满

现象：执行器机器提示磁盘空间不足，查看日志目录发现单个任务日志就有好几个G。

排查后发现，每个任务执行都会输出日志，执行失败时还会打印堆栈，长时间运行下来日志增长速度极快。解决方法是日志按时间滚动加上按大小滚动双策略，我们设置单个文件最大100MB，保留最近30天，超过自动清理。

还需要注意日志与任务结果要解耦。不要把任务的执行结果放在日志里解析，调度中心只看回调上报的success/fail状态。日志只是辅助排查，不参与核心调度逻辑，这样即使日志写满磁盘，也不会影响调度状态的准确性。

4.5 数据库连接池被偶然拖垮

现象：某天突然大量任务执行失败，错误日志显示无法从连接池获取连接，但数据库本身负载并不高。

一开始我们怀疑是慢查询，通过慢日志排查发现完全没有。后来定位到是某几个任务在短时间内高频查询执行记录表，且每次查询都用了非索引字段，导致单次查询虽然不慢，但并发量一大，每条连接都长时间占用不释放。

解决办法分两步：第一步，给执行记录表加查询频率最高的索引组合，我们加了任务ID加触发时间的联合索引；第二步，把管理端的列表查询都改为只查最近7天的数据，历史数据走归档表，避免一次扫描全表。

4.6 常见问题速查表

5. 一次完整的数据集群迁移实操记录

讲一个我们真实经历的场景，能串联起前面所有的知识点。

那周我们决定把某业务线的调度任务从旧集群整体迁移到新集群。原计划是逐一停旧任务，再逐个建新任务，后来发现步骤太多容易遗漏。最终采用的方式是“切换执行器定位地址”。

具体做法：任务配置保持不变，只把执行器路由策略从旧集群切换到新集群。调度中心在分配任务时，会优先选择列表靠前的执行器地址，于是新任务自然偏向新集群。切完后先观察新集群日志，确认数据同步正常，再逐步下线旧集群执行器。整个过程用一个配置开关控制，回滚也方便，不需要改动任务本身。

迁移中遇到的问题：旧集群部分执行器因为参数配置不同，时钟偏慢，迁移后出现任务补跑的现象。排查后确认不是新集群的问题，是旧集群最后一批任务触发时间早已超出当前时间，调度中心检测到“过期任务”后做了补偿执行。这里我们给补偿执行加了开关，只允许手动开启且默认不补偿超过1小时的任务，避免类似因为时钟偏差或停机维护导致的成批补跑。

我个人从这次迁移中得到的经验是：调度系统的迁移，核心不是搬代码，而是搬状态。任务配置可以重建，执行记录和状态必须保留，否则出了问题连去哪儿排查都不知道。我们迁移前先做了一次全量备份，迁移完成后对比新旧集群的执行记录数，确认对得上才真正收工。

6. 关于ax调度的几点切身总结

ax整套做下来，回头看，最大的感受是：调度系统不是“写一个定时器”那么简单，它实际是在管理系统的可用性边界。

如果你想在自己的团队落地类似的东西，我建议先不要急着铺开所有功能，从小闭环开始。第一版只做定时触发加执行记录，第二版再加失败重试和告警，第三版再做依赖编排和分布式部署。循序渐进，比一次性搭个大而全的系统稳妥得多。

还有两个小技巧想分享给正在做调度系统的朋友。第一，任务元数据和执行日志永远分开存储，否则当执行记录膨胀时，你的整个调度系统都会跟着变慢，这不是存储问题，是架构问题。第二，报警通知要区分“任务失败”和“任务连续失败N次”，后者要升级到值班群或者电话，否则一次网络抖动就能把你的告警群刷屏，真出大问题时反而没人看。

ax这个名字我们一直沿用至今，连文档都没改过。所谓“调度”，本质上就是用一套可靠的机制把不确定的现场变成确定的流程。“确定性”这三个字，才是调度系统给业务带来的最大价值。