ElasticJob的幂等机制，是指作业分片执行的幂等，他需要做到以下两点：
- 同一个分片在当前作业实例上不会被重复执行
- 一个作业分片不能同时在多个作业实例上执行
在ElasticJob中幂等机制是依赖misfire事务错过机制和monitor幂等机制同时来完成的，其实在这里好像也不能强行保证幂等，还是需要依赖业务的幂等来兜底保证。
1、如何保证同一个分片在当前作业实例上不会被重复执行？
分片任务执行一次没有执行完成，第二次又调度执行这种情况，导致分片数据会被重复执行。在ElasticJob中，通过开启misfire机制，任务执行前会在内存中设置任务为running状态，如果开启了monitor机制，同时会在zookeeper中创建/sharding/{item}/running临时节点，在下次任务调度到来时，会查看是否存在分片正在执行中running临时节点，如果前面有分片任务在执行，这个时候就会设置任务分片错过misfire，创建/sharding/{item}/misfire节点，待上次作业执行完成的时候，查看是否有错过执行的分片任务，重新补偿执行分片任务。
2、如何保证一个分片不会被下发给多个作业实例执行？
一个分片在执行的时候，突然宕机退出作业集群了，这个时候会导致重新分片，然后宕机的分片被重新指派给新机器，这个时候就会导致分片数据的重复执行。在ElasticJob中，重新分片的时候，需要等待这个作业实例的所有分片作业执行完成才行。所以正在执行的分片任务不会被重复分配给其他作业实例。但是/sharding/{item}/running节点是一个临时节点，在机器宕机的时候，这个节点就被删除了，重新分片等待所有分片任务完成的时候，是没法感知到对应的分片数据是否完成，这里是存在幂等问题的，还是需要靠业务自己去控制幂等。
可以看到ElasticJob的幂等控制其实做的还不是完善，依然会存在任务分片数据会被重复执行，在以下场景仍然会被重复执行：
- 分片任务执行一半宕机，/sharding/{item}/running临时节点删除，如果开启了故障转移，这个宕机机器上的分片都会被转移到其它正常节点作业实例上执行，如果没有开启故障转移配置，在重新分片的时候需要等待该作业的所有分片任务完成，其实这个时候宕机导致临时节点的删除，是没法感受到分片任务是否完成的。再重新分片的时候，会导致重复执行的问题。
