服务端开发博客 | 后端架构 · 高并发 · 性能优化 · 微服务实战 👋🏼

引言 凌晨 3 点被电话叫醒，打开日志发现定时任务又双击了——上次跑的实例还没结束，这次又开始了，两份并行把库存扣了两遍。这不是什么复杂的分布式 bug，就是单机 @Scheduled 在多实例部署下没有做幂等也没有做调度协调，各跑各的。 找运维要个控制台看看任务状态，答："没有控制台，任务定义在代码里，改 Cron 要重新发版。" 要个失败重试和告警，答："自己写 log + 钉钉机器人。" 要个任务执行历史，答："去 ELK 里搜。" @Scheduled 是个很好的起点，但业务长到"多实例部署 + 任务可视化 + 动态调整 + 失败告警"这四件事里的任何一个，它就不够用了。 团队开始找替代方案：Quartz？XXL-Job？PowerJob？每个方案看起来都能解决一部分问题，但谁也说不清哪个最适合自己。这篇文章把四个方案按"从简单到复杂"排开，逐个拆解能力边界，最后给一张决策树——照着选就行。 一、四个方案速览 1.1 一句话定位 方案一句话定位调度 vs 执行 @ScheduledSpring 原生注解，单机定时器应用内线程池 QuartzJava 生态老牌调度框架，....

引言 上个月的月结对账又双叒出问题了。凌晨 2 点的对账任务跑了 40 分钟，账单数据多了一倍——排查发现，两个订单服务实例各跑了一遍对账。单机时代用 @Scheduled 的代码，在部署第二个实例的那天起就埋下了这颗雷：没有分布式锁、没有分片、没有失败重试、没有告警，任务挂了只能靠第二天报表对不上才发现。 我们要的能力其实很明确： 需求@Scheduled 的现状期望 多实例不重复执行❌ 每个实例都会跑集群下同一任务只跑一次 大数据量提速❌ 单线程慢分片并行：10 个实例各处理 1/10 数据 任务失败感知❌ 日志里默默报错自动重试 + 告警通知 动态调整执行时间❌ 改 cron 要重启控制台改完立即生效 执行记录可查❌ 无记录每次执行的耗时/结果/日志留痕 手动触发/停止❌ 不支持控制台一键执行、终止 这些需求拼在一起，就是一个"分布式定时任务平台"。业界答案是 XXL-Job——它优雅地解决了上面所有问题，而且实现思路并不神秘。这篇文章先拆解 XXL-Job 的核心架构（调度中心做什么、执行器做什么、双方怎么协作），然后手写一个精简版：Quartz 调度 + HTTP....

做过分布式任务调度的同学肯定都遇到过这个问题：分片任务执行时，分片 0 先完成了，分片 1 还在跑，如果直接进入下一步可能会导致数据不完整。我之前就遇到过这样一个案例：一个数据汇总任务，分片 0 处理华东区数据，分片 1 处理华南区数据，分片 0 完成后就开始汇总，结果分片 1 还在处理，导致汇总数据只有华东区，漏掉了华南区。 今天我们就来聊聊 XXL-JOB 分片广播场景下的乱序处理问题，以及如何用全局屏障机制确保数据完整性。 分片广播的乱序问题 1. 什么是分片广播 XXL-JOB 分片广播原理： 执行器集群： ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ 执行器 0 │ │ 执行器 1 │ │ 执行器 2 │ │ (分片0) │ │ (分片1) │ │ (分片2) │ └─────────────┘ └─────────────┘ └─────────────┘ │ │ │ ▼ ▼ ▼ 处理数据A 处理数据B 处理数据C │ │ │ ▼ ▼ ▼ 完成 进行中 等待中 调度器一次广播，所有分片同时执行！ 2. 乱序问题的典型场....

一、执行器失联的痛点 上周，一位做金融系统的朋友吐槽：他们的订单处理系统每天早上9点准时"发呆"，所有定时任务都不执行，导致大量订单积压。 "我们已经排查了一整天，"朋友焦虑地说，"发现执行器和调度中心之间的心跳断了，但不知道为什么，也没办法自动恢复。" 我查看了他们的监控数据，发现问题确实很严重： 每天早上8:55左右，执行器集体失联 失联后任务堆积，最严重时积压超过 10 万条 人工介入需要 30 分钟才能恢复 每天早上准时出现问题，影响大量用户 更关键的是，他们根本不知道问题出在哪里，是网络抖动、服务器负载过高，还是 XXL-JOB 本身的 bug？ 二、传统方案的局限性 1. 人工恢复 通过管理后台手动点击"删除执行器"然后重新注册。 这种方案的问题： 响应慢：人工介入需要时间，任务持续积压 无法预测：不知道什么时候会出问题 消耗人力：需要专人值班盯着 体验差：用户等待时间长，投诉多 2. 定时心跳检测 通过定时任务检测执行器状态，发现失联后发送告警。 这种方案的问题： 只能告警：发现问题后还是需要人工处理 滞后性：检测到问题时，可能已经积压了很多任务 无法自愈：不能....

在早期的小项目中，我们可能会直接用Timer、ScheduledExecutorService这些JDK自带的定时器。但随着业务越来越复杂，用户量越来越大，你会发现这些简单的定时器根本扛不住： 单点故障：一旦服务器挂了，所有定时任务都停摆 无法监控：任务执行成功还是失败，你根本不知道 扩展困难：任务多了之后，代码混乱得像一锅粥 容错性差：任务执行失败了，没有重试机制 分布式的挑战：在微服务架构下，任务执行节点分散，难以统一管理 这时候，你就需要一个专业的任务调度系统了。今天咱们就来聊聊两个业界主流的调度框架：XXL-JOB和Quartz，以及如何搭建一个高可用的调度平台。