一次性作业与常驻作业
一次性作业有明确终点，例如批处理、备份、迁移脚本；常驻作业没有终点，例如服务进程、代理、采集器。两者的设计取向相反：一次性作业关心退出码语义、幂等、重跑与结果归档；常驻作业关心启动失败重试、崩溃自愈、日志轮转与平滑重启。判断标准很简单：进程是否需要长期占用资源并持续对外提供服务。介于两者之间的是「被调度器周期性拉起的一次性作业」，它既需要一次性作业的收敛性，也需要常驻作业的可靠性保障。
基本信息
| 一次性作业 | 有明确退出码，产出物可归档，要求可重复执行 |
|---|---|
| 常驻作业 | 交由系统管理（systemd、Windows 服务、容器编排）保证拉起 |
| 中间形态 | 由 cron、systemd timer、Kubernetes CronJob 周期拉起的一次性任务 |
| 关键差异 | 退出码语义、日志轮转、状态保持、重启策略 |
典型使用场景
- 备份、数据迁移、批量处理按一次性作业设计
- 服务、代理、采集器按常驻作业设计并交给系统管理
- 周期巡检写成一次性脚本，由调度器按周期拉起
- 需要进度与断点的长任务，按一次性作业设计并持久化进度
- 常驻作业需要平滑重启，避免中断在途请求
两种形态的落地方式
两种形态的落地方式
/tmp/batch.sh; echo "exit=$?" # 一次性作业：用退出码表达结果
systemctl enable --now app.service # 常驻作业：交给 systemd 管理重启与自启
systemctl status app.service # 查看是否处于 failed 状态
journalctl -u app.service -n 50 # 常驻作业日志统一走 journal
nohup /opt/app/bin/app & # 反例：临时手段，崩溃后无人拉起两种形态对比
| 维度 | 一次性作业 | 常驻作业 |
|---|---|---|
| 生命周期 | 从启动到结束 | 持续运行直到被停止 |
| 结果表达 | 退出码与产出物 | 健康状态与运行指标 |
| 失败处理 | 重跑或补偿 | 自动重启并告警 |
| 日志 | 一次性收集归档 | 需要轮转，避免写满磁盘 |
| 幂等要求 | 重复执行结果一致 | 重复启动不冲突、端口不占用 |
把长期运行的服务用后台符号与 nohup 拉起，会失去崩溃自愈、开机自启和统一日志，问题往往在无人值守的时段才暴露。除临时验证外应交给服务管理器。
常驻作业重启时若有在途请求或写操作，可能产生半写状态。平滑重启（先停止接收新请求、等待在途完成再退出）与幂等的启动流程是必要设计。