定时任务可靠性完全指南:从一次"任务跑成三份、还挂了一周没人知道"看懂防重叠、多实例单跑与可观测

2023 年我做一个后端服务,有一堆需要定时跑的活儿——每天凌晨生成报表、每小时同步一次外部数据、每隔几分钟清理过期数据。定时任务这件事,我压根没多想。第一版我做得很省事:定时任务不就是写个 cron 表达式、到点了调一下那个函数?用 APScheduler 之类的库,挂一个 @scheduled_job('cron', hour=3),函数体里该干嘛干嘛。本地开发时——真不错:我把触发间隔调短到一分钟,盯着日志,到点函数就跑、跑完就停,准得很。我心里很踏实:"定时任务嘛,不就是到点调个函数?"可等这个服务真正上线、还部署了多个实例,一串问题冒了出来。第一种最先把我打懵:有个同步任务,某天外部接口慢、它跑了很久还没跑完,下一次触发的时间又到了——于是两个同步任务并发跑起来,抢同一批数据,把数据写乱了。第二种最离谱:为了高可用,这个服务部署了三个实例,每个实例里都跑着同一份 cron——结果每个定时任务,到点都被跑了三遍,报表生成了三份,数据同步了三次。第三种最隐蔽:有个任务跑到一半,服务因为发版重启了,这个任务就停在了半路——它处理了一半的数据,既没真正完成、也没人知道它失败了,留下一堆半拉子状态。第四种最要命:有个清理任务,某天抛了个异常、整个没跑成,可它是静默失败的——没有报警、没有人发现,直到一周后过期数据堆积如山,我才知道这个任务已经挂了七天。我盯着这一连串问题想了很久才彻底想明白,第一版错在一个根本的认知上:我以为"定时任务,就是到点调一个函数"。这句话把定时任务当成了"一次普通的函数调用,只不过触发它的是时钟"。可它不是。一个定时任务和一次普通的函数调用,最根本的区别是:它在一个"有时间、有并发、有故障"的真实环境里,反复地、无人值守地运行。"反复"意味着上一次还没跑完,下一次可能就撞上来了;"无人值守"意味着它失败的那一刻,没有任何人在屏幕前看着;"有并发"意味着你部署的多个实例,会在同一时刻一起触发它;"有故障"意味着它可能在执行到任何一步时,因为发版、崩溃而中断。所以定时任务真正要管的,根本不是"到点触发"这一下——到点触发,库早就替你做好了。它要管的,是这个任务在"反复、无人值守"地运行时的全部可靠性:同一个任务不能重叠执行,多实例部署下只能由一个实例真正跑,任务必须幂等、中途崩了能恢复,而且它的每一次成败都必须能被监控系统看见。真正做好定时任务,核心不是"写对 cron 表达式",而是给任务加防重叠锁、多实例下选一个实例执行、让任务幂等可恢复、给每次执行接上监控告警、再处理好错过补偿与超时。这篇文章就把定时任务的可靠性梳理一遍:为什么"到点调个函数"是错的、怎么防重叠执行、多实例下怎么只让一个跑、任务怎么做到幂等可恢复、成败怎么被监控到,以及错过补偿、任务超时、手动触发、时区这些把定时任务真正做扎实要避开的坑。

问题背景

先把那串问题的现象和我的误判讲清楚,后面所有的设计都是冲着纠正这个误判去的。

现象:一套"到点调个函数"的定时任务,在上线、多实例部署后冒出一串问题:上一次还没跑完、下一次又触发,两个任务并发抢数据、把数据写乱;多实例各跑一份 cron,同一个任务被执行了 N 遍;任务执行中途服务重启,留下半拉子状态、既没完成也没人知道;任务抛异常静默失败,没有告警,挂了一周才被发现。

我当时的错误认知:"定时任务,就是到点调一个函数。"

