Systemd 定时器 vs. Cron：选择合适的调度器

当您的 Linux 服务器需要按计划运行备份、清理、健康检查或报告时，通常会在 cron 和 systemd 定时器之间进行选择。Cron 仍然简单且可移植。当任务的行为类似于托管服务，并且需要日志、依赖关系或资源控制时，systemd 定时器更合适。

正确的选择取决于您运行的机器、任务的失败行为以及您需要多少操作可见性。

理解 Cron 任务

cron 是类 Unix 操作系统中基于时间的任务调度器。它允许用户安排命令或脚本在固定的时间、日期或间隔定期运行。cron 守护进程 (crond) 在后台运行，并检查 crontab 文件中是否有任何计划任务。

Cron 的工作原理

每个用户都可以拥有自己的 crontab 文件，使用 crontab 命令进行管理。系统范围的任务通常配置在 /etc/crontab 或 /etc/cron.d/ 目录下的文件中。

crontab 条目遵循特定格式：

* * * * * command_to_execute
│ │ │ │ │
│ │ │ │ └───── 星期几 (0 - 6) (星期日=0 或 7)
│ │ │ └─────── 月份 (1 - 12)
│ │ └───────── 日期 (1 - 31)
│ └─────────── 小时 (0 - 23)
└───────────── 分钟 (0 - 59)

示例： 每天凌晨 2:00 运行备份脚本：

0 2 * * * /usr/local/bin/backup.sh

Cron 的优点

无处不在： 几乎在所有类 Unix 系统上都可用。
简单语法： crontab 格式对于基本调度来说相对容易学习。
用户特定任务： 易于为单个用户设置任务。

Cron 的缺点

灵活性有限： 主要基于固定的时间间隔。处理复杂的依赖关系或事件驱动的调度很困难。
无依赖管理： 无法轻松定义任务只能在另一个任务成功完成后运行。
无资源控制： 对计划任务消耗的资源（CPU、内存）几乎没有控制。
日志记录和监控： 通常依赖于邮件输出、syslog 或命令中的显式重定向。
单元文件集成： 未与 systemd 的服务管理功能直接集成。

理解 Systemd 定时器

systemd 定时器是一种更高级、更灵活的任务调度方式，利用了 systemd 单元文件的功能。systemd 定时器不是作为单独的守护进程，而是作为 systemd 初始化系统本身的一部分进行管理。

Systemd 定时器的工作原理

systemd 定时器由两个单元文件组成：

服务单元 (.service)： 定义要执行的任务或命令。
定时器单元 (.timer)： 定义何时应激活相应的服务单元。

这些文件通常放置在 /etc/systemd/system/ 或 ~/.config/systemd/user/ 中。

示例： 安排清理脚本每天凌晨 3:00 运行。

首先，创建服务文件 (cleanup.service)：

# /etc/systemd/system/cleanup.service

[Unit]
Description=每日清理任务

[Service]
Type=oneshot
ExecStart=/usr/local/bin/cleanup.sh

接下来，创建定时器文件 (cleanup.timer)：

# /etc/systemd/system/cleanup.timer

[Unit]
Description=每天运行清理任务

[Timer]
# 启动后 25 分钟运行，然后每天凌晨 3 点运行
OnBootSec=25min
OnCalendar=*-*-* 03:00:00
# 替代方案：上次执行后 24 小时运行
# OnUnitActiveSec=24h

[Install]
WantedBy=timers.target

创建这些文件后，重新加载 systemd，启用定时器以便将来启动时生效，并立即启动它：

sudo systemctl daemon-reload
sudo systemctl enable cleanup.timer
sudo systemctl start cleanup.timer

您可以使用以下命令检查定时器的状态以及下次触发时间：

sudo systemctl status cleanup.timer

关键 `systemd` 定时器指令：

OnCalendar=：指定日历事件时间（类似于 cron 的语法，但更强大）。
- *-*-* 03:00:00：每天凌晨 3 点。
- Mon..Fri *-*-* 09:00:00：工作日早上 9 点。
- hourly：每小时。
- daily：每天一次。
- weekly：每周一次。
- monthly：每月一次。
- yearly：每年一次。
OnBootSec=：在系统启动后指定时间触发。
OnUnitActiveSec=：在相应单元（服务）上次激活后指定时间触发。
OnUnitInactiveSec=：在相应单元（服务）变为非活动状态后指定时间触发。
AccuracySec=：定时器需要多精确。较低的值可能会消耗更多电量。
Persistent=：对于日历定时器，true 告诉 systemd 在定时器处于非活动状态（例如机器关机）时错过计划运行后进行补跑。

Systemd 定时器的优点

与 systemd 集成： 与 systemd 的服务管理、日志记录 (journalctl)、资源控制和依赖管理无缝集成。
灵活性： 支持超出固定间隔的各种调度选项，包括日历事件、启动后的相对时间以及上次激活后的相对时间。
依赖管理： 可以定义对其他 systemd 单元的依赖关系（例如网络可用性）。
资源控制： 可以利用 systemd 的 cgroups 进行资源限制（CPU、内存）。
日志记录： 与 journald 集成，实现全面且集中的日志记录。
错误处理： 可以使用服务单元行为，例如 Restart=、OnFailure= 以及适合任务模式的依赖排序。
状态感知： 可以跟踪任务本应运行的时间，并在系统启动时执行（如果设置了 Persistent=true）。

Systemd 定时器的缺点

学习曲线较陡： 对于初学者来说，systemd 单元文件语法和概念可能比 cron 更复杂。
Systemd 依赖： 需要运行 systemd 的系统（大多数现代 Linux 发行版都满足）。

Systemd 定时器 vs. Cron：主要区别总结

特性	Cron 任务	Systemd 定时器
管理	`crontab` 命令，系统文件	`systemctl` 命令，单元文件
调度	固定的分钟、小时、日、月、星期	日历事件、相对时间、基于启动
集成	独立守护进程	与 `systemd` 集成
日志记录	邮件、脚本重定向	`journald`
依赖关系	无	`systemd` 单元依赖
资源控制	无	`systemd` cgroups
错误处理	基本	服务单元故障处理
状态跟踪	有限	`Persistent=` 选项
复杂性	基本任务更简单	更强大，学习曲线更陡

何时选择哪种调度器

选择 Cron 的情况：

您在使用非常老旧或最小化的系统，该系统不使用 systemd。
您需要安排一个非常简单的、一次性且具有固定重复计划的任务，并且您优先考虑简单性而非高级功能。
您需要为一个已经处理自身日志和错误的命令快速安排计划。

选择 Systemd 定时器的情况：

您在使用现代 Linux 发行版，该系统使用 systemd。
您需要对任务运行时间有更多控制（例如，相对于启动、相对于上次运行、在网络就绪后）。
您需要更好的日志记录、监控和错误处理。
您希望使用 systemd 强大的服务管理功能（包括资源控制和依赖管理）来管理任务执行。
您已经在使用 systemd 管理其他服务，并希望采用一致的方法进行调度。
您的任务依赖于其他系统服务或事件。

实用经验法则

当任务是简短、明确的命令且可移植性很重要时，使用 cron。当任务是服务的一部分、需要 journalctl 日志、应等待网络或受益于资源限制和依赖排序时，使用 systemd 定时器。

夜间备份是一个很好的例子。在小型旧服务器上，0 2 * * * /usr/local/bin/backup.sh 可能就足够了。在基于 systemd 的生产主机上，backup.service 加上 backup.timer 可以提供更清晰的状态、日志、通过 Persistent=true 实现的启动补跑，以及以后添加依赖关系的更清晰路径。