那天上午,客服转来一条用户投诉,内容让我心里咯噔一下:"你们的对账邮件,我今天早上一口气收到了三封,一模一样,是不是系统出 bug 了?"我第一反应是邮件服务重试了?可一查,发邮件的代码确确实实只被"成功"调用了三次,每次都正大光明地发了一封——不是重试,是实打实地执行了三遍。而这个发对账邮件的任务,是一个每天凌晨定时跑一次的定时任务,逻辑里清清楚楚写着"每个用户发一封",怎么会发三封?
真相,藏在一个我们为了"高可用"而做的、本身完全正确的决定里:为了不让服务单点故障,我们把它部署了 3 个实例。这本是好事——挂了一个还有两个顶着。可问题在于,那个定时任务的代码,是和业务代码写在一起、随服务一起部署的;于是这 3 个实例,每一个都"尽职尽责"地在凌晨那个点,各自把这个定时任务跑了一遍——同一个"给所有用户发对账邮件"的任务,被三个实例同时执行了三次,于是每个用户就收到了三封。这是从单机走向集群、走向多实例部署时,几乎每个团队都会踩的一个经典的坑:定时任务,在多实例环境下被重复执行了。这篇文章,就从这次"对账邮件发三遍"的事故讲起,把分布式环境下定时任务这件"单机时代天经地义、集群时代处处是坑"的事,讲清楚。
故障现场:三个实例,三份"尽职尽责"
先把背景和代码还原一下。我们用的是很常见的 Spring 的 @Scheduled 注解来写定时任务,逻辑大概是这样:
@Component
public class ReconcileJob {
// 每天凌晨 2 点执行一次: 给所有用户发对账邮件
@Scheduled(cron = "0 0 2 * * ?")
public void sendReconcileEmails() {
List<User> users = userService.listAll();
for (User u : users) {
emailService.sendReconcile(u); // 给每个用户发一封
}
}
}
这段代码,在单机时代,是完美无瑕的——一个服务实例,凌晨 2 点,跑一次,每个用户一封,皆大欢喜。可当我们为了高可用,把这个服务部署成 3 个实例时,情况就变了:这 3 个实例,运行的是完全相同的代码,各自都有一个独立的、在本地跑着的定时任务调度器。它们彼此完全不知道对方的存在,也没有任何协调机制。于是凌晨 2 点一到,3 个调度器同时触发,3 个实例各自吭哧吭哧地把"给所有用户发邮件"完整地跑了一遍——它们都觉得"这是我该干的活",而谁也不知道另外两个也在干同一件事。
结果就是:用户被发了三遍邮件。这次还算"温柔"的——只是邮件烦人。但你可以想象,如果这个定时任务干的不是"发邮件",而是"给每个用户结算、扣款""生成账单""发放优惠券"呢?那就是重复扣款、重复发券、重复生成数据——是能直接造成资金损失和数据错乱的重大事故。定时任务重复执行的可怕之处,正在于此:它在单机时代是隐形的(根本不会发生),却在你为了高可用而扩成多实例的那一刻,悄无声息地变成了一颗定时炸弹,而且任务的副作用越"重",炸得越狠。
第一件事:理解"无状态扩容"和"定时任务"的天然矛盾
要理解这个坑,得先想明白一件事:为什么我们的服务能随便扩成多实例?因为我们的业务接口是无状态的——每个请求由哪个实例处理都一样,加机器、减机器,负载均衡器分流一下就行,实例之间不用协调。这正是无状态设计的巨大优势:可以随意水平扩展。可定时任务,恰恰打破了这个前提。
无状态接口扩容:天然合理
请求A → 负载均衡 → 实例1 处理 ┐
请求B → 负载均衡 → 实例2 处理 ├ 各处理各的, 互不干扰, 越多越快
请求C → 负载均衡 → 实例3 处理 ┘
定时任务"扩容":天然出错
凌晨2点 → 实例1 的调度器触发 → 跑一遍全量任务 ┐
凌晨2点 → 实例2 的调度器触发 → 跑一遍全量任务 ├ 同一个任务被干了3遍!
凌晨2点 → 实例3 的调度器触发 → 跑一遍全量任务 ┘
看出矛盾在哪了吗?对于"处理请求"这种活,多个实例是"分工"——请求被分散到各个实例,多多益善;可对于"定时任务"这种活,多个实例却变成了"重复"——同一个任务,被每个实例各自完整地干了一遍。根源在于:普通业务请求是"外部触发、由负载均衡分配给某一个实例"的,天然只会被处理一次;而内嵌的定时任务是"每个实例内部的调度器自己触发"的,没有任何机制保证"全局只触发一次"。所以,把"会产生全局副作用的定时任务",直接内嵌在"会被多实例部署"的无状态服务里,这个组合本身就是矛盾的、是 bug 的温床。认清这个矛盾,是解决问题的第一步。
第二件事:正解之一——用分布式锁让任务"只跑一个"
解决思路的核心,是给这个"全局只该执行一次"的任务,加一道全局的互斥:虽然 3 个实例的调度器都会在凌晨 2 点被触发,但要让它们去抢一把所有实例共享的锁,谁抢到谁执行,没抢到的就乖乖跳过。这就是分布式锁的用武之地——它是一把存在于所有实例之外(比如 Redis 里)的、全局唯一的锁。
@Scheduled(cron = "0 0 2 * * ?")
public void sendReconcileEmails() {
// 三个实例都会跑到这里, 但要先抢一把全局的分布式锁
String lockKey = "lock:reconcile:" + LocalDate.now();
// SET key value NX EX 3600: 不存在才设置成功(NX), 1小时自动过期(EX)
boolean got = redis.setIfAbsent(lockKey, instanceId, Duration.ofHours(1));
if (!got) {
log.info("没抢到锁, 说明别的实例在跑, 我跳过");
return; // 没抢到锁的实例直接退出, 不执行
}
// 只有抢到锁的那一个实例, 才会执行到这里
List users = userService.listAll();
for (User u : users) emailService.sendReconcile(u);
}
这段代码的关键,是那个 setIfAbsent(对应 Redis 的 SET key val NX EX):它是一个原子操作——"如果 key 不存在才设置成功并返回 true,否则返回 false"。3 个实例同时来抢,Redis 保证只有一个能设置成功(拿到锁),另外两个都失败、直接 return 跳过。这样,全局就只有一个实例真正执行了任务,重复执行的问题迎刃而解。这里有两个细节至关重要:一是锁必须带"过期时间"(EX)——万一抢到锁的实例执行到一半崩溃了,锁能自动过期释放,否则这把锁就成了永远没人能再拿到的"死锁",任务从此再也不执行;二是 key 里带上日期,保证每天是一把新锁,不会被昨天的锁影响。
分布式锁是解决"多实例下某操作只能执行一次"的通用利器,但用它有不少讲究(过期时间设多长、锁续期、误删别人的锁等),自己手写容易出错,生产中更推荐用成熟的库(如 Redisson 的分布式锁,帮你处理好续期、安全释放等细节)。我把"加锁前 vs 加锁后"的执行流程画成图:
这张图的精髓,在那个所有实例都要去抢的"全局锁"节点——它把原本"各跑各的、互不知情"的 3 个调度器,通过一把外部共享的锁强行收敛成了"只有一个能真正干活"。这其实是分布式系统里一个极其通用的模式:当多个对等的节点都想做同一件"只该做一次"的事时,就让它们去抢一个外部的、全局唯一的协调资源(锁、或选主),用它来裁决"到底谁来做"。
第三件事:正解之二——专业的事交给分布式调度平台
分布式锁能解决问题,但说到底是"打补丁"——你得在每个定时任务里都手动加锁、处理各种边界。当定时任务多起来、需求复杂起来(要分片、要重试、要监控、要手动触发、要看执行历史),自己用锁缝缝补补就力不从心了。这时候,更专业的方案是引入分布式任务调度平台,比如 XXL-JOB、Elastic-Job、PowerJob 等。
分布式调度平台的核心思路: 调度与执行分离
┌─────────────┐ ┌──── 执行器(你的实例1)
│ 调度中心 │ 派发任务 ├──── 执行器(你的实例2)
│ (统一触发) │────────>└──── 执行器(你的实例3)
└─────────────┘
- 调度中心统一决定"何时触发""派给哪个执行器"
- 同一个任务只派给一个执行器执行 → 天然不重复
- 还附带: 失败重试、任务分片(大任务拆给多实例并行)、
执行日志、手动触发、报警监控、任务依赖编排...
这类平台的核心设计,是把"调度"和"执行"分离开:有一个独立的"调度中心"统一负责"什么时候该触发哪个任务",而你的服务实例只作为"执行器"被动地接受派发的任务。调度中心保证同一个任务在同一时刻只派发给一个执行器,从机制上就杜绝了重复执行;而且它还顺带提供了一大堆自己手写分布式锁给不了的能力:失败自动重试、任务分片(把一个大任务自动拆成几片,派给多个实例并行处理,既不重复又能加速)、可视化的执行日志和历史、手动触发、报警监控、任务间的依赖编排……
所以一个实用的选型建议是:如果你只有一两个简单的定时任务,用"分布式锁 + @Scheduled"打个补丁就够了;但如果你有较多的定时任务、或对调度有复杂需求(重试、分片、监控、运维),那就别自己造轮子了,引入一个成熟的分布式调度平台,会让你事半功倍。这背后是一个朴素的工程判断:简单问题用简单方案,复杂问题用专业工具——别用一把分布式锁,去硬扛一个调度平台才该承担的复杂度。
第四件事:最后一道防线——幂等设计
分布式锁也好、调度平台也好,都是从"调度层面"保证任务只被触发一次。但我后来想得更深了一层:万一这层防护还是失效了呢?比如锁的过期时间设短了、网络分区导致两个实例都以为自己拿到了锁、调度平台出了 bug 重复派发……分布式环境下,"恰好执行一次"是出了名的难保证。所以真正稳妥的做法,是再加一道业务层面的兜底——幂等设计:让任务里那些有副作用的操作,即便被重复执行,也不会产生重复的后果。
// 幂等兜底: 即便这段逻辑被重复执行, 也不会重复发邮件
public void sendReconcile(User u) {
String today = LocalDate.now().toString();
// 先尝试插入一条"已发送"记录, 利用数据库唯一索引(user_id + date)去重
boolean firstTime = reconcileLog.insertIfAbsent(u.getId(), today);
if (!firstTime) {
return; // 今天已经给这个用户发过了, 直接跳过, 不重复发
}
emailService.send(u); // 只有"第一次"才真正发送
}
// 关键: reconcile_log 表对 (user_id, date) 建唯一索引,
// 重复插入会失败, 以此保证"每个用户每天只发一次"
这段代码的思路是:在执行有副作用的操作之前,先用一个"唯一标识"(这里是"用户+日期")去一张去重表里登记,登记成功才执行,登记失败(说明已经做过了)就跳过。这样,哪怕上层的调度防护全部失效、这个方法被调用了三次,真正"发邮件"的动作也只会在第一次发生,后两次都会因为登记失败而跳过。幂等的本质,是让一个操作"做一次"和"做多次"的最终效果完全相同——它不依赖"恰好只调用一次"这个脆弱的前提,而是从结果上保证"重复也无害"。
这一点对"重操作"尤其重要:发邮件重复了顶多烦人,但扣款、发券、生成账单这类操作一旦重复就是真金白银的损失,对它们,幂等不是"可选的加固",而是"必须的底线"。我把"防重复执行"的几道防线列成一张表,它们是层层递进、可以叠加的:
| 防线 | 作用层面 | 解决什么 |
|---|---|---|
| 分布式锁 | 调度层 | 多实例只让一个执行 |
| 分布式调度平台 | 调度层 | 统一调度, 天然不重复派发 |
| 幂等设计 | 业务层 | 万一重复执行也不产生重复后果 |
我的建议是:调度层(锁或平台)和业务层(幂等)要结合用——调度层尽量保证"不重复触发",业务层兜底保证"重复了也无害"。尤其是涉及钱、涉及关键数据的任务,绝不能只依赖调度层那一道防线,一定要用幂等再兜一层。因为在分布式的世界里,"恰好一次"是理想,"至少一次 + 幂等"才是现实中更可靠的工程姿态。
第五件事:几种方案怎么选
讲完了所有方案,把它们放一起对比,帮你按场景选型。从最简单的"关掉多余的"到最专业的"调度平台",各有各的位置:
| 方案 | 做法 | 适用场景 |
|---|---|---|
| 单独部署任务实例 | 定时任务从业务服务剥离, 只部署一个 | 任务少且简单, 能接受这个实例单点 |
| 分布式锁 | @Scheduled + 抢 Redis 锁 | 少量任务, 不想引入额外平台 |
| 分布式调度平台 | XXL-JOB/Elastic-Job 等 | 任务多、需重试分片监控等能力 |
| 幂等设计 | 去重表/唯一索引/状态机 | 所有重操作的必备兜底, 与上面叠加 |
选型的核心,还是回到那个朴素判断——用复杂度匹配问题的规模:任务就一两个、又简单,那把它单独部署一个实例、或加个分布式锁,就够了,别上重型平台;任务多、需求复杂,才值得引入调度平台这把"重武器"。而幂等,是独立于上面所有方案的一道业务底线,凡是有副作用、尤其是涉及钱和关键数据的任务,都应该叠加上它。不要一上来就追求最"高大上"的方案,也不要在重要任务上偷懒省掉幂等——合适的,才是最好的。
一张"定时任务上多实例前必问"的决策图
把这次踩坑沉淀成一张图。每当你要把一个带定时任务的服务部署成多实例、或给多实例服务新增定时任务时,照着走一遍:
这张图的主线是"先判副作用,再选调度方案,最后用幂等兜底":没有全局副作用的任务问题不大;有副作用的,按复杂度选分布式锁或调度平台来保证"只执行一次";而只要涉及钱和关键数据,就必须再叠加幂等这道业务底线。走一遍这张图,"多实例下定时任务重复执行"这个经典坑,你就能在部署之前就规避掉。
我立下的几条规矩
这次"对账邮件发三遍"的事故后,团队的规范里加了这么几条:
- 多实例服务里的定时任务必须互斥:凡是会随服务多实例部署的定时任务,一律加分布式锁或交给调度平台,严禁裸跑。
- 分布式锁必带过期时间:防止持锁实例崩溃导致死锁,让任务再也不执行;推荐用 Redisson 等成熟库处理续期与安全释放。
- 重操作必做幂等:扣款、发券、生成账单等有副作用的任务,用去重表/唯一索引兜底,保证重复执行也无害。
- 任务多了上调度平台:任务数量或复杂度上来后,引入 XXL-JOB 等分布式调度平台,别用一堆手写锁硬扛。
- 评审部署架构变更:服务从单实例改多实例时,专门 review 有没有"依赖单实例假设"的逻辑(定时任务、本地缓存、本地锁等)。
- 监控任务执行:记录每个定时任务的执行次数、时间、结果,执行次数异常(比如本该一次却三次)能被及时发现。
- 警惕一切"本地单例"假设:本地缓存、本地锁(synchronized)、内存计数器等,在多实例下都会失效,迁移到分布式时逐一审视。
这几条里,第五、七条是我觉得最有"举一反三"价值的。因为"定时任务重复执行"只是"单机假设在多实例下失效"这一大类问题的一个典型代表。同样会在多实例下"翻车"的,还有:本地缓存(每个实例一份,数据不一致)、本地锁 synchronized(只能锁住单个实例内的线程,锁不住跨实例)、内存里的计数器/限流器(各算各的)、本地文件存储(各存各的)……它们在单机时都工作得好好的,可一旦多实例部署,就都暴露出"我只考虑了自己这一个实例"的隐含假设。所以从单机迈向集群,真正的思维转变是:从"我"到"我们"——你写的每一段有状态、有副作用的逻辑,都要从"只有我一个实例"的视角,切换到"有好多个一模一样的我同时在跑"的视角去重新审视。
写在最后:从"单机思维"到"分布式思维"
这次被"对账邮件发三遍"教育的经历,标志着我编程思维的一次重要升级——从单机思维,向分布式思维的转变。在那之前,我写代码时脑子里默认的模型,始终是"一个程序、一个实例、独自运行":我加个 synchronized 锁就以为锁住了、我写个定时任务就以为它只跑一次、我用个本地缓存就以为数据都在我手里。这些假设,在单机的世界里全都成立,所以我从没意识到它们只是"假设"。可当系统为了高可用、为了扛住流量而走向多实例、走向分布式时,这些藏在我脑子里、我自己都没察觉的"单机假设",就一个个地崩塌了——而"定时任务发三遍",正是其中最典型、最直观的一次崩塌。
想通这次事故,我领悟到分布式思维的内核,其实是一种"去中心化"的世界观:在分布式系统里,不存在一个"唯一的我"——存在的是"许多个对等的、一模一样的我,同时在跑,且彼此不知道对方在干什么"。所以,凡是"全局只能有一个"的事情(只执行一次、只有一个主、全局唯一的计数),都不能想当然地以为"反正就一个实例,自然只有一个",而必须显式地引入某种外部协调机制(分布式锁、选主、分布式调度、共享存储)去达成那个"全局唯一"。单机时代,"唯一"是天然的、免费的;分布式时代,"唯一"是需要你刻意设计、付出协调成本去争取的。这个从"唯一是默认"到"唯一要争取"的认知翻转,是单机思维迈向分布式思维最关键的一步。
所以,如果你的系统也正在(或即将)从单机走向多实例、走向分布式,我想把这次踩坑最想说的话送给你:把你脑子里那个"只有我一个实例"的默认假设,郑重地拿出来检视一遍。问问自己:我这段定时任务,多实例下会不会重复跑?我这个 synchronized,跨实例还锁得住吗?我这个本地缓存,各实例之间一致吗?我这个"全局唯一"的东西,真的全局唯一吗?——把这些藏在代码里的单机假设一一揪出来、显式地用分布式手段去解决,你才算真正完成了从"写单机程序"到"写分布式系统"的蜕变。那封发了三遍的对账邮件,于我而言,正是这场蜕变的起点:它用一个不算严重的小事故,温柔地点醒了我——你的程序,早已不是一个人在战斗了。愿你也能早点完成这次思维的转身,别等到一次"重复扣款"的重大事故,才被迫想明白这个道理。
—— 别看了 · 2026