分布式周期任务调度：把 cron 做成一个不会重跑的服务

一句话

cron 在单机上是个几十年没人操心的小工具；搬进数据中心，它立刻变成一个有状态、必须靠分布式共识才能做对的服务。而本章最硬的一句是：它天然拿不到「恰好一次」——你只能在「可能漏跑」与「可能重跑」之间先选一边，再用幂等与报警去兜住另一边。

Glossary · 术语表

坐标

本章作者 Štěpán Davidovič，属《SRE》Part III「实践」中围绕有状态系统可靠性的那一串。上承 Ch23《管理关键状态》——那章讲共识本身，本章是它最小、最具体的一次落地：整个系统要靠共识维护的状态，少到只有「每个任务上一次什么时候启动过」；下启 Ch25《数据处理管线》——那章讲的正是被 cron 触发的那些周期作业。现实对应：Kubernetes CronJob、Airflow / Argo 的定时触发、云上的托管调度器，以及任何一句「每天凌晨跑一次」的对账、清理与报表任务。

这章要解决什么

单机 cron 的可靠性模型只有一句话：等于那一台机器的可靠性。它悄悄藏了两个假设——进程一直活着、本地状态不会丢。数据中心里这两条都不成立：机器会被抢占、会被重装、会整机架断电；而 crontab 本身也在那台机器上，机器没了，连「该跑什么」的清单都一起没了。

但真正致命的不是概率，是失败模式：一次成功的请求变成 500，你在监控上能看见；一次没有发生的定时任务不产生任何信号。它不报错、不写日志、不进指标——它只是没发生。这类事故的典型发现路径是「周一早上有人问：上周五的报表呢？」

于是规模一上来就必须做两件事：①把「按点开工」这件事和单台机器解绑；②把「跑没跑」记在一个死不了的地方。而只要多台机器都可能执行、状态又必须跨机器可见，你就一头撞进这章真正的问题：重复启动与漏掉启动，二者必居其一。

核心内容，讲透

谁开工：用共识选出唯一的发起者

做法是把 cron 做成一个多副本服务：副本之间用 Paxos 选出 leader，只有 leader 会真的发起任务，其余副本不发起，但必须跟住同一份状态——因为它们随时要接班。

一个常见的偷懒替代是「每台都跑，靠抢一把分布式锁去重」。这在本章的语境里是不够的：抢到锁不等于下游认这把锁。持有者可能在拿到锁之后、真正发起之前卡住几十秒（长 GC、网络拥塞），锁早已过期被别人拿走，而它醒来后照样发起——两个「唯一发起者」就这么并存了。要让锁真正管用，必须配 fencing：每次授权带一个递增序号，下游（这里是数据中心调度器）校验并拒收旧序号。这就是 Ch23 的老结论：你以为在用锁，其实在实现共识。

记什么：两个同步点，和那个说不清的窗口

这是全章的技术核心。leader 每到一个调度点，做的不是一个动作而是三个：①先把「我即将启动 X、本次调度时间 T」写进共识日志；②再向数据中心调度器发起；③发起返回后，把「已启动」写回日志。

为什么要多写第一笔？因为 leader 可以在任何一个瞬间消失。分三种情况看：崩在 ① 之前——新 leader 什么都没看见，确定没启动，按点补发即可；崩在 ③ 之后——确定已启动，跳过；崩在 ① 与 ③ 之间——不确定：请求可能压根没发出去，也可能已经被调度器收下、只是回执没写成。这个窗口通常只有几十到几百毫秒，但它不会消失。

消解办法是把「问一句」变得可行：让每次启动的实例名由（任务名，调度时间）唯一确定，比如 job-X@2026-09-25T02:00。新 leader 接班后拿这个名字去问调度器「有没有这个实例」——问到了，记为已启动；确认没有，补发一次。只有当调度器自己也答不上来（它正在重启、或请求超时）时，才落到那条兜底策略上。

这里要看透的是：cron 和调度器是两个系统，两个系统之间没有原子提交。所有「恰好一次」的幻觉，都死在这条缝里。本章的诚实之处，就是不假装这条缝能被填上，而是明码标价地选一边：Google 的这套 cron 选择宁可漏跑，不可重跑——漏跑是可观测、可补救的；重复的对外副作用往往不可撤回。

状态存哪：自带共识日志，还是外挂一个存储