真相:这个认知错在它只看见了"触发",没看见"运行环境"。它默认定时任务和一次普通函数调用没区别——"到点了,把那个函数叫起来跑一遍"。可一次普通函数调用,是你在代码里主动调的、调一次、当场就能看见它的返回值或异常;而一个定时任务,是由时钟反复触发、无人值守、还在多个实例上一起跑的。就是这几个差别,催生了那一串问题:正因为它反复触发,所以上一次和下一次会撞车;正因为它跑在多个实例上,所以会被重复执行;正因为它无人值守,所以中途崩了没人当场知道、失败了没有告警。这些问题,没有一个是"cron 表达式写错了"导致的——cron 表达式完全正确,任务也确实到点触发了。问题全都出在"触发之后":这个任务在一个并发的、会故障的、没人盯着的环境里运行,而我的代码对这个环境一无所知、毫无防备。所以要做对定时任务,你得换一个视角:别把它看成"一个被时钟调用的函数",把它看成"一个要在恶劣环境里长期、无人值守地稳定运行的小系统"——然后为这个环境里的每一种麻烦,补上对应的防护。

要把定时任务的可靠性做对,需要几块认知:

• 为什么"到点调个函数"是错的——它只管触发,不管任务在并发、故障、无人值守环境下的运行;
• 防重叠——上一次没跑完,下一次触发就跳过,绝不让同名任务并发;
• 多实例单跑——多个实例同时触发,只让抢到锁的那个真正执行;
• 幂等与可恢复——任务重复跑不出错,中途崩了能从断点接着来;
• 可观测——每一次执行的成败、耗时都要能被监控系统看见;
• 错过补偿、任务超时、手动触发、时区这些工程坑怎么处理。

一、为什么"到点调个函数"是错的

先把这件最根本的事钉死:"到点调个函数"这个模型,只覆盖了定时任务生命周期里最简单的一个瞬间——"触发"。它默认:触发之后,函数会安安静静地、独占地、一次性地跑完,然后干干净净地结束。这个默认,在本地开发时百分之百成立——本地只有一个进程,任务跑得又快,你还盯着日志看,所以它从不重叠、从不被重复执行、崩了你当场就知道。可线上的运行环境,恰恰把这几个"默认"逐个推翻:任务可能跑得比触发间隔还久(于是重叠),服务部署了多个实例(于是重复),发版会随时重启进程(于是中途崩溃),没有人盯着日志(于是静默失败)。所以"到点调个函数"不是写错了,而是它只为"触发"这一个瞬间做了设计,却对"触发之后,任务要在什么环境里活下去"这件事,完全没有设计。

下面这段代码,就是我那个"本地一切正常、上线全是坑"的第一版:

# 反面教材:一个只管"到点触发"的裸定时任务
from apscheduler.schedulers.background import BackgroundScheduler

scheduler = BackgroundScheduler()

@scheduler.scheduled_job("cron", minute="*/30")   # 每 30 分钟跑一次
def sync_orders():
    rows = db.query("SELECT * FROM orders WHERE synced = 0")
    for row in rows:
        push_to_downstream(row)                   # 破绽 1:跑超过 30 分钟就和下一次重叠
        db.execute("UPDATE orders SET synced=1 WHERE id=%s", row.id)
    # 破绽 2:三个实例各跑一份,这段逻辑被执行三遍
    # 破绽 3:跑到一半进程被重启,剩下的 row 既没处理也没记录
    # 破绽 4:这里抛了异常,只进日志,没有任何人会收到通知

scheduler.start()

这段代码在本地开发时表现不错,因为本地只有一个进程、数据也少,任务几秒就跑完,我还开着日志窗口盯着——它不可能重叠(就一个进程、跑得又快)、不可能被重复执行(就一个实例)、崩了我当场就看见(我正盯着日志)。它的问题不在某一行语法上——scheduled_job 注册得完全正确——而在它对"任务上线后要运行在什么环境里"这件事的四个想当然:想当然以为任务总在触发间隔内跑完、想当然以为只有一个实例在跑、想当然以为进程不会在任务执行中途重启、想当然以为有人会看日志。这四个想当然,对应的正是开头那四类事故。问题的根子清楚了:定时任务的工程量,全在"触发之后"——你得承认它会重叠、会被多实例重复跑、会中途崩、会没人看着,然后为这每一种情况,补上一道防护。下面四节,就是这四道防护。

二、防重叠执行:给任务加一把锁

