通用crontab接入任务调度的思考

这是学习笔记的第 1781篇文章

在最近使用celery接入了crontab实现了初步的自动化任务编排之后，发现可做的事情一下子多了起来。

对于备份任务的crontab设置而言，其实数量不是很大，在数量上验证调度还是有差距的，而要实现更通用的任务接入，就需要考虑更丰富的场景。

比如一台服务器我需要定制一系列的检查任务，任务简单而繁琐，但是相对来说，机器不会偷懒，有问题就会毫不犹豫的抛出来。从数量上接入来说，比如有100台服务器，我们可以对每一台服务器定制一些任务，比如每隔10分钟检测一些服务心跳，那么一天下来就是6*24*100（台）=14400次，如果接入的其他任务，那么这个数量级就要翻好几倍，这么多的任务和反反复复的检查就是为了保证在问题出现的第一时刻，我们是相对主动的探测到问题症结，能够及时进行修复。所以在数量上有一个基本保证，无论是对于业务更细粒度的检测，还是对于调度系统的性能和功能的补充完善，都是一种互补的方式。

对于通用任务的接入尤为重要，我的初步设想是能够做到任务的平滑接入，统一对接crontab的配置信息,这个维度的粒度可以很细，但是不需要有时间属性，因为对于crontab的定时任务，我们完全可以通过任务的调度算法来对接。

打个比方，我要接入的crontab是这样的。

00 20 * * * /root/scripts/test.sh -h -p >> /root/scripts/test.log 2>&1 &

按照这个维度，我可以抽象成一系列的属性组合，其实对于额外的参数对接，可以使用json的格式来统一解析。

[task_code] [script_path] [script_name] [script_param] [logpath] [logfile] [profile_name]

这样一来，我们定义了业务属性，比如备份任务是mysqlfullbackup，那么我在接入的时候就会更加轻量，也就是说，按照这个维度，我们可以配置很多本书。

第二个维度是profile，也就是模板维度，比如我们有100台服务器，其中70台是一种策略，另外20台是第二种策略，最后10台是第三种策略，我们可以通过profile的方式来管理，统一的对接编码就是[task_code]

这样一来，不同的任务就可以对接不同的需求来使用调度器进行调度编排了。

编排之后会把编排的时间配置生成到这个profile表中。

[task_code] [profile_name] [ip_addr] [db_port] [cron_time]

按照这种思路，整个脚本的接入相对会平滑许多，也会避免很多前期不明确的问题和解决办法。

在后续会逐步对接起来crontab的配置，当然其中还有一个重要环节，就是脚本的定制crontab的逻辑了。