概述

这个系列计划里面是只有3篇，但是在后续使用的过程中发现了新的问题，以及发现了一个很重要但是没有写上的部分。

遇到的问题是在服务器上运行时，有可能是服务器的CPU和内存资源比个人笔记本上的资源要强大，导致在服务器上采用第三篇 中说到的“如果我需要在job中重新设定下次触发的时间怎么办”中给出的方式，在日志中看到在reschedule的时候，同时出发最多接近10次。

第三篇没有写上的内容是，如何看zookeeper上的节点信息。

接下来一起看一下以上两个点。

使用elastic-job在job内部调用reschedule遇到的问题

在job内部调用reschedule时由于第三篇中说到的下次触发时间计算的问题，导致在reschedule的时刻任务被同时触发了多次，尤其是当服务器空闲资源比较多，或者服务器资源比较强大的时候，触发的次数会更多。

对于这个问题，我们期初使用的是Thread.sleep(1)的方式规避，最好的情况下定时任务1分钟能够执行60，000次。如果用于处理订单的话，这个处理能力对于小型系统来说相当好了，足够用了。

但是，同时触发的现象确实感觉十分不舒服，并且会导致很多无效日志的输出，造成日志体积增大。

由于当前我们的系统规模较小，订单量也小，使用了Thread.sleep(500)的激进方案，这样算下来1分钟内最多最好也就能够处理120次，虽然这个数字很小，但是对我们当前情况来说足够用。

对于这个问题，如果仍然基于elastic-job框架最扩展的话，我们想可以这样处理：借助elastic-job的分片机制，在把待处理订单号插入队列中时添加不同的序列标记，可以和分片数相同。那么总体处理能力就会和服务器的数量成正比：120xN次（N是服务器数量）。这就达到了处理能力的水平扩展。

我如何知道自己任务的执行情况和任务节点的状态信息

这一点有两种方法，一个就是部署一个elastic-job的console服务，通过网页端查看任务的执行情况和任务节点的状态信息。

如果觉得不熟一套console服务必要性不大，也可以自己到zookeeper上查看各个节点的状态。zookeeper有一个eclispe的插件，可以直接在eclipse里面看到zk的节点数据。

安装插件可以参考这篇文章：