任务调度的思考和总结
我们就直接进入正题：
系统的crontab解决不了的几类问题：
任务的时间精度不够
任务管理太臃肿
没法设置任务的截止时间
没有调度功能
没法监控任务的执行情况
如果系统出问题，任务可能没法执行
任务间的依赖没法直接控制
而如果要接入任务调度平台，会解决掉绝大多数的问题，不过很多人都会有类似的几个顾虑：
1.如果调度平台出问题，所有的任务都会失败，影响巨大
2.一旦迁入平台，就是一条“不归路”，除非手工干预调整
3.任务的调度不够优雅，如果任务多，比如有500个任务，需要在1:00~3:00之间执行，如果合理的规划任务的执行情况，目前的很多解决方案还做不到灵活的控制和调度。
4.如果出现临时的维护窗口，系统的crontab和平台的调度任务都是整段垮掉。
所以说，任务调度有很多的痛点，也有解决这个问题的价值，这个问题具有通用性，而且结合不同的场景可以做针对性的实现。
所以在和同事沟通的过程中，我发现，任务调度其实有很多的亮点可以做，我们换个角色来看，如果你有很多的任务，现在饱受困扰，想迁入平台，但是感觉不一定可控（尤其网络不稳定的时候，不是问题的都会成为问题的瓶颈），比较苦恼。
如果我来找你聊一下这个事情，如果我告诉你咱们这么做好不好：
如果系统已有crontab，依然可以继续使用，接入平台只是对已有的crontab，把元数据信息保存下来，然后对任务的执行情况做管理，比如查看执行的任务日志，任务的执行状态（加入标示位），我想这对很多人来说，应该是可以接受的，缺点是这么做，意义不是很大。
我们再加一层砝码，如果在平台里支持任务调度，比如使用celery,我们可以无缝的把crontab切换到celery中，那么这个事情的意义就很明显了，我们可以选几个系统crontab做试点，然后逐步开放
如果因为网络不稳定等原因，你需要在系统层继续使用crontab，如果可以由celery的任务直接切换到crontab,那么这个事情就可以说可控了。
如果我们在平台中修改系统调度任务的时间，系统中的crontab会联动变化，那么crontab的维护就会方便许多。
如果有500个任务要执行，比如说备份任务，有的数据库有50G,有的只有500M,如何合理的规划备份任务，目前很容易看到的一种瓶颈就是瞬间有500个备份任务同时开始，不够优雅，如果我们可以限定并行度，比如同时执行备份的任务有5个，就会对500台服务器做一个统一的调度，分成5组，每组的任务会根据数据量和时间来评估，如果后续需要调整备份任务的并行度，可以扩展也可以收缩，那么这个事情幸福度就大大提高了。
以上几点，是我对目前的调度任务的一个规划，目前已经做了原型，其中的核心点和亮点应该是第五条，需要一个通用高效的算法。
在这个基础之上，我们能做更多的小细节，比如自动接入crontab,你只需要确认和微调即可。比如我们把任务调度的时间和周期做成可视化的方式。
里面的很多思想是和同事聊需求的过程中突然想到的，解决问你题有顾虑，解决了顾虑，那么问题的价值就很明显了。
还有就是我想到了Oracle的任务调度，其实已经很成熟了，我们要做的事情其实还是有些类似的。
比如scheduler,Oracle有很专业的设计和实现。
下面这个就是一个调度的设置，很多时间的设置都可以通过可视化的方式来完成，和业务对接起来就有意义了。
相关的链接，之前写过的文章，供参考。