最近在做一个调度平台改造的项目,quartz在测试环境跑的是单机环境,生产上两台服务器做集群。
![87148fd5d93ea8295dfe4e9608e228fd.png](https://i-blog.csdnimg.cn/blog_migrate/5249c2df6936e80c2d3537a460c9c511.jpeg)
测试环境是ok的,生产上线后报错,一个类java.lang.classNotFoundException(注明:这个类被别人修改了名称,现在使用的新名字)
第一次:失败
从代码上排除了对旧的job类的引用(配置文件和类都排除了)
推测是服务器缓存了该类。
尝试:
清除缓存,重启服务器,仍然报上述错误。
第二次:失败
将生产上的配置拉到测试环境上,反复测试,重启服务器时会自动清除缓存。
推测是quartz的那个类为全局变量,在生产上会做同步。
尝试:
在测试环境上再次搭建一台调度服务器,从生产上将配置和执行全部拉到测试环境上,执行ok
反复调试,仍然没有发现同步的迹象。
没有重现生产上的异常,不敢上线了。
第三次:失败
那么这个旧的job类究竟从哪里调用的?找不到头绪!会不会保存到数据库吧?
当时觉得这个想法很搞笑,从设计的角度上来说,quartz应该不允许将别的类引入到自己的体系吧。
但也没路可走,就查看数据库,看看有没有保存在数据库中。你猜对了,它对原原本本的躺在数据库的表中:
CREATE TABLE QRTZ_JOB_DETAILS(JOB_NAME VARCHAR(200) NOT NULL,JOB_GROUP VARCHAR(200) NOT NULL,DESCRIPTION VARCHAR(250) NULL,JOB_CLASS_NAME VARCHAR(250) NOT NULL,IS_DURABLE VARCHAR(1) NOT NULL,IS_VOLATILE VARCHAR(1) NOT NULL,IS_STATEFUL VARCHAR(1) NOT NULL,REQUESTS_RECOVERY VARCHAR(1) NOT NULL,JOB_DATA BLOB NULL,PRIMARY KEY (JOB_NAME,JOB_GROUP))TYPE=InnoDB;
好吧! 查看该字段,发现确实是旧的类,被不是新的类。
那么为什么在测试环境中发现呢?
进入测试库,也没有发现旧的类,好吧。
第四次:成功
再次部署到生产上,还是报错:类找不到。
确认问题处在数据库中,我对quartz的表一张张的查找,仍然找不到这个记录,那就从写入库开始入手,查了quartz的代码,发现job_detail表中有个字段job_data,它的类型是blob,会不会存在这里呢?
确实,可以打开此blob查看,数据时放到这里了。
这个小心一些,再次检查是否有别的blob字段存放旧的job类,发现在triggers表中也有个字段job_data,至此问题发现了。可怎么解决呢?blob类型的数据不能直接通过update来执行,毕竟要考虑到编码的因素,拿就釜底抽薪,直接将类重构为以前的类。
从这次经历来看,旧项目果然是坑,我就直愣愣的掉进去了。
结论:
计算机是个理性的东西,故一切皆有可能,即便是最不可能的事情也要去一一确认。在查找问题时最好想清楚所有发生故障的可能,然后一一排除,直到找到最终的问题。
对web开发来说,解决此类问题的一般思路如下:
1,从全局的角度来看,应用程序,缓存,数据库是三大独立模块,这些部分都有可能发生异常,应该首先排查应用程序本身的异常(这个概率最大);其次是缓存(同步)模块排查;最后是数据库模块排查。
2,全局确定好的前提下,细分上述的模块,将可能出现的问题一一列出。
3,动手,验证想法。对一个好的开发者来说,动手只是验证的手段,思路才是最重要的。