xxl-job集群部署调度中心重复调度问题

不知言愁

已于 2025-03-19 10:11:07 修改

阅读量613

点赞数 4

CC 4.0 BY-SA版权

文章标签： oracle 数据库

于 2025-03-19 10:08:40 首次发布

本文链接：https://blog.youkuaiyun.com/m0_47136198/article/details/146361799

问题场景：

业务需要做xxljob集群支持高可用稳定性支撑，打算部署两台服务器用的同一套数据库，通过nginx路由进行跳转负载均衡。

因存在两台调度中心，顾思考是否会产出重复调度的问题，于是查看源码，调度中心源码实现如下，只贴出部分。

原因分析：

根据上述代码可见，采用了数据库for update获取行锁，来保证同一时间只有一台服务器可查询需要执行的任务，及调度，但是问题出现了，不同服务器之间，时间几乎做不到完全同步的，若是两台服务器时间不同步，是否会产生重复调度的问题呢？源码中 PRE_READ_MS 常量=5，即它会预读当前时间往后5s内的数据，及处理过期未执行的任务。这里假设，服务器A的时间为1:00:00 服务器B的时间为1:00:04 job1设置为每秒执行一次假设此时服务器B获取数据库锁开始执行，将job1的下次执行时间更改为1:00:05，执行完毕，释放锁。服务器A获取数据库锁，查询需要执行的任务,即查询下次执行时间小于等于(1:00:00 + 5s) = 1:00:05秒的数据，这时它查出了已被B服务器执行过的任务job1，所以此时，它还会再调度一次，所以此时就出现了重复调度的问题。以上的假设是建立在每次执行都很快的情况下，即从B执行到结束释放锁到A获取锁查询到任务这一段时间在1S内发生。

解决方案：

由上可知，它会预读出执行时间小于当前时间5s后的数据，若是两台服务器间时间是同步的，则数据库锁即可解决问题，但是当两台服务器时间不同步时，且相差在5s内，则不可避免会导致已执行过的任务被另一台服务器查询出来并再次执行，所以此时，若两台服务器时间不能同步，为了避免重复调度，则将他们的时间差设置在5s及以上，这时先执行的服务器(时间快于服务器A的服务器B)，会将任务的下次执行时间更新为时间比较慢的服务器A所够不着的位置（服务器B时间+1s,1s表示假设该任务每秒执行一次），这时，服务器A+5s也无法预读到原本就比它时间快5秒且+1S后执行的job1,这样就避免了重复调度的问题，但是随之而来的是，这个任务将一直只被服务器B去调度，除非B挂了，这样也就缺少了调度集群部署的意义了。

方案补充：

路由策略：选择一致性HASH
阻塞处理策略：选择丢弃后续调度
在这里插入图片描述

配置详解：

基础配置：
    - 执行器：任务的绑定的执行器，任务触发调度时将会自动发现注册成功的执行器, 实现任务自动发现功能; 另一方面也可以方便的进行任务分组。每个任务必须绑定一个执行器, 可在 "执行器管理" 进行设置;
    - 任务描述：任务的描述信息，便于任务管理；
    - 负责人：任务的负责人；
    - 报警邮件：任务调度失败时邮件通知的邮箱地址，支持配置多邮箱地址，配置多个邮箱地址时用逗号分隔；
触发配置：
    - 调度类型：
        无：该类型不会主动触发调度；
        CRON：该类型将会通过CRON，触发任务调度；
        固定速度：该类型将会以固定速度，触发任务调度；按照固定的间隔时间，周期性触发；
        固定延迟：该类型将会以固定延迟，触发任务调度；按照固定的延迟时间，从上次调度结束后开始计算延迟时间，到达延迟时间后触发下次调度；
    - CRON：触发任务执行的Cron表达式；
    - 固定速度：固定速度的时间间隔，单位为秒；
    - 固定延迟：固定延迟的时间间隔，单位为秒；
任务配置：
    - 运行模式：
        BEAN模式：任务以JobHandler方式维护在执行器端；需要结合 "JobHandler" 属性匹配执行器中任务；
        GLUE模式(Java)：任务以源码方式维护在调度中心；该模式的任务实际上是一段继承自IJobHandler的Java类代码并 "groovy" 源码方式维护，它在执行器项目中运行，可使用@Resource/@Autowire注入执行器里中的其他服务；
        GLUE模式(Shell)：任务以源码方式维护在调度中心；该模式的任务实际上是一段 "shell" 脚本；
        GLUE模式(Python)：任务以源码方式维护在调度中心；该模式的任务实际上是一段 "python" 脚本；
        GLUE模式(PHP)：任务以源码方式维护在调度中心；该模式的任务实际上是一段 "php" 脚本；
        GLUE模式(NodeJS)：任务以源码方式维护在调度中心；该模式的任务实际上是一段 "nodejs" 脚本；
        GLUE模式(PowerShell)：任务以源码方式维护在调度中心；该模式的任务实际上是一段 "PowerShell" 脚本；
    - JobHandler：运行模式为 "BEAN模式" 时生效，对应执行器中新开发的JobHandler类“@JobHandler”注解自定义的value值；
    - 执行参数：任务执行所需的参数；     
高级配置：
    - 路由策略：当执行器集群部署时，提供丰富的路由策略，包括；
        FIRST（第一个）：固定选择第一个机器；
        LAST（最后一个）：固定选择最后一个机器；
        ROUND（轮询）：；
        RANDOM（随机）：随机选择在线的机器；
        CONSISTENT_HASH（一致性HASH）：每个任务按照Hash算法固定选择某一台机器，且所有任务均匀散列在不同机器上。
        LEAST_FREQUENTLY_USED（最不经常使用）：使用频率最低的机器优先被选举；
        LEAST_RECENTLY_USED（最近最久未使用）：最久未使用的机器优先被选举；
        FAILOVER（故障转移）：按照顺序依次进行心跳检测，第一个心跳检测成功的机器选定为目标执行器并发起调度；
        BUSYOVER（忙碌转移）：按照顺序依次进行空闲检测，第一个空闲检测成功的机器选定为目标执行器并发起调度；
        SHARDING_BROADCAST(分片广播)：广播触发对应集群中所有机器执行一次任务，同时系统自动传递分片参数；可根据分片参数开发分片任务；
    - 子任务：每个任务都拥有一个唯一的任务ID(任务ID可以从任务列表获取)，当本任务执行结束并且执行成功时，将会触发子任务ID所对应的任务的一次主动调度。
    - 调度过期策略：
        - 忽略：调度过期后，忽略过期的任务，从当前时间开始重新计算下次触发时间；
        - 立即执行一次：调度过期后，立即执行一次，并从当前时间开始重新计算下次触发时间；
    - 阻塞处理策略：调度过于密集执行器来不及处理时的处理策略；
        单机串行（默认）：调度请求进入单机执行器后，调度请求进入FIFO队列并以串行方式运行；
        丢弃后续调度：调度请求进入单机执行器后，发现执行器存在运行的调度任务，本次请求将会被丢弃并标记为失败；
        覆盖之前调度：调度请求进入单机执行器后，发现执行器存在运行的调度任务，将会终止运行中的调度任务并清空队列，然后运行本地调度任务；
    - 任务超时时间：支持自定义任务超时时间，任务运行超时将会主动中断任务；
    - 失败重试次数；支持自定义任务失败重试次数，当任务失败时将会按照预设的失败重试次数主动进行重试；