第一道防护,补的是破绽 1:上一次没跑完,下一次触发又开跑。这个问题的根源是:"触发间隔"和"任务实际耗时"是两件没有任何关系的事。你设了每 30 分钟触发一次,可任务实际跑多久,取决于这次要处理多少数据、外部接口快不快——某天它跑了 40 分钟,那么在第 30 分钟,调度器会照常触发下一次,于是两个同名任务并发跑起来,一起去抢同一批 synced=0 的数据。解法很直接:给任务加一把锁,开跑前先试着拿锁,拿不到——说明上一次还在跑——就直接跳过这一次:

import threading

log = get_logger("cron")

class NonOverlappingJob:
    """防重叠:上一次还在跑,这一次直接跳过 —— 绝不让同名任务并发。"""
    def __init__(self, fn):
        self.fn = fn
        self._lock = threading.Lock()

    def run(self):
        # acquire(blocking=False):拿不到锁立刻返回 False,绝不在这里干等
        if not self._lock.acquire(blocking=False):
            log.warning("上一次任务还在执行,本次触发跳过")
            return
        try:
            self.fn()
        finally:
            self._lock.release()                  # 无论成败都释放,别把锁焊死

这里的认知要点是:防重叠的关键,是想清楚"上一次还没跑完,这一次该怎么办"。有两个选项:一是"等"——等上一次跑完再跑这一次;二是"跳过"——干脆放弃这一次。对绝大多数定时任务,正确答案是"跳过",而不是"等"。原因是:定时任务的语义是"周期性地把某件事做到最新状态",而不是"每一次触发都必须被兑现"。一个同步任务,你这一次跳过了没关系——30 分钟后的下一次,会把这期间所有该同步的数据一起带走;真正不能容忍的,是两个任务并发跑、互相抢数据、把状态写乱。如果你选"等",那些被积压的触发会排成一条越来越长的队,任务一旦持续变慢,这条队会无限膨胀,最后雪崩。所以这里 acquire 一定要用 blocking=False:拿不到锁,不是排队等,是立刻放弃、记一条日志、等下一个自然周期。"跳过"听起来像是"丢了一次执行",但对周期性任务来说,这恰恰是最稳的处理。单实例内的重叠挡住了,可多实例下还有另一种重复——这要靠第二道防护。

三、多实例单跑:多个实例只让一个真正执行

第二道防护,补的是破绽 2:多实例各跑一份 cron,任务被重复执行。上面那把 threading.Lock 是进程内的锁——它只能挡住同一个进程里的重叠,挡不住三个独立进程各跑一份。要让多个实例里只有一个真正执行,得用一把跨进程的锁:任务到点时,三个实例都去同一个 Redis 抢一把锁,只有抢到的那个才执行,其余的直接跳过:

import redis, socket

rds = redis.Redis()
INSTANCE = socket.gethostname()

def run_once_across_cluster(job_name, fn, ttl=600):
    """多实例下,用 Redis SET NX 抢一把任务锁,只有抢到的实例才执行。"""
    key = f"cron:lock:{job_name}"
    # NX:只有 key 不存在才设置成功;EX:锁自动过期,防止持锁实例崩了死锁
    got = rds.set(key, INSTANCE, nx=True, ex=ttl)
    if not got:
        return                                    # 没抢到 = 别的实例在跑,本实例跳过
    try:
        fn()
    finally:
        # 只删自己设的锁,避免锁过期后误删了别的实例新拿到的锁
        if rds.get(key) == INSTANCE.encode():
            rds.delete(key)

下面这张图,把多实例下一次定时触发是怎么被处理的画出来:

