用Nacos替代XXL-JOB：轻量定时任务调度方案与实践

这个标题不是我起的标题党是我最近在某个内部系统里真的做了这件事把一个还在稳定运行的 XXL-JOB 调度集群逐步替换成一套以 Nacos 为核心的轻量调度方案。替换完之后最直观的感受就是部署清单里少了一个调度中心要维护的数据库表少了一批任务却还在老老实实地跑。如果你也遇到过类似的场景——系统里只有几十上百个定时任务逻辑不复杂但每次想调整任务周期都要上一次调度平台想给某个任务换个执行节点还得去改路由策略——那这篇内容很适合你。我会把方案选型的思考过程、核心机制、一个能直接拿出来跑的 Demo以及我在生产环境踩过的几个坑按实操顺序完整写出来。先说清楚这套方案的适用边界它不打算替代功能庞大的分布式任务平台而是用更少的组件、更轻的接入成本解决大部分中小团队真正面对的“定时任务怎么跑、节点挂了怎么办、任务周期怎么动态调整”这三个核心问题。1. 为什么那么多人想换掉 XXL-JOB但很多人只是想想而已1.1 XXL-JOB 到底“笨重”在哪我最早接 XXL-JOB 的时候第一感觉是这东西功能确实全。可视化界面、执行日志、失败告警、分片广播、动态修改 cron几乎能想到的运维能力都有。但用着用着问题就慢慢浮现出来了。首先要部署一台调度中心也就是 xxl-job-admin。这台东西虽然能打成独立服务跑但既然它挂了会影响所有任务调度你就必须把它当核心组件去运维要考虑高可用、考虑持久化数据库、考虑备份。一个几十个任务的系统为了“调度”这个动作单独维护一套服务成本其实挺高的。其次是执行器和调度中心之间有大量状态同步。执行器启动后要往调度中心注册调度中心要记录执行器的 ip、端口、分组信息还要维护一个调度日志表。任务每次执行都会写入日志时间长了这张表数据量会持续增长又得考虑日志清理策略。数据库成了整个调度链路的强依赖数据库一抖动调度任务也跟着飘。再有就是接入带来的代码侵入。业务服务要引入执行器依赖还要自己实现 JobHandler再由调度中心通过 HTTP 把任务调用打到业务服务上。这在架构上形成了一条额外的调用链路出了问题排查路径比普通业务调用更长。不是说 XXL-JOB 不好它本身在大型复杂调度场景下极其成熟。但回到自己的项目上下文里我发现它解决的问题我可能只有两三个在用它引入的运维负担我却要全部承受。这种“功能溢出”就是笨重感的来源。1.2 换之前先想清楚你真的需要换吗在我动手之前我先列了一张清单问自己这几个问题任务量有多大如果超过三五百个或者存在复杂的任务依赖关系那不要轻易换现有调度平台的编排能力是你的核心竞争力。是否需要可视化管理如果团队里有较多非技术角色需要看任务执行情况调度中心的管理界面可能是刚需。是否频繁调整任务参数如果任务周期常年不变化那动态调整这个优势对你的价值就有限。当前系统是否已经依赖 Nacos这是很关键的一个决策点。如果服务发现和配置管理本来就在用 Nacos那么在此基础上做调度改造的边际成本会低很多。我当时所在的某中后台系统已经有 Nacos 在承担注册中心和配置中心任务总量不到一百个定时任务的核心诉求就两个按周期跑、节点挂掉后能自动漂移。管理界面需求很弱大部分任务日志其实都是业务打点并不依赖调度平台展示。这种情况下继续保留一个独立调度中心确实不划算。这也是我选择走向 Nacos 路线的直接原因不是推翻现有调度体系而是把“调度中心”这个概念本身从架构里拿掉用现有组件组合出一个更轻的调度能力。2. 方案选型为什么是 Nacos而不是自研定时器2.1 几种常见替代方案的对比换掉 XXL-JOB 之后要做什么这个问题我原本可以很简单地回答每个服务自己起一个线程池用 Cron 表达式调度不就行了。但这样做的结果是任务分散在各业务服务里没有统一配置入口也没有节点存活感知。所以自我梳理时我对比了四种路线方案维护成本动态调整配置节点感知防重复执行适合场景纯本地定时器低但要自己散落管理极弱基本要改代码发版无靠自己写几乎没有复杂组织需求的小工具Quartz 集群模式中需要共享数据库弱改 trigger 要连库操作依赖数据库锁用数据库锁实现没有注册中心的中型老项目自研分布式调度框架高自己实现自己实现自己实现团队大、工期足、需求极其特殊Nacos 配置 注册中心组合低复用现有设施强配置变更秒级推送强临时实例自动摘除配合锁或 leader 判断已有 Nacos 生态的中小团队我最终选了最后一行理由并不复杂Nacos 在我现有技术栈里已经存在不需要额外引入新组件也不需要单独维护调度库。它天然提供了两个对调度非常有利的能力一个是配置中心的长轮询推送一个是注册中心的临时实例健康检查。这两个能力叠加起来正好覆盖调度系统里最核心的“任务配置管理”和“执行节点动态感知”。2.2 基于 Nacos 的调度方案整体思路这个方案的设计思路简单说就是三段式配置集中、节点发现、锁兜底。配置集中所有任务的定义包括任务名称、cron 表达式、参数、执行策略统一放到 Nacos 配置中心的某个 dataId 下。节点发现每个业务服务实例启动时把自己注册到 Nacos 的某个 service 下作为任务执行节点。临时实例会随服务下线自动从注册表移除不需要额外做心跳清理。锁兜底对于全局只能执行一次的任务在执行前通过 Redis 分布式锁或 Nacos 自身能力做互斥避免多节点同时触发造成重复执行。这套架构里没有一个“中央调度器”。每个节点在本地维护一套调度计划配置一变本地计划跟着变。任务触发时由节点自身发起执行而不是等待外部调度平台来调用。这就避免了调度中心这个单点也省掉了执行器注册、回调通知那套复杂链路。用一句话概括我当时的想法调度本质上只是“时间到了找个人干活”。既然节点自己都知道时间为什么还要找个中介来通知它呢你只需要保证大家的“共识配置”一致、节点之间不会干重活、下线节点及时退出就够了。3. 核心机制拆解不写调度器也能做调度3.1 用配置中心承载任务定义第一步要解决的是任务定义存储问题。以前任务定义在调度中心的表里现在我把它们放到 Nacos 配置中心用 YAML 格式维护。配置结构大概长这样tasks: - name: syncOrderTask cron: 0 0/5 * * * ? scope: global handler: com.example.task.SyncOrderTask params: pageSize: 100 enable: true - name: cleanLocalCache cron: 0 * * * * ? scope: instance handler: com.example.task.CleanLocalCacheTask每个任务的核心字段就四个执行周期、执行范围、业务处理器、参数。配置放在配置中心后最大好处是任务调整不需要发版。我改一下 cron发布配置所有节点很快都会收到新的配置内容。用 Nacos 还有个细节值得提一下配置变更不是靠定时轮询而是长轮询机制。客户端和 Nacos 服务端保持连接一旦配置发生变化服务端会主动推送变更事件。实测下来配置发布后到节点感知通常在一秒以内。这个速度对大多数定时任务场景完全足够。3.2 用服务发现做节点管理与路由配置中心解决了“任务长什么样”的问题接下来要解决“任务由哪个节点执行”。Nacos 的注册中心天然适合干这件事。我在服务启动时往同一个 service 名下注册当前实例NacosNamingService namingService new NacosNamingService(127.0.0.1:8848); // 当前实例注册 Instance instance new Instance(); instance.setIp(localIp); instance.setPort(8091); instance.setServiceName(task-worker); namingService.registerInstance(task-worker, instance);注意这里用的是临时实例模式。临时实例和 Nacos 服务端之间有心跳机制实例宕机后心跳停止Nacos 会在几十秒内把它从健康列表里摘除。这比自己在数据库维护一张节点心跳表要省心得多。当一个任务需要指定某个节点执行时可以通过 NamingService 获取当前健康实例列表再按简单轮询策略选择一个Instance selected namingService.selectOneHealthyInstance(task-worker); // 把任务参数发给对应节点执行 String target selected.getIp() : selected.getPort(); sendExecCommand(target, taskName, taskParams);看到这里你可能会问这个方案还是需要把任务转发给别的节点跟中心化调度不是一样吗区别在于这里没有独立调度中心节点节点之间的信息来自 Nacos 注册中心而且每个节点也具备本地执行能力。路由只是为了让任务在集群中均匀分布或者说让某个任务固定落在某一类节点上。需要注意的是临时实例的摘除不是实时秒级。实际生产环境里节点宕机到实例被摘除通常会有几十秒的过渡期。如果你的任务对“节点故障转移时间”要求特别高就要设计更快的探活机制。但对多数定时任务场景来说几十秒的延迟完全可以接受。3.3 用锁来兜底全局任务配置也有了节点也有了但还有一个隐藏问题如果每个节点都在本地用 cron 触发同一个任务那所有节点都会在相同时间点执行它这显然不行。有两种处理思路第一种给任务加一个 scope 字段。global 表示全局只能有一个节点执行instance 表示每个节点各自执行。对于 instance 类型多节点同时跑是预期行为比如清理本地缓存不需要加锁对于 global 类型需要做互斥。第二种互斥用 Redis 分布式锁解决。执行前先尝试加锁String lockKey task:lock: taskName; boolean locked redisTemplate.opsForValue() .setIfAbsent(lockKey, localIp, 2, TimeUnit.MINUTES); if (locked) { try { executeTask(taskName); } finally { redisTemplate.delete(lockKey); } } else { // 其他节点已经抢到锁本次跳过 log.info(task {} already executed by another node, taskName); }这里有个关键点锁的过期时间一定要根据任务最长执行时间去估算。我一开始设过很短的过期时间任务还没执行完锁就自动释放了结果另一个节点又抢到锁造成了重复执行。后来我把锁过期时间统一改成任务预估超时时间的两倍问题才解决。更稳的做法是加锁续期机制但那是另一个话题。在大多数定时任务场景里只要根据实际执行耗时设置一个合理阈值就已经足够。4. 落地一个最小可跑起来的 Demo光讲原理容易飘我直接把当时验证方案可行性的最小 Demo 拿出来。代码不算复杂照着敲一遍就能跑起来。4.1 环境准备需要准备以下内容Nacos 服务端本地启动即可2.x 版本都行JDK 8 或 11一个正常的 Maven 工程如果是验证锁逻辑还需要一个 Redis和部署调度中心相比这已经少了很多东西。不需要初始化任何数据库表Nacos 本身自带存储能力。Maven 依赖只多加一个 Nacos Clientdependency groupIdcom.alibaba.nacos/groupId artifactIdnacos-client/artifactId version2.2.0/version /dependency4.2 任务注册与配置监听的核心代码这是一个简化版的调度器核心类负责监听配置变化并动态刷新本地任务public class NacosTaskScheduler { private final Scheduler quartzScheduler new StdSchedulerFactory().getScheduler(); private final NacosConfigService configService; public NacosTaskScheduler() throws Exception { Properties props new Properties(); props.put(serverAddr, 127.0.0.1:8848); this.configService new NacosConfigService(props); } public void start() throws Exception { quartzScheduler.start(); // 添加配置监听器 configService.addListener(task-config.yaml, DEFAULT_GROUP, new Listener() { Override public Executor getExecutor() { return Executors.newFixedThreadPool(4); } Override public void receiveConfigInfo(String configInfo) { reloadTasks(configInfo); } }); } private void reloadTasks(String configInfo) { // 解析 YAML遍历 tasks动态添加或更新 Quartz Job ListTaskDefinition tasks YamlUtils.parseTaskList(configInfo); for (TaskDefinition task : tasks) { // 同一个任务用同一个 jobKey动态更新 cron JobKey jobKey JobKey.jobKey(task.getName()); if (!quartzScheduler.checkExists(jobKey)) { JobDetail job JobBuilder.newJob(TaskDispatchJob.class) .withIdentity(jobKey) .usingJobData(taskName, task.getName()) .build(); CronTrigger trigger TriggerBuilder.newTrigger() .withIdentity(task.getName() Trigger) .withSchedule(CronScheduleBuilder.cronSchedule(task.getCron())) .build(); quartzScheduler.scheduleJob(job, trigger); } } } }这段代码把调度动作全部放到本地执行。Quartz 在这里只负责按 cron 触发不负责集群协调所以不需要配置 Quartz 自带的集群同步表省掉那套靠数据库锁抢占 trigger 的机制。TaskDispatchJob 的执行类内部就是前面提到的那段分布式锁逻辑。拿到锁就执行拿不到就跳过。4.3 实测流程我看到了哪些现象我当时启动了两个 worker 实例分别监听同一个配置然后按下面这个流程操作第一步往 Nacos 配置中心的 task-config.yaml 里发布一个 syncOrderTaskcron 设为每 5 秒跑一次。两个 worker 都在 1 秒内收到了配置变更事件本地 Quartz 调度器都创建了对应 Job。第二步观察任务执行日志。因为 syncOrderTask 是 global 类型每次触发时两个 worker 都会尝试抢锁。结果显示同一个时间点只有一个 worker 打印了执行日志另一个 worker 打印跳过日志。第三步手动杀掉其中一个 worker。按理说剩下的 worker 会继续在本地按照 cron 触发任务并执行事实也确实如此。没有调度中心去重新分配任务因为任务本来就没有绑定到某个特定节点。这个流程最大的收获是让我确认了一个事实任务全部跑在每个节点自己进程里调度中心只是一个配置广播和节点感知的底座。节点少了一个任务并没有丢只是执行权完全落到了另一个节点上。5. 生产环境中的坑我帮你踩过几个方案跑通容易上了生产才会遇到真问题。这一节我记录几个自己实际遇到并且排查过的问题应该能帮你少走一段弯路。5.1 配置全量刷新引发任务空窗第一个坑出在最开始的实现里。我当时偷懒收到配置变更后先把调度器里所有 Job 全部移除再重新根据新配置添加。这种做法在配置里任务数量少的时候看不出问题一旦任务数量上了五十个移除和重建之间会有一小段空窗可能有几秒没有任何任务能触发。排查起来也很简单当时我发现某一个本该每分钟跑一次的任务日志里中间断了两次。后来我改成增量更新解析新旧配置对比任务列表只对新增任务添加对删除任务移除对 cron 变化的任务更新 trigger。尽量保持旧任务不动空窗问题就消失了。5.2 分布式锁过期导致重复执行前面提过这个问题再展开一下。当时有一个数据同步任务正常执行需要三十秒左右我最初把锁过期时间设成了十秒。结果任务跑到一半锁过期了另一个节点立刻抢到锁又开始同步同一批数据两边同时写同一个目标表。好在写入逻辑本身没有唯一约束否则会产生重复数据。这个问题的根源是锁过期时间和任务真实执行时间不匹配。后来我在锁的设计上加了一条规则锁过期时间必须大于该任务历史执行耗时并且在任务代码里增加了每小步的幂等判断。对于特别耗时的任务要么拆成多个子任务要么做续期不要指望一个固定过期时间覆盖所有情况。5.3 Nacos 配置监听回调线程池别开太小Nacos 配置监听回调里可以自定 Executor如果你不提供它就用默认线程池执行。这个线程池如果开太小当任务数量多、配置变更频繁时回调可能长时间排队任务更新时间就会明显延迟。我当时有这样一个现象发布一条配置等了十几秒任务才更新。查了一下监听回调的线程池线程数只有 2而当时任务已经达到三十多个更新时的 YAML 解析和 Job 调度操作比较耗时。后来把回调线程池调成 8配置推进速度恢复正常。一个小细节调试阶段看日志如果 Nacos 客户端里出现大量长轮询线程不要慌那是正常设计不是线程泄漏。5.4 任务执行结果的记录还是得靠业务自己XXL-JOB 自带执行日志和调度记录换成轻量方案后这些能力就没了。你需要在业务代码里自己记录任务执行结果包括开始时间、结束时间、成功与否、执行耗时。否则排查问题时会非常痛苦因为你只知道任务没跑但不知道它为什么没跑。我的做法是统一封装了一个 TaskExecutionLogger任务执行开始和结束时分别打一条结构化日志包含任务名、节点 ip、参数摘要和执行时间。后续要用图表看任务健康度时直接把日志同步到日志平台按任务名聚合即可。下面整理一个速查表方便在生产环境遇到问题时对照现象可能原因解决方案配置发布后任务迟迟不更新监听线程池太小或配置没匹配调整回调线程池大小检查 dataId / group任务重复执行分布式锁过期时间太短加大锁过期时间增加幂等必要时做锁续期某个节点挂了任务中断太久临时实例摘除需要时间等 Nacos 心跳超时或自行实现加速探活所有节点同时执行 global 任务锁逻辑未生效检查 Redis 连接确认锁 key 是否一致任务日志分散在各个节点没有统一日志收集接入日志平台按任务名聚合这套方案我用了几个月之后最深的体会是它把调度从“一个平台组件”降级成了“业务系统自带的一种能力”付出的代价是你需要自己承担一部分任务展示和记录功能。但这笔账对我来说是划算的因为团队不再需要专门维护一个调度中心的可用性了。最后分享一个小建议如果你也在考虑做类似的改造不要一上来就追求完整方案。先从最简单的“把任务配置放到 Nacos 里监听”开始试水等跑顺了再逐步补上路由和锁逻辑你会发现这条路比想象中要短很多。