Quartz任务调度踩过的坑

前言

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

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

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

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

踩坑过程

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

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

解决问题

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

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

一点感悟

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