这里的认知要点是:多实例部署和定时任务,天生有一个矛盾。多实例部署是为了高可用——任何一个实例挂了,别的实例还能顶上。可一旦你把服务部署成多实例,每个实例里那份 cron 也跟着被复制了 N 份,于是每个定时任务到点都会被触发 N 次。你想要的是"N 个实例都活着,但任务只跑一次",这就需要一个"所有实例之外的、共享的裁判"来决定"这一次,由谁来跑"。Redis 的 SET NX 就是这个裁判:它是原子的,N 个实例同时来抢,Redis 保证有且只有一个能设置成功。这里有两个细节不能省:第一,锁必须带过期时间 EX——假如抢到锁的实例在执行中途崩了,它就再也没机会删锁了,要是锁不会过期,这个任务就永远卡死、再没有实例能抢到;有了 EX,锁会自动释放,下个周期别的实例就能接手。第二,删锁前要先确认"这把锁还是不是我的"——如果任务跑得比 ttl 还久,锁会先过期、被别的实例抢走,这时你再无脑删锁,删掉的就是别人的锁了。重复执行挡住了,可任务本身还可能在中途崩掉——这要靠第三道防护。

四、幂等与可恢复:中途崩了不留半拉子

第三道防护,补的是破绽 3:任务跑到一半,服务重启,留下半拉子状态。发版、崩溃、被运维重启——任务在执行到一半时被打断,是一定会发生的事。要让这种打断不留下烂摊子,靠两个性质:一是幂等——任务被重复执行,结果和执行一次一样;二是可恢复——任务能记住自己跑到哪了,下次从断点接着来。先看幂等,关键是每处理完一条就立刻打标记,而不是全部处理完才统一打标记:

def sync_orders(batch_size=500):
    """幂等的同步任务:只挑"还没同步过"的记录,重复跑也不会重复处理。"""
    while True:
        rows = db.query(
            "SELECT id FROM orders WHERE synced = 0 LIMIT %s", batch_size)
        if not rows:
            break
        for row in rows:
            push_to_downstream(row)
            # 处理完一条立刻打标记:即便下一条崩了,这一条也不会被重做
            db.execute("UPDATE orders SET synced = 1 WHERE id = %s", row.id)

幂等让"重跑一遍不出错",但如果任务要处理几百万条数据,崩了之后从头再扫一遍也很浪费。更进一步是可恢复:任务把进度记在外部,崩了之后从断点继续:

def run_with_checkpoint(job_name, fn):
    """带检查点的任务:记下进度,中途崩了下次从断点接着跑,不从头再来。"""
    cursor = rds.get(f"cron:ckpt:{job_name}")
    cursor = int(cursor) if cursor else 0
    # fn 是一个生成器:每处理完一批,就 yield 出这一批最后一条的 id
    for last_id in fn(start_after=cursor):
        rds.set(f"cron:ckpt:{job_name}", last_id)  # 进度落盘,崩溃后可从这里恢复
    rds.delete(f"cron:ckpt:{job_name}")            # 整个任务跑完,清掉检查点

这里的认知要点是:定时任务必须假设"我会在任意一步被打断"。这不是杞人忧天——发版重启是日常,实例被调度漂移是日常,进程 OOM 被杀也时有发生,你的任务一定会在某次执行到一半时被掐断。问题只在于:被掐断的那一刻,留下的是一个"干净的中间状态",还是一个"谁也说不清"的烂摊子。幂等和可恢复,就是为了保证它是前者。幂等的精髓,是把一个大任务拆成许多个"小到不可分"的步骤,每个步骤自带"做没做过"的标记——处理一条、标记一条,这样无论在哪一条上被打断,已标记的不会重做、未标记的下次会被重新挑出来,不重不漏。可恢复则更进一步,它额外记一个"我扫到哪了"的检查点,让恢复不必从头开始。一个判断标准能帮你检查任务设计得对不对:把你的任务在任意一行代码处强行 kill 掉,然后再完整跑一遍——如果最终的数据状态和"一次性顺利跑完"完全一致,它就是对的;如果会多处理、漏处理、或留下脏数据,它就还不够格。任务崩了不留烂摊子了,可它"崩了"这件事本身,还得有人知道——这要靠第四道防护。

五、可观测:任务的成败必须能被看见

第四道防护,补的是破绽 4:任务静默失败,挂了一周才被发现。这是定时任务最阴险的一个坑——因为它无人值守,所以它失败的那一刻,没有任何人在现场。一个接口出错,用户会立刻投诉;可一个定时任务出错,它只是悄悄地不干活了,世界一切如常,直到它该产出的东西迟迟不出现,你才后知后觉。要破这个局,得做两件事。第一件:给每次执行包一层,成功记一笔、失败立刻告警:

