Quartz任务调度踩过的坑

Quartz任务调度踩过的坑

Scroll Down

前言

今天不知道在思考什么事的时候,脑子里闪过分布式任务调度,紧随而来的想到Quartz踩过的一次坑,于是就有了这篇文章...

当时是在某一个项目组,在做一个产品——会务系统,这就牵扯得到了业务流程,以下做简要说明:

对会议进行一系列的设置,比如是否要报名审核,排座审核,要配置如何打卡,例如现场扫码打卡、钉钉设备打卡、系统定位打卡等等。在一个就是指定具体的参会人员,还是选择部门,由部门决定具体的参会人员。还有一个就是是否多会场,多会场下比较复杂,每个会场可以设置自己会场的打卡方式等等,之后的流程就是,系统根据会议的配置,决定走什么样的流程,比如要不要审核,要不要由部门去指定参会人员等等,一系列都走完后,会在设置好的会议开始时间、打卡时间、打卡结束时间,由定时任务来去处理。

没有使用工作流,基于事件驱动的,状态-事件-任务

踩坑过程

先说结论,Quartz是分布式集群任务调度的一个框架,当时我们开发是共用一个数据库,所以其他人也开着服务,这就相当于一个集群了,没进断点应该是在我同事的电脑上执行了这个任务。

当时在调试Quartz的定时任务时,我在Job里打断点,有时会进断点,有时不会进断点,时有时无,搞得我有点怀疑人生,由于当时接触Quartz没多久,所以很不解。

解决问题

出现这个问题时,已经临近下班了,到点后该项目组的其他同事下班了,我仍然被这个问题困扰着,我不死心的触发着这个任务——进断点,后来的几次不会出现不进断点的状况了(我是谁,我在哪,我在干嘛)。后来我静心想了一会猜测到,可能是因为分布式任务调度的原因,我们都在共用同一个数据库,正如结论里所提及的那样。

第二天早一来,打断点又出现了时有时无的情况,我单独导了一份数据库在我本地,之后再没出现这个问题,也证实了我的猜测。

一点感悟

问题解决不了说到底还是认知和知识储备少了,我想这个问题,换一个对Quartz了解深一点的人来说,都不是问题,唯有不断学习、不断努力还有不断踩坑,方能不断前行。