xxl-job定时任务执行日志部分“消失”

现象：

于xxxx月18日发现备机定时任务10:30时尚未执行，业务侧也未执行。

直接原因：

 在XXJobTrigger执行loadId时异常，是一个非原子性事务问题。执行日志如下

，XXJobTrigger方法执行与外层的调用者XXJobScheduleHelper调度器的scheduleUpdate方法（更新调度状态）不在一个线程、一个事务里面，导致内层的loadId报错了，业务还未执行，但调度状态确已持久化，调度状态决定了下次执行时间。

分析：

首先，通过观察，131日志中有大量和的loadId一样的异常，绝大部分是”连接不可用“，如下

，而132不存在这种异常；

其次，通过查看数据库xxl-job执行日志，发现132处理了大部分任务，131承担了小部分任务，而18日的10:30定时任务轮给131执行，排除压力问题导致131执行异常。进而怀疑131执行少的原因依旧是大量的“连接不可用”异常导致；

第三，131的“连接异常”为什么如此频繁？通过观察日志进一步发现系统启动时存在反向域名解析的隐患，据以往的经验，Oracle JDBC建立连接时，也存在反向域名解析的逻辑。若反向域名解析的时长不稳定将直接导致JDBC连接创建不稳定，这也能解释为什么131服务连接有大量连接异常。

措施：

    修改131、132本地/etc/hosts文件，使JDK的反向域名方法根据本地文件而不是走域名解析服务器这种不稳定的方式获取。

后续：暂未发现异常，需持续观察两天，若XXXXXJobTrigger有错，则依旧存在对于稍长（短任务执行频率高，人工发现难）任务需要手工补录的问题。