欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  IT编程

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

程序员文章站 2023-03-26 12:29:04
实习生张大胖这是个代码写得很烂的电商系统,只要运行一段时间,服务器就会出现Out Of Memory。别人都忙得四脚朝天,于是实习生张大胖被抓了壮丁去研究为什么会出现OOM。刚入行的张大胖技术水平一般,“装模作样”地看代码,研究日志,请教老员工,一个星期过去了,还是一无所获。周一例行的项目会议上, ......

实习生张大胖

这是个代码写得很烂的电商系统,只要运行一段时间,服务器就会出现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