xxl-job-plus: 通过改造xxl-job，实现分布式延迟任务的功能。调度时间精确，误差不超过1秒

比如server端部署了两台，worker这样配置server地址：192.168.2.1:7700,192.168.2.2:7700，假设第一个节点永远正常，因为worker启动的时候，都是从第一个节点开始请求的，那么就会导致所有应用的currentServer的值都是第一个服务的ActorSystem的地址。worker刚启动的时候，也不知道server的哪个节点是正常的，所以，会从配置的第一

就需要查询xxl-job-registry表了，这个表中存放的是各个执行器节点注册时的信息，然后通过心跳机制，不停的更新时间，所以，如果多长时间以内（3*30s）没有更新时间，就判定这个节点下线了，然后把地址重新汇总之后，存到xxl_job_group表中。如果这个新执行时间点没有超过当前时间+5s的时间点，就将这个任务放到时间轮中，然后重新在新执行时间点的基础上计算下次的执行时间，并更新表，相对

如果缓存了这个东西，请求到达客户端之后，就可以快速从里面找到执行器进行执行，因为JobHandler中封装了bean的类型，方法，init方法，destroy方法，这样直接通过反射就可以执行了。所以，这里要做的是，找到当前这个客户端节点的ip，并且从9999这个端口为界，先向上找到一个小于65535的没有使用的端口，如果没有，就向下找，直到找到为止，和ip拼接成一个客户端的地址。通过一个自研的注册

我们分析过，客户端在启动时，会找到所有的执行器，并以执行器的名字作为key，缓存在map中，这里的loadJobHandler就是根据名字从缓存中找到对应的执行器。那么又会出现2种情况：如果新名字可以在初始化缓存中找到对应的执行器，就将原来绑定的线程终止掉，然后生成一个新的线程，重新绑定任务id和执行器，后面的任务就都用新的执行器执行了；这样做的好处是，将执行快的任务和执行慢的任务进行隔离，避免慢

这里主要是考虑到，如果客户端下线，到了调度时间的任务，服务端找不到一个执行节点来执行，那么任务的状态就会一直是调度中。所以，这里做个规定，超过10分钟，状态还是“调度中”的任务，需要重新复位一下，让它立马再调度一次，保证这个任务至少执行一次。客户端项目启动的时候，将Bean中标记了@XxlDelay注解的方法收集起来，封装成IJobHandler，并且以value定义的名称作为key缓存起来，方便