jobService.addJob通过获取ZK信息注册任务的例外场景

[idyoudo]

#1、问题
现有代码是通过判断计数器JOB_ADD_COUNT是否为1来决定是否执行addJob(job)方法，但是这样还是有例外场景。
#2、场景
比如有进程A，B，都需要执行同样的任务，先启动进程A，显示调用了addJob方法，此时在zk上完成任务的注册。待注册成功后启动进程B，没有显示调用addJob，那么monitorJobRegister方法启动监听，执行
case CHILD_ADDED的逻辑，但是在进程B中由于还没有执行对应job的addJob方法，此时的计数器还没有初始化，那么monitorJobRegister中的的动态注册任务是不会执行的。

#3、分析
正常情况下，进程启动后，由进程解析ElasticJobConf，然后注册任务(addJob)，那么原有的逻辑是不会有问题的，但是存在一种例外情况，如上所述，启动进程B，在上下文中没有ElasticJobConf注解，纯碎是根据zk的注册信息，通过执行monitorJobRegister监听代码，完成任务的注册。

建议，可以综合考虑上述的两种情况，在JobService中维护一个任务注册器，只要任务已经注册了，就不调用addJob方法，否则就执行。

[idyoudo]

还可以在监听的时候，留下扩展接口，将如何添加job的控制权交给应用程序来管理。

[idyoudo]

if(!jobRecord.containsKey(job.getJobName())){
if (ClassUtils.isPresent(job.getJobClass(), JobService.class.getClassLoader())) {

            if(jobServiceCallbacks!=null && jobServiceCallbacks.size()>0){
              for(String callKey  :  jobServiceCallbacks.keySet()){
                jobServiceCallbacks.get(callKey).callback(job);
              }
            }else{
              addJob(job);
            }
          } else {
            removeJob(job.getJobName());
          }
        }

[yinjihuan]

目前动态job是这样设计的，因为原生的ESJob没有带这个功能，这个是我自己扩展加上去的。
我对这个动态任务的设想是某些业务逻辑是一样的，但是会在不同的时间点去执行，比如定时发送新闻，也就是说这个动态任务是一次性的，下次启动是不会再次注册的，如果你的任务需要启动页执行的话，那么没必要用动态任务去添加，直接采取配置的方式。

所以B在A注册成功之后，再次启动是肯定不会去注册的。也不会执行case CHILD_ADDED这里的逻辑，因为zk节点增加的时候，B还不在线。