Linux systemd.timer FixedRandomDelay 怎样保持随机延迟的稳定性

如果你希望一批 Linux 主机把定时任务错开，又不希望同一台机器上的任务每次启动都重新“抽签”，可以把 RandomizedDelaySec=30min 和 FixedRandomDelay=yes 放在同一个 [Timer] 段里。前者给出随机延迟的上限，后者让这个 timer 在相同身份条件下反复使用稳定偏移，管理器重启后也不会因为重新加载而改变。

官方手册地址：https://www.freedesktop.org/software/systemd/man/latest/systemd.timer.html

核心判断是：FixedRandomDelay 解决“同一个 timer 每次不要乱跳”的问题，AccuracySec 解决“系统是否允许把多个唤醒合并”的问题；如果你还要保证机器重启后仍沿着原来的日历周期走，则要进一步考虑 RandomizedOffsetSec，不能只依赖固定随机延迟。

先把“稳定错峰”拆成两个单元

systemd 的 timer 和 service 是一对契约：.timer 决定什么时候尝试激活，匹配的 .service 决定真正执行什么。默认情况下，backup.timer 会激活同名的 backup.service；也可以用 Unit= 指向另一个服务。

这个契约有一个容易被忽略的错误模型：当 timer 到点时，如果目标服务还处于 active 状态，systemd 不会再启动一个新实例，而是保持当前实例继续运行。因此，稳定的随机偏移并不等于允许任务并发堆积。先把执行单元写成一次性服务，再为 timer 设定周期，排查结果会更清晰。

# 中文说明：服务只负责执行一次任务，避免用常驻进程掩盖 timer 的重复触发语义
[Unit]
Description=执行一次归档任务

[Service]
Type=oneshot
# 中文说明：这里替换为实际的、可审计的任务入口
ExecStart=/usr/local/bin/archive-report

让同一个 timer 的错峰偏移稳定下来

RandomizedDelaySec=30min 表示在下一次确定的触发时间上增加一个 0 到 30 分钟之间的随机延迟。如果不设置 FixedRandomDelay，每次迭代都可能得到不同延迟；设置为 yes 后，systemd 会依据机器 ID、管理器用户 ID 和 timer 单元名确定性地选择偏移，同一 timer 的多次触发会沿用这个偏移。

可以把它理解为“在一个上限范围内选定固定位置”，而不是“每次都重新产生一个随机数”。因此，同一台机器上重启 systemd manager 不会自动改变该 timer 的偏移；不同的 timer 单元名通常也会得到不同的偏移，有助于把相似任务分散开。

稳定性有边界：它依赖机器身份、管理器用户和单元名这些输入。改名、切换用户管理器、改变机器身份或调整随机延迟上限，都不应被当作“原偏移永远不变”的承诺。部署时要把 unit 文件名和 RandomizedDelaySec 视为配置接口的一部分。

把随机范围和精度窗口分开配置

AccuracySec 默认是 1 分钟，它允许 systemd 在指定触发时间之后的窗口内安排实际唤醒，并在本机 timer 之间合并唤醒以节省资源。它和 RandomizedDelaySec 的方向相反：前者倾向于合并，后者用于把事件拉开。

当两者同时存在时，先加随机延迟，再根据 AccuracySec 做可能的合并。如果目标是尽量把任务铺开，而不是优先省电，可以将 AccuracySec 调到很小，例如 1us；如果任务只要求大致在窗口内完成，则保留更大的值通常更节省唤醒成本。

一个适合日常批处理的 timer 可以这样写：

# 中文说明：每日触发一次，在固定随机偏移上错开同类任务
[Unit]
Description=每日归档任务定时器

