本文适合有 Java 基础知识的人群前端
做者:HelloGitHub-Salierigit
HelloGitHub 推出的《讲解开源项目》系列。通过几番的努力和沟通,终于邀请到分布式任务调度与计算框架:PowerJob 的做者 Salieri,加入 HG 的开源讲解系列,开启了他的 PowerJob 讲解系列🎉。后续每周三将更新一篇,欢迎你们持续关注,但愿你能从本系列学到真本事。github
项目地址:https://github.com/KFCFans/PowerJobweb
你们好我是 PowerJob 的做者 Salieri,关于 PowerJob 故事要从一年前提及了。算法
一年前,我前往阿里巴巴集团,开启了本身的暑期实习。机缘巧合的是,我接到的第一个正式的开发类任务,就与分布式任务调度与计算紧密相关。数据库
当时,集团内部研发出了一款全新的任务调度中间件(SchedulerX 2.0,也就是 README 中提到的本框架的参考对象),须要从老版本的 DTS 迁移到 SchedulerX 2.0。而这个光荣而伟大的任务,天然也被师兄委派到了我身上。也从那时候开始我开始正式接触并使用这种分布式任务调度与计算中间件。安全
迁移完毕后很长一段时间内,算是我和 SchedulerX 的蜜月期,不得不说 SchedulerX 的设计理念极其先进,好比经过控制台或 OpenAPI 动态传递运行时参数能让传统的任务变得很是灵活,无需更改代码便可实现不一样的功能,再好比 MapReduce 处理器的存在使得开发者只须要寥寥数行代码就能实现分布式计算,解决大量数据的处理需求。然而好景不长,在即将迎来双十一之际,发生了两个比较悲伤的故事。服务器
双十一临近,因为须要处理的数据量激增,以前在 SchedulerX 上运行完美的离线任务开始频频失败,整个双十一前夕报警电话的频率甚至能超过微信提醒的频率(好吧有一部分缘由是没人找我 T_T)。通过与相关开发人员的一通排查,初步判定问题的缘由在于咱们的应用内存占用太高,致使 SchedulerX 没有足够的内存去完成必要的任务,进而致使任务失败。这个锅,SchedulerX 显然是不背的,也很合理,不符合最低运行要求嘛,就比如你买一台 Macbook Air 装个 Windows 准备玩 PUBG 结果发现连欢迎界面都看不到,你能说什么呢?人家最低运行要求写的明明白白,达不到配置要求没法运行只能怪你本身,你能作的只有接受。最后实在没办法,只能拆东墙补西墙勉勉强强撑过了双十一。微信
另外一件事是限流。为了监控任务的运行状态,我在另外一个应用单独写了轮询查询 SchedulerX 任务运行状态的逻辑,该功能一直四平八稳地运行着。直到某一天,我完成一个微小改动的发布后,本着安全生产的原则,登上在线日志平台查看应用的运行时日志。不看不知道一看吓一跳,满屏幕的 RuntimeException 甚至让我怀疑我是否是不当心删掉了某个模块,仍是不当心把数据库删了,仍是不当心发布错代码分支了。慌乱事后冷静下来看异常信息,才发现一直以来我调用的 SchedulerX 提供的查看任务运行状态接口报错了,被限流了。理由是双十一保障。嗯,由于须要保障双十一稳定性因此先弄挂一个虽然不在双十一圈内但好歹站在边上的应用。沟通无果,只能一顿魔改代码,本身去实现任务的状态监控。框架
其实这两件事情呢,SchedulerX 团队确实没有什么问题。毕竟服务于整个集团全部业务线,不作一些限制任由你们肆无忌惮使用是不可能的。可是中台模式下,某些个体的需求没法获得知足也是确实存在的现象。对于大部分接入用户来讲,只须要依赖个 Jar 包,写点代码,去控制台一配置,任务就能跑起来,使用体验极好。毕竟,并非全部用户都有咱们这种动辄几百万子任务的变态需求......
双十一事后,实习期满,我也就从阿里离职回家,开启混吃等死模式,天天不是在打游戏就是在想怎么打游戏,对了,还有告诉本身明天必定要好好学习。
浑浑噩噩过了 N 个月后,终于想起还有毕业论文这事。没办法,为了卑微的学位,我只能暂时金盆洗手,投入到论文的撰写之中去。写完论文,疫情差很少结束了,一块儿“送人头”的小伙伴都差很少上班去了,构成我充满打游戏欲望的条件(人数==5)被破坏,我也就完全闲了下来。重拾本身的传统艺能——Reading。
在看了不少本奇奇怪怪的书(甚至包括一本言情小说)之后,终于想起了之前一直想作可是一直被慵懒的本身所搁置的事情:自研一个 SchedulerX,万一哪天 SchedulerX 知足不了需求,至少还能本身就本身抢救一下~因而,OhMyScheduler(没错,一开始叫 OhMyScheduler),后面更名为 PowerJob 诞生了~
实在是没事儿干了,也是时候扛起是“新一代分布式任务调度与计算框架”的大旗了(固然要走的路还很长),废话很少说接下来开始正文。
定时任务相信你们都接触过,好比经典的 Linux crontab。定时调度、定时执行已经渐渐成为了各个系统广泛须要依赖的中间系统。在 Java 领域,也出现了许多优秀的任务调度框架。
当前市面上流行的做业调度框架有老牌的 Quartz、基于 Quartz 的 elastic-job 和原先基于 Quartz 后面移除依赖的 xxl-job,这里分别谈一些这些框架现存的缺点。
Quartz 能够视为第一代任务调度框架,基本上是现有全部分布式调度框架的“祖宗”。因为历史缘由,它不提供Web界面,只能经过API完成任务的配置,使用起来不够方便和灵活,同时它仅支持任务的单机执行,没法有效利用整个集群的计算能力。 同时,Quartz 须要的调度和执行耦合在同一个应用中,没有平台化服务的能力。
xxl-job 能够视为第二代任务调度框架,在必定程度上解决了 Quartz 的不足,在过去几年中是个很是优秀的调度框架,不过放到今天来看,仍是存在着一些不足的,具体以下:
正所谓长江后浪推前浪,在现在这个数据量日益增加、业务愈来愈复杂的年代,急需一款更为强大的任务调度框架来解决上诉问题,而 PowerJob 所以应运而生。
PowerJob 能够被认为是第三代任务调度框架,在任务调度的基础上,还额外提供了分布式计算和工做流功能,其主要特性以下:
综上所述,PowerJob 是全新一代分布式调度与计算框架,能让您轻松完成任务的调度与繁杂任务的分布式计算。适用于各个有任务调度需求的企业,统一部署 Server 作为整个公司的公共调度平台,成为分布式调度的中间件。
后面会逐步从上手使用讲到核心技术剖析,但愿你们能够从中有所收获,同时欢迎小伙伴们能够贡献代码哦!大纲太长了(10+篇)简单罗列一部分:
本章主要阐述了 PowerJob 诞生的故事,同时简单介绍了 PowerJob 这个框架的功能和适用场景,本系列的大纲。下一章节,我将会介绍 PowerJob 的快速入门,帮助你们快速熟悉并使用这款强大的分布式任务调度与计算框架。
关注公众号加入交流群(做者在 Java 群)