先贴几张图，看看效果：
环境和版本说明：xxl-job版本为2.1.2；调度器和执行器都是通过k8s部署了3个节点如图一所示，同一个任务在同一时间执行了3次，分别由不同的调度器调度，因为路由策略选的是一致性HASH，所以同一个任务的执行器是在同一个机器执行。
想问下，这种情况升级到最新版本能解决吗？还是说可以通过其他设置能避免这种问题？ @xuxueli因为我们对这个框架做了比较多的自定义开发，升级版本的成本要高一些，还请告知一下，谢谢！
gtlvzcf81#
我也出现同样的问题
8hhllhi22#
我目前线上暂时只用了一个调度中心。测试环境部署多个就会概率性出现这种问题，而且概率还不低，无奈只能这样。作者也没有说法，很尴尬。
z9zf31ra3#
我这边出现的概率奇高接近90%，再研究一段时间，降低版本再试试，一直无法解决只能放弃了，生产环境重复任务太致命了，目前我也是只保留了一台调度中心
xdnvmnnf4#
问题已解决：问题是批量执行sql脚本时此INSERT INTO xxl_job_lock ( lock_name) VALUES ( 'schedule_lock');脚本没生效，导致DB锁未生效
k4emjkb15#
谢谢反馈。那我的问题可能和你还不太一样，我测试环境这个数据是有的。我这边压测出现的概率是比较低的，一万次调度差不多有20-30笔重复执行的。
fbcarpbf6#
少量重复建议做个redis锁和幂等
ia2d9nvy7#
@jipeigong 能详细讲一下如何解决的吗？
0mkxixxg8#
我也遇到这个问题，看代码xxl_job_lock这个表感觉没用，有人解决吗
8条答案
按热度按时间gtlvzcf81#
我也出现同样的问题
8hhllhi22#
我目前线上暂时只用了一个调度中心。测试环境部署多个就会概率性出现这种问题，而且概率还不低，无奈只能这样。作者也没有说法，很尴尬。
z9zf31ra3#
我这边出现的概率奇高接近90%，再研究一段时间，降低版本再试试，一直无法解决只能放弃了，生产环境重复任务太致命了，目前我也是只保留了一台调度中心
xdnvmnnf4#
问题已解决：问题是批量执行sql脚本时此INSERT INTO xxl_job_lock ( lock_name) VALUES ( 'schedule_lock');脚本没生效，导致DB锁未生效
k4emjkb15#
谢谢反馈。那我的问题可能和你还不太一样，我测试环境这个数据是有的。我这边压测出现的概率是比较低的，一万次调度差不多有20-30笔重复执行的。
fbcarpbf6#
少量重复建议做个redis锁和幂等
ia2d9nvy7#
@jipeigong 能详细讲一下如何解决的吗？
0mkxixxg8#
我也遇到这个问题，看代码xxl_job_lock这个表感觉没用，有人解决吗