[Timer]
# 中文说明：日历表达式给出基准触发点
OnCalendar=*-*-* 02:00:00
# 中文说明：最多额外延迟 30 分钟，用于把同类任务分散
RandomizedDelaySec=30min
# 中文说明：让本 timer 的随机偏移在多次触发和 manager 重启后保持稳定
FixedRandomDelay=yes
# 中文说明：降低唤醒合并造成的额外时间弹性；不是随机延迟上限
AccuracySec=1us
# 中文说明：关机错过日历点后，在重新激活 timer 时补做一次
Persistent=true
# 中文说明：显式指定目标服务，避免改名后触发了错误的同名单元
Unit=archive-report.service

[Install]
# 中文说明：允许 systemctl enable 把 timer 接入系统定时器目标
WantedBy=timers.target

不要用 FixedRandomDelay 代替错过执行和周期保持

Persistent=true 只对 OnCalendar= 生效。它保存上次触发时间；如果 timer 停用期间本来应该触发过，重新激活时会尝试补做一次，而且这次补做仍会受到 RandomizedDelaySec 的影响。它解决的是“停机期间漏掉了日历事件”，不是“让偏移稳定”。

如果服务执行时间可能超过周期，还要关注服务本身是否仍 active。systemd 不会因为下一次 timer 到点就强行复制一个实例；你需要在 service 设计里处理超时、幂等和失败重试，而不是继续扩大随机范围。

还有一个跨重启的区别：FixedRandomDelay 能稳定每次的延迟值，但随机延迟仍是加在下一次确定的触发时间或 manager 启动时间（取较晚者）之后。对于每周备份这类必须保持原有日历节奏的场景，官方文档建议考虑版本 258 引入的 RandomizedOffsetSec，因为它专门用于维持 OnCalendar 事件在重启前后的周期位置。

版本和参数取舍要先写进部署约定

FixedRandomDelay 在 systemd 247 加入，RandomizedOffsetSec 在 systemd 258 加入。目标发行版如果低于相应版本，不能只把 unit 文件复制过去然后假设行为一致。应先确认目标机器的 systemd 版本，再决定是退回普通 RandomizedDelaySec，还是把稳定偏移交给外部调度策略。

我会按下面的决策表选择：

用 systemctl 完成一次可回查的部署

保存两个 unit 文件后，先让 systemd 重新读取配置，再启用并启动 timer。下面的命令只负责部署和查看，不会把状态查询误当成业务执行结果。

# 中文说明：重新读取新增或修改后的 unit 文件
sudo systemctl daemon-reload
# 中文说明：设置为开机自动启用，并立即启动 timer
sudo systemctl enable --now archive-report.timer
# 中文说明：查看下一次触发时间、上次触发时间和目标单元
systemctl list-timers archive-report.timer
# 中文说明：查看 timer 的解析后配置，重点确认两个随机参数
systemctl cat archive-report.timer
# 中文说明：查看本次 timer 关联服务的最近日志
journalctl -u archive-report.service -n 50 --no-pager

排查时优先确认四件事：RandomizedDelaySec 是否非零、FixedRandomDelay=yes 是否确实落在 [Timer] 段、目标服务是否因仍在运行而没有重复启动、以及 AccuracySec 是否给了你无法接受的时间窗口。若问题只出现在重启后日历位置改变，则应回到 RandomizedOffsetSec 的兼容性，而不是反复调大 FixedRandomDelay。

常见追问

FixedRandomDelay 是不是固定在某一个分钟数？ 不是。它是在 RandomizedDelaySec 给出的范围内确定一个偏移；基准触发时间和精度合并仍会影响实际唤醒。

把 AccuracySec 设成 1us 就绝对准时吗？ 不是。它只是把 systemd 的合并窗口压到很小，仍可能受到系统 timer slack 等因素影响。

为什么改了 timer 名称后延迟变了？ timer 单元名参与了确定性偏移的计算。改名等同于改变了配置输入，不能要求继续复用旧偏移。

FixedRandomDelay 能保证服务不会重复运行吗？ 不能。重复运行由 service 是否仍 active、任务是否幂等以及周期设置共同决定；固定偏移只负责随机延迟的稳定性。