批量任务的并发调度和时间调度

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

一直以来有一个潜在的数据库备份问题，在后续对接任务调度框架的场景下依然感觉没有彻底解决，而如果从我对需求的理解，我们可以把这个任务分解为另外一种思路，换个角度问题就迎刃而解了。

今天看主持人张泉灵评价混子哥的历史解读时，提到了一个观点：有用，有趣，有意义，很受益，也和工作中的问题联系了起来。

顺着这个思路来理解一下我们处理问题的思路和方法，原来在问题的定位上出了问题。有用，这个有用可以是自己认为有用的事情，当然自己认为有用的不一定是真的有用，需要相关的人也能够参与到这个评价中，我们不期望大家都100%达成一致，但是这个事情能够解决大家的大部分痛点就是胜利。打个比方，一条SQL,我们从1分钟优化到了1秒钟，其实对于业务来说，这个场景基本不会用到，哪怕能够用到，这个使用频率足够低，影响完全可以忽略，那么我们做这个事情的价值就会大大降低。

有趣，我觉得是大部分人做工作的一个瓶颈点，怎么样让工作有趣起来，或者说让自己的解决问题方法有趣起来，一种方法一定是很有多见解或者是表现形式有新意的方法，让人看了眼前一亮，另外一类方法就是极大的改善现有的工作现状，比如原来1个小时的繁琐工作现在1秒钟就可以搞定，而且处理方式看起来和原来没有任何差别。

有意义，这是最关键的一点，我们做的事情要变得有意义，一种是让上层看来这个事情值得做，做了之后产出了应有的价值，另外一种是对于团队和个人来说，都有所收获，不论是技术上，还是心智上都有一定的提升。

说了这么多，我们再来看看数据库备份的调度任务现状，我们目前是基于celery来完成的，但是这种方式从目前的实践来看，唯一的改进点是接入了调度平台，也就是达到了有意义的维度，但是还没有解决现有的痛点问题，偶尔还会出点问题，当然不会有趣。

所以这个事情怎么改善，我的思路就是既然备份的核心部分就是一个crontab任务，这个任务会负责备份的检查，备份的细节信息和元数据信息的提取注册等，最关键的部分，这种方式相对于celery的逻辑方式目前来看更为可控，那么我们就暂用crontab的方式，那么问题来了，又回到了原点，痛点问题有哪些，我们列举一下。

1.备份触发状态不够清晰，之前的备份信息是通过手工配置crontab的时间点来分配的，至于合理不合理，只能拍脑袋想

2.如果要调整crontab配置信息，是很痛苦的，基本得逐个连接到服务器来完成，所以越是这样就越不想改动了

3.对于备份任务的时间控制，目前是失控状态，比如我们希望在1:00~3:00完成备份，到底开启多少并行来解决，这个目前是一个黑盒。

所以使用celery来改善调度方式不是关键，对于备份任务的配置和管理才是关键，如果上面的问题解决了，自然是有用的，而且有意义。怎么让这个事情有趣起来呢？目前来看还不能，还是需要继续挖掘痛点，提出更酷的解决方案。

我大体画了下面的设计图。

在已有的crontab配置中，我们可以引入两个调度策略，第一个是任务调度，第二个是时间调度，第一个任务调度是对任务的并发调度，比如有100个任务，我们可以把任务做切分，比如根据备份时间或者数据量来切分为多组，这种切分维度的是和业务场景紧密结合起来的，所以切分的粒度会更加清晰。

另外一个时间调度，时间调度就是我们提出的一个时间范围，比如1:00~3:00，我们会根据这个时间点来计算，得到一个相对资源使用充分的时间调度策略。比如任务1用了20分钟，任务2用了5分钟，那么我们可以使用20+5的时间点来完成上面的两个备份任务，基本保证是串行的状态。

而对于crontab的管理，亮点其实在于crontab的配置信息和系统层面的crontab信息能够联动管理起来，如果修改了模型的数据，就能够让系统层面生效，那么这个事情就会简化很多。

如此一来，这个事情就有趣了。

当然在任务调度和时间调度方面，还有大量的算法和场景可以参考和借鉴，想想可以做的事情和改进的地方依旧很多，而且这种场景相对来说是通用的。对于业务的支持友好性是很不错的。

在这个基础上，再考虑celery任务和crontab的无缝切换，这个事情就变得有趣，而且有意义了。