blob字段乱码怎么处理_一个基于quartz的调度平台改造的问题处理过程

最近在做一个调度平台改造的项目，quartz在测试环境跑的是单机环境，生产上两台服务器做集群。

测试环境是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，动手，验证想法。对一个好的开发者来说，动手只是验证的手段，思路才是最重要的。