import time, traceback

def observed_job(job_name, fn):
    """给任务包一层:成败、耗时都记录,失败立刻告警 —— 任务绝不能静默失败。"""
    start = time.monotonic()
    try:
        fn()
        cost = time.monotonic() - start
        rds.hset(f"cron:stat:{job_name}",
                 mapping={"last_ok": int(time.time()), "cost": round(cost, 1)})
    except Exception:
        # 关键:任务异常必须主动告警,绝不能只是吞进日志、等着没人看
        alert(f"定时任务 {job_name} 执行失败\n{traceback.format_exc()}")
        rds.hset(f"cron:stat:{job_name}", "last_fail", int(time.time()))
        raise

但只靠"失败告警"还不够——万一任务压根没被触发呢(调度器挂了、cron 写错了)?它连"失败"都谈不上,自然也不会告警。所以还要第二件:从监控侧反过来看,一个任务太久没成功跑过,本身就是一种故障:

def check_job_freshness(job_name, max_silence=7200):
    """监控侧:一个任务太久没成功跑过,就是它已经默默挂掉了。"""
    last_ok = rds.hget(f"cron:stat:{job_name}", "last_ok")
    if last_ok is None:
        return alert(f"定时任务 {job_name} 从未成功执行过")
    silence = time.time() - int(last_ok)
    if silence > max_silence:                      # 沉默时间远超它该有的执行间隔
        alert(f"定时任务 {job_name} 已 {int(silence)}s 没成功,疑似已停摆")

这里的认知要点是:定时任务的可观测,要同时从"正面"和"反面"两个方向做,缺一个都会留下盲区。正面是"失败告警"——任务跑了、但抛了异常,你包一层 try 把异常抓住、主动推一条告警出去。这条防线挡住的是"任务跑了但跑挂了"。但它有一个致命盲区:它依赖"任务被触发了"这个前提——如果调度器本身挂了、或者 cron 表达式写错导致任务根本没被调起来,那么 try 块从头到尾就没执行过,自然一条告警也不会发。这种"静默地什么都没发生",比"跑挂了"更难发现。所以必须有反面这条防线:你不盯"它有没有报错",你盯"它上一次成功执行是多久以前"。给每个任务记一个 last_ok 时间戳,再让监控定期检查——一个本该每小时跑的任务,要是两小时都没刷新过 last_ok,那不管它是跑挂了、还是压根没被触发,结论都一样:它停摆了,该告警了。正面防"跑挂",反面防"没跑",两条合起来,任务才真正没有了静默失败的空间。四道防护齐了,最后是几个把定时任务真正用到生产里才会撞见的工程坑。

六、工程坑:错过补偿、任务超时、手动触发、时区

四道防护之外,还有几个工程坑,不处理就会让你的定时任务在边角上出岔子。坑 1:服务停了一段时间,错过的执行要不要补。服务因为发版、故障停了两小时,这期间该触发的任务全错过了。重启后,有些任务需要补一次(比如数据同步),有些不用补(比如每分钟的健康上报)。需要补的,启动时检查一下"距上次成功是不是超了一个周期":

def catch_up_missed(job_name, fn, interval=3600):
    """错过补偿:服务停了一段时间,重启后把错过的执行补上(只补一次)。"""
    last = rds.hget(f"cron:stat:{job_name}", "last_ok")
    last = int(last) if last else 0
    if time.time() - last > interval * 1.5:        # 距上次成功已超过一个半周期
        log.info("检测到错过的执行,补跑一次")
        observed_job(job_name, fn)
    # 注意:只补一次,别把停机两小时错过的 120 次全部补跑,那会瞬间压垮下游

坑 2:任务必须有超时。一个任务调了外部接口、那个接口卡死了,这个任务就会一直挂着、永不结束——它还占着那把 Redis 锁,导致后面每一次触发都被"上一次还在跑"挡掉,任务从此再不执行。每个任务都要包一层超时:

import asyncio

