Elastic-Job的分片任务在调度执行中，由于某种原因未执行完毕，下一次调度任务触发后，如果在同一个Job实例中出现两个线程处理同一个分片上的数据，这样就会造成两个线程处理到相同的数据。
为了避免上述问题，Elastic-Job引入任务错过机制(misfire)与幂等机制(monitorExecution)，来确保同一条数据不会被多个Job同时处理，避免同一条数据被同一个Job实例的多个线程处理。
重申一次Elastci-Job的分布式是数据的分布式，一个任务在多个Job实例上运行，每个Job实例处理该Job的部分数据（数据分片）。
1、Elastic-Job如何确保同一个Job实例的多个线程不会处理相同的数据。
场景：任务调度周期为每5s执行一次，正常每次调度任务处理需要耗时2s，如果在某一段时间由于数据库压力变大，导致原本只需要2s就能处理完成的任务，现在需要16s才能完成。
在这个数据处理的过程中，每5s又会触发一次调度（任务处理），如果不加以控制的话，在同一个实例上根据分片条件去查询数据库，查询到的数据有可能相同（部分相同），这样同一条任务数据将被多次运行。
如果这个任务是处理转账业务，如果在业务方法不实现幂等，则会引发非常严重的问题，那ElasticJob是否可以避免这个问题呢？
答案是肯定。elastic-Job提供了一个配置参数：monitorExecution=true，开启幂等性。
幂等机制开启后的工作流程：
（1）Elastic-Job在开启monitorExecution(true)【幂等机制】机制的情况下，在分片任务开始时会在注册中心zookeeper上创建${namespace}/jobname/sharding/{item}/running临时节点，在任务结束后会删除该目录。
（2）在判断是否有分片正在运行时，只需判断是否存在上述节点即可。如果存在，调用setMisfire方法，将分片状态设置为mirefire，表示错失了一次任务执行。如果该分片被设置为mirefire并开启了事件跟踪，将事件跟踪保存在数据库中。
（3）设置misfire的方法会为分配给该实例下的所有分片创建持久节点${namespace}/jobname/shading/{item}/misfire节点。
（4）注意，只要分配给该实例的任何一分片未执行完毕，则在该实例下的所有分片都增加misfire节点，然后忽略本次任务触发执行，等待任务结束后再执行其他未忽略的任务。
（5）在任务执行完成后检查是否存在${namespace}/jobname/sharding/{item}/misfire节点，如果存在，则首先清除misfie相关的文件，然后执行任务。
Elastic-Job的misfire实现方案总结：
在下一个调度周期到达之后，只要发现这个分片的任何一个分片正在执行，则为该实例分片的所有分片都设置为misfire，等任务执行完毕后，再统一执行下一次任务调度。
技术原理其实很简单，就是通过zookeeper来实现分布式锁来完成幂等性。
2、Elastic-Job如何确保数据不会被多个Job实例处理？
Elastic-Job基于数据分片，不同分片根据分片参数(人为配置)，从数据库中查询各自数据(任务数据分片)，如果当节点宕机，数据会重新分片，如果任务未执行完成，然后执行分片，数据是否会被不同的任务同时处理呢？
答案是不会，因为当节点宕机（作业执行节点）后，是否需要重新分片事件监听器会监听到Job实例代表的节点删除，设置重新分片。在任务被调度执行具体处理逻辑之前，需要重新分片，重新分片的前提就是要所有的分片任务全部执行完毕，这也依赖是否开启幂等控制(monitorExecution)。
如果开启幂等机制，Elastic-Job能感知正在执行处理逻辑的分片，重新分片需要等待当前所有分片任务全部运行完毕后才会触发，故不会存在不同节点处理相同数据的问题。
场景：一个任务JOB的调度频率为每10s一次，在某个时间，该job执行耗时用了33s（平时只需执行5s），按照正常调度，应该后续会触发3次调度，那该job后执行完，会连续执行3次调度吗？
答案：在33s这次任务执行完成后，如果后面的任务执行在10s内执行完毕的话，只会触发一次，不会补偿3次，因为ElasticJob记录任务错失执行，只是创建了misfire节点，并不会记录错失的次数，因为也没这个必要。
参考文章：https://blog.csdn.net/prestigeding/article/details/80140777
