5
1.9.2-SNAPSHOT 数据库10.0.20-MariaDB-log 事务提交模式，READ-COMMITTED
两个调度协调执行，不会出现重复
解决方式： quartz.properties 增加 org.quartz.jobStore.acquireTriggersWithinLock: true
参考： https://github.com/quartz-scheduler/quartz/issues/107
Q
[xuxueli/xxl-job]Case Study：调度集群模式 任务重复执行问题
A
回答
0
你好，quartz官方尚未给出该issue的结论，其文档建议为false，暂时先等待quartz反馈。
3
我也遇到了重复触发的问题，有没有什么好的解决办法？不然我们的分布式任务调度就失去价值了～
8
目前重复调度问题解决了吗？
1
这里的重复调度应该和quartz没有关系； 因为xxl-job采用了异步化的设计，但是当多次调度落在不同机器时，确实是会造成任务并行执行； 根本原因应该是每台执行器维护的任务队列会重复。 @xuxueli
1
我说的不是这个，我遇到的问题就是quartz重复触发，截图为证。
6
对于xxl-job，因为公用的RemoteHttpJobBean并没有DisallowConcurrentExecution注解，也就是说任务可以被并行执行（似乎加了注解也有可能导致任务重复触发，我这里还没出现，有可能是机器检入异常导致的，等待quartz官方给出结论）。可以参考这里https://github.com/quartz-scheduler/quartz/issues/107 @cheocs
org.quartz.jobStore.acquireTriggersWithinLock这个配置应该是没有效果的，因为quartz源码中决定是否拿到triggers的操作是原子的。
8
最近出现非常频繁：
2
红字“失败”的地方都是重复触发的，即两台调度机器在同一时间点调用了同一个执行机器，执行机器上使用【丢弃后续调度】把任务标记失败了。
4
怀疑是多台调度器前后取到了waiting状态的trigger，从而导致任务重复触发。 quartz的结构主要有triggers， firedTriggers表。firedTriggers写入与修改triggers状态的操作是上锁的，但是对于statelessJob，会将trigger状态改为waiting状态，导致重复触发。 考虑以下场景：有A、B调度器，任务1 A修改1状态为accquired，A写入firedTriggers表，同时修改1状态为waiting； B重复A的操作（有可能机器有时差，这里也是xxl-job作者建议调度集群的时差不要超过1s的原因）； 造成了任务重复调度。
8
仔细研究了下quartz的misfire策略，请参照这里#445
0
修改org.quartz.jobStore.acquireTriggersWithinLock，我这边集群调度，没再出现重复，可以试试
1
调度密集或者耗时任务可能会导致任务阻塞，集群情况下调度组件（quartz）小概率情况下会重复触发； 针对上述情况，可以通过结合 "单机路由策略（如：第一台、一致性哈希）" + "阻塞策略（如：单机串行、丢弃后续调度）" 来规避，最终避免任务重复执行。
2
目前我碰到的这个概率不小，差不多一个小时就出现一次。不过仅仅是在路由策略为故障转移的情况的情况下才会触发。
0
org.quartz.jobStore.acquireTriggersWithinLock 加了这个参数我这里还是会出现重复调度的问题
5
Which version of XXL-JOB do you using? 2.1.0 release 数据库mysql数据库 5.7.22-0ubuntu0.16.04.1 事务提交模式，REPEATABLE-READ
Expected behavior 一次任务corn触发，只调度一次。
Actual behavior 一次任务corn触发，重复调度3次以上。
Steps to reproduce the behavior
1.部署2.1.0 release版本微服务到服务器中。
2.业务微服务中实现IJobHandler 实现业务行为。
3.管理页面进行执行器注册（自动）
4.任务添加 corn触发
分片策略（使用过第一个和一致性HASH）
单机串行（如果使用丢弃后续调度，则新建其他任务无法调度同一业务（调度任务参数不同））
@xuxueli 麻烦帮忙看下。
3
我这边任务重复触发是由于scheduleUpdate 方法中的 XxlJobInfo 这个SQL没有变更状态导致的。现在处理后，无问题， 我看最新的快照版本已经把这个地方修复了。
4
admin集群模式下，最新版本2.1.1也存在重复执行，大神们，有解决办法吗？
3
admin集群，2.1.0版本，同时间重复调度。设置的是第一台，丢弃后续调度。接入了钉钉告警，暂时先在告警的地方将discard later信息的trigger msg 忽略告警了。丢弃后续调度暂时不影响业务。 每天会存在很多执行中的任务，不知道是不是调度中心没有接收到回调呢？
5
admin集群，2.1.0版本也遇到这个问题，占位持续关注。
4
你好，admin做集群，两台机，每分钟执行一次，出现重复调度的问题，两个重复任务间隔10秒执行，版本2.1.0
5
你好，admin做集群，两台机，每分钟执行一次，出现重复调度的问题，两个重复任务间隔10秒执行，版本2.1.0
请问解决了吗？我的是2.1.2的版本也有这个问题。
1
admin集群模式下，最新版本2.1.1也存在重复执行，大神们，有解决办法吗？
大佬，请问解决了吗？2.1.2 一致性hash 单机串行策略 也重复执行，楼上说配置quartz属性，但是高本版的根本就没有用quartz.
1
遇到同样的问题，路由策略为第一个；每次任务调度时还是同时触发了两次。怎么解决的呢？
6
遇到同样的问题，路由策略为第一个；每次任务调度时还是同时触发了两次。怎么解决的呢？
问题已解决，是 lock 表没有添加初始化数据，导致每次 select for update 时没有锁住。 可以在代码里检查一下，当锁记录不存在时抛个错出来。
0
2.2.1版本也出现了重复执行的情况
5
2.2.1版本也出现了重复执行的情况
大佬，这个重复执行的问题解决了吗？
4
我也遇到这个问题了（2.1.x）， 初始化数据的时候少执行了lock表数据插入的sql
com.xxl.job.admin.core.thread.JobScheduleHelper#start
这行代码会因为没数据导致互斥失效
8
感觉破案了？
4
这边用的2.3.0版本，部署的两个xxl-job-admin节点，也高概率出现了同时触发2次的问题，网上查了些资料，包括来这个issue学习。最后了解到xxl job靠 select * from xxl_job_lock where lock_name='schedule_lock' for update 实现全局锁，最后怀疑到数据库mysql的多节点部署上。当时用的3主集群方案，数据库连接字符串如下： jdbc:mysql:loadbalance://192.168.1.100:3306,192.168.1.200:3306,192.168.1.300:3306/xxl_job?useUnicode=true&characterEncoding=utf8&useSSL=true&serverTimezone=GMT%2B8 猜测可能在一个数据库节点加全局锁后，全局锁信息还没同步到另一个数据库节点，这时另一个xxljob节点的加锁请求就来了（基本上可以理解为强并2个请求），导致定时任务又触发成功，全局锁此时失效。 所以想办法让两个节点的xxl job连接同一台数据库看是否能解决问题，将数据库连接字符串都改为server failover模式即可，即： jdbc:mysql://192.168.1.100:3306,192.168.1.200:3306,192.168.1.300:3306/xxl_job?useUnicode=true&characterEncoding=utf8&useSSL=true&serverTimezone=GMT%2B8
问题解决！希望能帮到你。
mysql驱动协议可参考网友文章：https://blog.csdn.net/weixin_33754065/article/details/92072857
3
@xuxueli 用了一个多月了，今天忽然出现所有job间歇性调度失败，丢弃后续调度的错误。通过修改job执行时间，比如从原来每分钟执行一次改成每秒钟执行一次，调度失败的现象就会消失，请问这是怎么回事。
1
任务执行重复
版本：2.0.1
路由策略：第一个
阻塞处理策略：单机串行