async def run_with_timeout(job_name, coro, timeout=300):
    """任务超时:一个任务跑太久,八成是卡死了,要主动掐断而不是无限等。"""
    try:
        await asyncio.wait_for(coro, timeout=timeout)
    except asyncio.TimeoutError:
        alert(f"定时任务 {job_name} 执行超过 {timeout}s,已强制中断")
        raise

坑 3:任务要能手动触发。任务挂了要补、调试时要验证,你不能干等下一个自然周期。留一个手动触发的入口,但它必须同样走防重叠和单实例那套护栏,不能绕开:

@app.post("/admin/jobs/{job_name}/run")
def trigger_job(job_name: str):
    """手动触发:任务挂了要补、要调试时,得能手动点一下,而不是干等周期。"""
    fn = JOB_REGISTRY.get(job_name)
    if fn is None:
        return {"error": f"未知任务: {job_name}"}, 404
    # 手动触发同样走 防重叠 + 单实例 那套护栏,绝不能绕开
    run_once_across_cluster(job_name, lambda: observed_job(job_name, fn))
    return {"status": "triggered", "job": job_name}

坑 4:时区必须显式指定。你写了个 hour=3 的凌晨任务,可这个"3 点"是哪个时区的 3 点?默认跟服务器本地时区走——服务器一旦迁移、或本地时区配置不同,任务执行时间就悄悄漂走了。调度器初始化时一定要显式写死时区:

from apscheduler.schedulers.background import BackgroundScheduler
from zoneinfo import ZoneInfo

# 定时任务必须显式指定时区:别让"凌晨 3 点"在服务器换时区后悄悄漂走
scheduler = BackgroundScheduler(timezone=ZoneInfo("Asia/Shanghai"))

@scheduler.scheduled_job("cron", hour=3, minute=0)
def daily_report():
    observed_job("daily_report", build_report)
# 显式写死时区,任务的"3 点"就永远是北京时间 3 点,与服务器本地时区无关

坑 5:别在一个进程里堆太多重任务。APScheduler 默认用一个线程池跑所有任务,要是几个重任务同一时刻被触发,会互相抢线程。重任务多的场景,该把任务挪到独立的 worker 进程(比如 Celery beat),让调度和执行分离。坑 6:任务里别用裸 sleep 等条件。任务里写 while not ready: sleep(10) 死等某个条件,会让任务长时间占着锁和线程;要等就设一个最大等待上限,超了就当失败退出。坑 7:任务的日志要带上 job_name 和一次执行的唯一 id。多个任务的日志混在一起,出问题时根本分不清是哪个任务、哪一次执行;每次执行生成一个 run_id,贯穿这次执行的所有日志,复盘时才理得清。

关键概念速查

避坑清单

1. 别写只管"到点触发"的裸定时任务,它对并发、故障、无人值守毫无防备。
2. 给任务加防重叠锁,上一次没跑完,这一次触发直接跳过而不是排队。
3. 多实例部署下用 Redis SET NX 抢锁,只让抢到的那个实例真正执行。
4. 分布式锁必须带过期时间,持锁实例崩溃时锁能自动释放。
5. 删锁前确认锁还是自己的,避免锁过期后误删别的实例新拿的锁。
6. 任务要幂等:处理一条立刻标记一条,中途崩了重跑也不重不漏。
7. 大任务记检查点,崩溃后从断点续跑,不要每次都从头扫。
8. 每次执行包一层:成功记 last_ok,失败立刻主动告警,绝不静默。
9. 从监控侧反查:任务太久没成功跑过,不管什么原因都要告警。
10. 处理好错过补偿、任务超时、手动触发入口和显式时区这些工程坑。

总结

回头看那串"任务重叠抢数据、多实例重复执行、中途崩了留半拉子、静默失败挂一周"的问题,以及我后来在定时任务上接连踩的坑,最该记住的不是某一段调度代码的写法,而是我动手前那个想当然的判断——"定时任务,就是到点调一个函数"。这句话错在它只看见了"触发"这一个瞬间。我以为到点了,把函数叫起来跑一遍,这件事就完了。可我忽略了一件最要紧的事:触发,只是定时任务生命周期的开头;真正的考验,全在"触发之后"。一个定时任务,不是被你在代码里主动调一次、当场看着它返回的普通函数;它是被时钟反复触发、运行在多个实例上、没有任何人盯着、还随时可能被发版打断的——它运行在一个并发的、会故障的、无人值守的环境里。"到点调个函数"这个模型,为"触发"做足了设计,却对"任务要在什么环境里活下去"完全没有设计。它不是写错了,是只做了一半。

