可以看到，蓝色服务器在2016-07-23 15:19:50--15:20:09隔了19秒，这段时间只有白色服务器在运行。白色服务器并没有受到蓝色暂停的影响，分片参数仍按蓝色正常进行计算。

在运维界面点击【恢复】后，蓝色服务器又开始运行。

此处注意，若暂停的为主节点服务器（主节点一栏为对号的），会暂停所有服务器的该任务，运维界面有提示文字说明该情况。

　　3、分片不均，服务器执行任务时间不等的情况下，是否会出现相互等待的情况？

　　　测试结果为： A、B两台服务器，都是5秒执行一次，A执行很快(认为是0s)B执行很慢(需要8秒)，A并不会等待B。验证图如下：

　　　此问题，曾有小伙伴怀疑是否跟配置相关，并附代码如下：

　　　　此处依据是否开启monitorexecution，从而判断是否等待其它服务器；但需要注意的是，这里是重新分片时候的操作，注释中说的明白，如果要分片，且当前为主服务器，且开启了monitorexecution，则等待，跟本小节讨论的问题不是同一问题。因此，目前未发现与此问题相关的配置；当前版本是1.0.7。

　　4、失效转移（failover）问题究竟怎么理解，对性能有何影响？

　　　　官网的解释不多，此问题可以理解为：开启失效转移的情况下，如果任务执行过程中一台服务器失去连接，那么已经分配到该服务器的任务，将会在下次任务执行之前被当前集群中正常的服务器获取分片并执行，执行结束后再进行下一次任务；未开启失效转移，那么服务器丢失后，程序将不作任务处理，任由其丢失，但下次任务会重新分片。

　　　　两台机器(一个物理机，一个虚拟机)，10个分片，每1分钟执行一次任务(每个任务sleep10s，模拟任务执行花费的时间)，执行过程中中断虚拟机网络，使其失去跟zk的连接，测试结果如下：

　　　　　　　　　　　　　　图1：虚拟机日志截图

　　　　　　　　　　　　　　图2：物理机eclipse日志截图

　　　　观察两图，可以看到以下四个过程：

　　　　1、物理机先启动并执行第一次任务，获取全部分片；

　　　　2、然后虚拟机启动，第二次任务执行时，两台机器各分5个分片，该次任务两台机器均正常执行；

　　　　3、第三次任务开始，两台机器各获取5分片，任务执行的10s内，虚拟机断开跟物理机zk的连接：

　　　　　  这时候，断开的虚拟机仍然正常执行自己已经获得的分片任务，物理机开始阶段也正常执行自己获得的分片任务，但执行完毕后32s，又获得了分片4=E，这时候可以看到时间并未

　　　　　  到达1分钟，也就是并未达到下次任务开始时间；稍后又分多次获取了本次分给虚拟机的其它分片，我们可以看到获取到所有分片的时间已经超过了1分钟；分片执行结束后，并未

　　　　　  等待，而是直接执行了下一次任务(原来都是1分钟整点执行，这次是在22s执行)；

　　　　4、虚拟机丢失，物理机获取所有分片信息，并且执行时间变成了从22s开始执行。

　　　注意：该过程中，分片0-4对应的业务信息，实际被执行了两次，可能会对业务数据产生影响。

　　　failover对性能有影响有一个前提是开启monitor-execution，这个监控是造成性能下降的关键。failover=true，monitor-execution=false的情况下，failover不会生效(本地测试结果如此，需要monitor-execution的支持)。

　　------------------------------------------------------------------------------------------------------------------------------------------------------------------

　　以上问题为实际开发过程中遇到的疑问，自己在本地测试的结果，难免有考虑不周的情况，有错误之处欢迎留言讨论。

　　ps：今天看了下官网，发现官方已经推出elastic-job-cloud了！这是个什么东东？！看上去貌似很好很强大，稍后得看一下，努力追赶各路开源大神的脚步，，，，，