我们就直接进入正题:
系统的crontab解决不了的几类问题:
而如果要接入任务调度平台,会解决掉绝大多数的问题,不过很多人都会有类似的几个顾虑:
1.如果调度平台出问题,所有的任务都会失败,影响巨大
2.一旦迁入平台,就是一条“不归路”,除非手工干预调整
3.任务的调度不够优雅,如果任务多,比如有500个任务,需要在1:00~3:00之间执行,如果合理的规划任务的执行情况,目前的很多解决方案还做不到灵活的控制和调度。
4.如果出现临时的维护窗口,系统的crontab和平台的调度任务都是整段垮掉。
所以说,任务调度有很多的痛点,也有解决这个问题的价值,这个问题具有通用性,而且结合不同的场景可以做针对性的实现。
所以在和同事沟通的过程中,我发现,任务调度其实有很多的亮点可以做,我们换个角色来看,如果你有很多的任务,现在饱受困扰,想迁入平台,但是感觉不一定可控(尤其网络不稳定的时候,不是问题的都会成为问题的瓶颈),比较苦恼。
如果我来找你聊一下这个事情,如果我告诉你咱们这么做好不好:
以上几点,是我对目前的调度任务的一个规划,目前已经做了原型,其中的核心点和亮点应该是第五条,需要一个通用高效的算法。
在这个基础之上,我们能做更多的小细节,比如自动接入crontab,你只需要确认和微调即可。比如我们把任务调度的时间和周期做成可视化的方式。
里面的很多思想是和同事聊需求的过程中突然想到的,解决问你题有顾虑,解决了顾虑,那么问题的价值就很明显了。
还有就是我想到了Oracle的任务调度,其实已经很成熟了,我们要做的事情其实还是有些类似的。
比如scheduler,Oracle有很专业的设计和实现。
下面这个就是一个调度的设置,很多时间的设置都可以通过可视化的方式来完成,和业务对接起来就有意义了。