所以做好定时任务,真正的工程量不在"把 cron 表达式写对"那几下上。写 cron 表达式,库早就替你做好了。真正的工程量,在于你要为"触发之后"那个恶劣的运行环境,补上一整套防护:任务可能和自己重叠,你就加一把锁,上次没跑完这次就跳过;多个实例会重复跑,你就用一把跨进程的锁,只让一个实例真正执行;任务会在中途被打断,你就让它幂等、记检查点,崩了也不留烂摊子、能从断点续上;它会无人值守地静默失败,你就给每次执行接上告警、再从监控侧反查它是不是太久没成功了。这篇文章的几节,其实就是顺着这套防护展开的:先想清楚"裸定时任务"为什么错,再讲怎么防重叠、多实例怎么单跑、任务怎么幂等可恢复、成败怎么被看见,最后是错过补偿、超时、手动触发、时区这几个把定时任务守扎实的工程细节。

你会发现,定时任务这件事,和现实里"一家店铺每天打烊后那些雷打不动的例行杂务"完全相通。店里每天要做的事——盘点、对账、补货登记——一个不会管店的老板会怎么安排?他嘴上交代一句"每天三点谁去把这些做了",然后就不管了。于是出乱子:上一个人盘点还没盘完,下一个人到点又开始盘,两个人对着同一批货各报各的数;店里前后雇了三个伙计,每个人都以为这是自己的活,同一份账对了三遍;有个伙计盘到一半临时有事走了,剩下半拉账没人接、也没人知道;还有一回,那件杂务整整一周没人做,老板压根不知道,直到货架空了才发觉。而一个会管店的老板怎么做?他不只是"交代一声":他立规矩——这件事正有人在做,就别让第二个人插手(这就是防重叠锁);三个伙计里,每天只挂牌指定一个人去做(这就是多实例单跑);做到哪一步要随手记在本子上,中途换人也能接着往下做(这就是幂等与检查点);做完必须在打卡本上签个字,他每天扫一眼——哪件事的签名迟迟不出现,他立刻就知道那件事出岔子了(这就是正反两面的可观测)。同样是打理一家店的例行杂务,不会管的老板被这些杂务搅得鸡飞狗跳,会管的老板让它们日复一日悄无声息地办妥——差别不在"这些杂务难不难"本身,只在老板有没有为"没人盯着的时候,这些事会怎么出岔子",事先一条条立好规矩。

最后想说,定时任务做没做对,差距永远不会在"本地开发、单进程、还盯着日志看"时暴露——本地就一个进程,任务几秒就跑完,你又开着日志窗口,那四个想当然——不会重叠、不会被多实例重复、不会中途崩、有人看着——恰好全都成立,裸定时任务看上去精准又可靠。它只在真实的、多实例部署、发版频繁、没有人盯着日志的线上才显形。那时候它会用最难堪的方式给你结账:做不好,你会因为任务重叠让两个进程抢着写、把数据搅乱,会因为多实例各跑一份让报表生成三份,会因为中途崩溃留下永远说不清的半拉子状态,还会因为静默失败让一个挂掉的任务无人知晓地躺上一整周;而做对了,你的定时任务无论触发多频繁都不会和自己撞车,无论部署多少实例都只跑一次,无论在哪一步被打断都能干净地恢复,一旦出事监控立刻就会喊你。所以别等"一个挂了一周的定时任务被发现"那一刻找上门,在你写下每一个 @scheduled_job 的时候就该想清楚:这个任务会不会和自己重叠、多实例下会不会重复跑、中途崩了留不留烂摊子、失败了有没有人会知道,这一道道防护,我是不是都替它想过了?这些问题有了答案,你交付的才不只是一个"本地到点能跑"的函数,而是一套多实例、频繁发版、无人值守也照样稳稳运转的可靠定时任务。

—— 别看了 · 2026