需要持久化的状态小得惊人：每个任务只要一条「上一次启动的调度时间」以及那条未决的启动意图。这就让「自带共识日志」变得非常划算——状态可以整份放内存、定期快照，一次启动只对应一次共识写，代价是1 个网络往返 + 1 次 fsync（同机房往返亚毫秒、fsync 几毫秒，合计个位数毫秒），相对于一个按分钟计的调度周期完全可以忽略。

反过来把状态外挂到 etcd / ZooKeeper / 数据库也能做，省掉自建复制的工程量，但把 cron 的可用性钉在另一个系统上——更糟的是，那个系统挂掉时，你连「这次到底跑没跑」都答不出来。

边界：cron 只管发起，不管跑完

本章划了一条很清楚的界：分布式 cron 的职责止于把任务交给数据中心调度器，之后任务跑多久、跑成什么样，是调度器和任务自己的事。这不是偷懒，是防止职责蔓延——一旦 cron 开始追踪长任务的生命周期、表达「A 跑完才跑 B」，它就变成了一个工作流引擎，而那是另一个更难的问题。

落到实践就是一条很实用的经验：cron 触发的东西越短越好，最好只是「发起」这一下；真正的多步长流程交给专门的工作流引擎。

时间本身也是敌人：惊群与时区

人写 crontab 有强烈的整点偏好。假设一个集群上有 2000 个周期任务、其中四成写着 0 0 * * *，那就是 800 个任务在同一秒同时向调度器要资源——调度器排队、启动延迟飙升，而接下来的 59 分钟机器闲着。所以这套 cron 在 crontab 语法上做了扩展：允许你表达「在这个范围里你随便挑一个时间」，由系统把启动点摊到整段窗口里。绝大多数「每天跑一次」的任务其实完全不在乎是 0:00 还是 0:37。

时区是第二个坑：夏令时切换那天，本地时间可能少一个小时或重复一个小时，于是「每天 2:30」这一条要么不存在、要么触发两次。工程上的通行做法是内部一律按 UTC 记账，只在展示层换算。

关键权衡与选型

表 1 · 漏跑与重跑，按任务性质选边（这一刀必须自己砍，且要公开声明）

表 2 · 「跑没跑」这份状态存在哪

表 3 · 你到底该用哪一档

为什么重要 / 落到真实系统

这一章的价值不在于「教你造一个 cron」，而在于它把一个人人都以为已经解决了的老问题重新撕开，并且给出了一个可以照抄的诚实答案：承认拿不到恰好一次，公开声明你选了哪一边。今天所有主流调度器给出的，都是同一个结论的不同说法。

面试里怎么用：被问到「设计一个分布式定时任务系统」，评分点几乎就是本章的目录——谁发起（选主）、跑没跑记在哪（状态与共识）、崩溃窗口怎么消解（两个同步点 + 可推算的实例名）、语义选哪一边并公开声明（漏 vs 重）、惊群怎么摊平、以及边界在哪（不追踪长任务）。只要你主动说出「恰好一次做不到」，就已经赢了一半。

易错点与争议

• 以为 cron 是无状态的。单机 cron 只是把状态藏在本地目录和一个「假定永不重启」的进程里。一旦多副本，这份状态必须被显式建模——这一章本质上就是在讲这件事。
• 以为幂等是免费的。幂等键必须一路穿到真正产生副作用的那一层（支付网关、短信通道）。只在调度层去重，等于在自家门口拦截，而副作用发生在别人家里。
• 把锁当保证。拿到锁到真正执行之间可能被 GC 或网络卡住，锁早已过期而你仍在写。没有 fencing 的锁只是「大概率不会撞车」。
• 拿 cron 当工作流引擎。只要你开始想表达「A 成功了才跑 B」「失败了退避重试三次」，你要的就不是 cron。
• 只监控失败，不监控「没发生」。这是 cron 最典型的事故形态：什么都没发生。关键任务必须配「窗口内未观察到本次启动就报警」，这条报警比任务本身的失败报警更重要。
• 时代局限与后续发展。本章 2016 年的方案有个前提：调度器可以被查询——崩溃窗口靠「去问一句」消解。此后主流答案往持久化执行偏移（Temporal / Cadence 那一路）：不再追求启动的恰好一次，而是保证整个流程的状态可重放、把幂等下沉到每一步。这不是推翻本章，而是把它的结论抬高了一层——缝还在那儿，只是被搬到了更容易兜住的位置。

要点收尾