在日常工作之中, 是会有许多固定周期性的任务来存在的, 比如说在每天的早晨需要去拉取业务数据, 又或者说要每周自动生成相应的周报以及定期清理临时文件之类的情况等等, 如果是依靠人工记忆这种形式来进行执行操作的话, 那么在面临工作繁忙的时候便非常容易出现遗忘的现象, 而一旦给脚本搭配定时功能之后, 系统便可以在指定的时间自动运行, 从而也就完全不需要再人为地去记忆相关的操作节点了。轻量级的定时库适合用在简单的场景里, 它能设置脚本每隔一段固定的时长去执行任务, 或者在每天的固定时间去执行任务。不过这样的方案也有它的局限之处,它需要脚本进程一直保持着运行的状态, 如果程序被关闭了或者是发生了崩溃现象, 那么定时任务就会停止下来。倘若业务场景变得更加复杂, 那么选择支持更多触发规则的定时框架会是更加合适的做法。这种框架不仅能够支持固定间隔这样的设置, 还可以支持指定日期触发。此外, 用户还可以对任务失败重试进行配置。采用后台运行模式, 这一模式不会对主程序的执行造成阻塞效应。它比较适合用于那些需要同时执行多项逻辑的脚本之中。但是大部分周期性任务, 优先推荐操作系统自带定时工具。系统自带的任务计划程序, Linux系统使用定时配置, 只需要配置执行时间, 填写脚本启动命令。由操作系统负责调度, 不需要程序常驻后台, 稳定性更强, 不用担心程序意外中断导致任务停止。我经常用到的场景包括定期地清理磁盘里面的临时文件, 以此来避免存储空间被耗尽到没有地方的情况还有就是定时地从外部把业务数据拉取过来, 并且在本地进行存档。像这种类型的任务, 把它交给系统进行定时调度来说, 那是足够的稳定和可靠的。在开发定时任务的时候, 日志记录这个环节是绝对不可能省去的。我们要把脚本运行的详细过程, 还有那些报错的具体信息, 全部都写进日志文件里面去。万一遇到了网络出现波动、权限不够用、或者是依赖的环境发生了改变, 这些情况都可能导致脚本运行失败。这时候, 只要查看日志, 就能快速地定位问题出在了什么地方。千万不要等到发现数据很长时间都没有更新了, 才回去费劲地排查故障。把那些周期性的、固定的工作任务, 交给定时任务去执行, 这样能够减少人为的因为记忆带来的负担, 避免在工作中出现遗漏的事情, 可以合理地把脚本能力和系统的调度能力强行搭配在一起, 实现对日常重复性工作的自动化处理。
