系统架构设计之-任务调度系统的设计

实习生张大胖

这是个代码写得很烂的电商系统，只要运行一段时间，服务器就会出现out of memory。

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

本文转载自：http://www.dalbll.com/group/topic/architectureddesign/5246