别人都忙得四脚朝天，于是实习生张大胖被抓了壮丁去研究为什么会出现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应该不错。

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

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

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

这个版本不仅有核心的API像Job, Trigger, Scheduler ，张大胖还专门开发了一个界面，用来展示定时任务的进展，例如什么时间运行，运行了几次，失败了几次......等等。

张大胖把它叫做“大胖定时任务调度系统”。

持久化

他兴奋地拿去让项目经理老梁看， 可是老梁并不感冒，面无表情地说：“你这个小软件有啥用啊。”

张大胖被泼了一盆冷水，依然热情满满地推销：“用了我的这个定时调度系统，任何人都可以轻松地启动，停止任务， 咱们项目中所有的定时任务一目了然。 大家就不用找我来手工调整了。”

老梁开玩笑地说：“奥，那你的实习工作就可以结束了，哈哈。”

正巧CTO Bill经过，他饶有兴趣地看了一会，提了一个问题：“假设你这个大胖调度系统在运行的时候，机器突然间Down掉了，怎么处理？”

张大胖一脸懵逼：“什么怎么处理，重启机器呗。”

Bill 说： “之前的任务还能接着运行吗，比如说一个任务需要运行100次，在机器down掉之前运行了90次，重启后能不能从第91次运行？”

张大胖有点发窘，不好意思地挠挠头：“这一点我还真没考虑到，我现在都是在内存中记录运行的情况，看来得做持久化了。”

Bill 听到持久化这个词，知道张大胖已经Get到了，他说，你把这个持久化实现了，到时候直接向我汇报。

得到了CTO的赏识，张大胖不敢怠慢，赶紧进行新的设计， 他抽象了一个叫做JobStore的接口，表示Job的存储，像什么Job，Trigger， Job运行情况都存储在其中。

下面有两个实现，分别对应内存存储和数据库存储。

虽然SQL是标准的，但是不同的数据库还是有细微的差异， 张大胖觉得得把这些差异给封装起来， 他又提取了一个接口叫做DriverDelegate， 屏蔽了数据库细节，让DbJobStore使用。

他还提供了一个缺省的实现StdJDBCDelegate，如果那些数据库还有独特的实现，那就写个子类就行了。

高可用

“大胖定时任务调度系统 2.0” 开发完成以后，张大胖仔细地想了一遍，似乎没有什么漏洞了，决定正式向CTO Bill去汇报。

Bill 亲切地询问了张大胖加班加点设计和开发的情况，对他这种不计较个人得失，一心一意为公司谋福利的精神表示了高度的赞赏。

张大胖受宠若惊。

Bill话锋一转：“我们的系统最近用户越来越多，老板特别提出了高可用的需求，系统的各个组件也得达到高可用！”

“高可用？ 拿我的定时调度系统来说，就是说可以部署在多个机器上，一个down掉了，其他的还可以运行，对吧？” 张大胖一点就透。

Bill 赞许地点点头：“你想好怎么去实现了吗？”

“很简单啊，把定时调度系统部署到多个机器上，形成几个备份就行了！”

张大胖还在白板上画了这么一个图：

“那同一个时刻，有多少个Scheduler 在运行？”  Bill 终于抛出了重磅炸弹。

张大胖现在明白Bill的疑问了了，三个实例都在运行，那一个Job就有可能运行多次，这肯定是不行的！

他说道：“要不让三个实例A,B,C都去访问同一个数据库吧！”

Bill说：“那三个实例访问同一份数据，肯定会出现冲突，互相覆盖，那就乱套了！”

其实，实例A，实例B，实例C组成一个类似集群的东西，但是同一时刻，一个Job只能在一个实例上运行。

比如Job X 从凌晨1点开始，每隔1小时运行一次，那1:00 的时候Job X可能在实例A上运行， 2:00的时候可能在实例B上运行， 3:00的时候可能在实例C上运行。

也就是说，这三个实例部分地实现了负载均衡。

张大胖说：“这可就难办了。难道让这三个实例A,B,C之间互相通信？”

Bill说道：“那样有点麻烦，就变成一个分布式系统下的通信问题了，我们要不用这个数据库做点文章？ 反正这个数据库已经存了Job的信息，Trigger的信息，我们就多加一个表吧，就叫LOCKS，这个表里边每一行记录都可以当做一个‘锁’来用。”

张大胖表示不太明白。

“很简单，就是数据库的‘行’锁嘛， 比如SELECT * FROM LOCKS where LOCK_NAME='TRIGGER' FOR UPDATE ，这就把那一行记录给锁住了， 别的事务只能等待当前事务commit以后才能访问。”

张大胖还是不太明白。

“比如，服务器A的实例A在一个事务中先执行了上面SQL, 就把那一行给锁住了，当服务器B的实例B也去执行同样的SQL的时候， 只能等待，对吧？ 这不就相当于实例A获得了锁吗？”

“原来如此，以后任何一个调度器实例想要获取Job的运行时间，设置Job的下一次运行时间的时候，都必须先获得这个锁。这样这些分布式的调度器就不会冲突了，只会运行一个特定时间的Job。 我这就去做个详细设计，再来汇报。”

开源

两个月后，“大胖定时任务调度系统 3.0” 开发完毕，在Bill的大力支持和推动下，成功地应用在了公司的项目中。

灵活的设计和扩展性，加上持久化，集群等强大的功能， 系统受到了大家的欢迎。

考虑到很多公司都会有类似的需求，Bill决定把系统开源， 只是“大胖定时任务调度系统”这个名字有点俗，还有点长，Bill把它改名为“Quartz”。

Quartz从此流行开来。

（注：本文试图讲解Quartz的原理，其中的类图并没有和Quartz的真实类完全对应，这一点请大家知晓。）

【本文为51CTO专栏作者“刘欣”的原创稿件，转载请通过作者微信公众号coderising获取授权】

戳这里，看该作者更多好文

【编辑推荐】

CNN也能用于NLP任务，一文简述文本分类任务的7个模型

达观数据：想写出人见人爱的推荐系统，先了解经典矩阵分解技术

OpenStack环境中运行大数据系统的四大存储问题

京东物流仓储系统618大促保障背后的运维秘诀

踩坑实践：如何消除微服务架构中的系统耦合？