一个著名的任务调度系统是怎么设计的？

别人都忙得四脚朝天，于是实习生张大胖被抓了壮丁去研究为什么会出现OOM。

刚入行的张大胖技术水平一般，“装模作样”地看代码，研究日志，请教老员工，一个星期过去了，还是一无所获。

周一例行的项目会议上， 大家似乎要看张大胖的笑话了，没想到他却提了一个歪招：“这个OOM问题非常复杂，一时半会儿也解决不了，要不我们定时重启服务器怎么样？”

一脸严肃的项目经理老梁点点头：“以目前的情况看，也只能如此了。但是不能让服务中断，这样吧，公司有两台服务器，一台在凌晨1点重启， 另外一台在凌晨2点重启。”

得到了领导的首肯，张大胖赶紧行动，周末他其实已经做了准备，研究了Linux上的crontab，它的格式是这样样子：

每天凌晨一点重启系统，可以这么写：

0 1 * * *  restart.sh

（码农翻身注：这里只是个简单的例子， 实际上crontab及其灵活）

这个OOM的问题被张大胖灵机一动给解决了，或者说，被临时隐藏了。

crontab达人的烦恼

大家知道张大胖擅长crontab， 都把一些定时的任务扔给他去做： 什么定时统计报表，定时同步数据，定时删除表中的无效订单...... 等等。

张大胖整天面对的就是crontab和脚本，都快要吐了。

不仅如此，同事们还经常提出一些“变态”的需求：

“大胖，那个定时任务运行得怎么样了？”

“大胖，我想把那个定时任务给停掉。”

“大胖，那个定时任务今晚别运行啊！”

“......”

张大胖真是烦死了，他心想，要是提供个界面让大家使用就好了， 可是crontab似乎并不支持。

要不自己开发一个？

有一次张大胖偶然发现了JDK中的Timer类，似乎也是做这些定时任务的， 不由地眼前一亮，但是仔细研究以后就发现，JDK的Timer还是太简单了，做点简单的定时任务还行， 对于复杂的情况，尤其是复杂的时间策略，还是力不从心。

另起炉灶

看来自己需要从头设计了，张大胖想到了公众号码农翻身的一篇文章《一个著名的日志系统是怎么设计出来的？》， 小张用“正交”的原则设计出了Logger, Appender, Formatter这些类。

我也可以使用同样的原则啊，小张能行，我凭什么不行？

说干就干，先想想需求，非常简单，不就是定时地执行任务嘛！

“任务”应该是正交中的一个“维度”，我可以抽象出一个接口叫做Task ， 嗯，还是叫做Job吧。

对使用者来说，他需要提供一个实现类出来，在实现类中描述要做什么事情，比如：生成报表，复制数据......

“定时”该怎么处理？ 定时，定时触发，干脆叫做Trigger吧。

这个Trigger 可以指定什么时间开始，时间间隔，运行多少次， 能覆盖大部分需求了。

可是张大胖转念一想，如果有人要求类似日历的重复间隔该怎么处理？ 比如每月的第一天运行，或者每周的最后一天运行，该怎么办？  crontab特别适合描述这种情况，对，可以搞一个类似于crontab的Trigger。

看来Trigger最好也是个接口，我来提供几个默认的实现，比如SimpleTrigger，CronTrigger，用户还可以扩展，这样就灵活了。

Job和Trigger也是正交的关系， 两者可以互不影响，可以独立扩展，真是不错， 张大胖不仅得意起来，这设计也很简单嘛！

但是怎么把这两个家伙结合起来？

必须得有个“大管家”才行，这个大管家应该可以接受Job， 然后按照各种Trigger去运行，嗯，叫做调度器Scheduler应该不错。

张大胖画了个草图，来展示三者之间的关系：

设计得差不多了，可以进入开发阶段了， 因为是自己要写一个类似于框架的东西，让别人去使用，张大胖开发起来非常有激情，即使是利用晚上和周末的时间来写代码，也是像打了鸡血一样，根本不觉得累。

一个月过去了，第一版新鲜出炉。