XXL-JOB是一个轻量级分布式任务调度平台，其核心设计目标是开发迅速、学习简单、轻量级、易扩展。现已开放源代码并接入多家公司线上产品线，开箱即用。

测试机器：116、143、220

1、FIRST（第一个） — 固定选择注册列表的第一个机器

测试1：运行3个执行器服务，注册列表排序143、220、116，应该每次都在143服务执行（符合预期）。

测试2: 关闭143服务，任务应该路由到220上执行（符合预期）。

测试3: 关闭220服务，任务应该路由到116上执行（符合预期）。

2、LAST（最后一个） — 固定选择注册列表的最后一个机器

测试1：运行3个执行器服务，注册列表排序143、220、116，应该每次都在116服务执行（符合预期）。

测试2: 关闭116服务，任务应该路由到220上执行（符合预期）。

测试3: 关闭220服务，任务应该路由到143上执行（符合预期）。

3、ROUND（轮询） — 循环选择执行注册列表的一个机器

测试1：运行3个执行器服务，注册列表排序143、220、116，依次在3个服务执行（符合预期）。

测试2：设置调度时间为2秒，当调度再次调度到143个服务时，后一次调度会阻塞2s左右，阻塞策略针对单执行器生效（符合预期）。

测试3: 关闭220服务，自动调整（符合预期）。

4、RANDOM（随机） — 随机选择注册列表的一个机器

测试1：运行3个执行器服务，注册列表排序143、220、116，随机在3个服务执行（符合预期）。

测试2: 关闭220服务，自动调整（符合预期）。

5、CONSISTENT_HASH（一致性HASH） — 每个任务按照Hash算法固定选择某一台机器，且所有任务均匀散列在不同机器上

测试1：运行3个执行器服务，注册列表排序143、220、116，配置3个任务，同一任务固定在一台服务器执行（符合预期）。

测试2：关闭220服务，自动重新负载，将220上执行的任务调度到另一个服务上执行（符合预期）。

6、LEAST_FREQUENTLY_USED（最不经常使用） — 使用频率最低的机器优先被选举

测试1：运行3个执行器服务，注册列表排序143、220、116，服务自动选择合适执行服务器（符合预期）。

7、LEAST_RECENTLY_USED（最近最久未使用） — 最久为使用的机器优先被选举

测试1：运行3个执行器服务，注册列表排序143、220、116，服务自动选择合适执行服务器（符合预期）。

8、FAILOVER（故障转移） — 按照顺序依次进行心跳检测，第一个心跳检测成功的机器选定为目标执行器并发起调度

测试1：运行3个执行器服务，注册列表排序143、220、116，先触发一次心跳检查，选择在活的执行服务器（符合预期）。

测试2：如果所有的执行器都故障，不执行路由，直接调度失败（服务全部关闭时直接爆执行器地址为空，没有模拟出该情况）。

9、BUSYOVER（忙碌转移） — 按照顺序依次进行空闲检测，第一个空闲检测成功的机器选定为目标执行器并发起调度

测试1：运行3个执行器服务，注册列表排序143、220、116，先自动触发一次空闲检查，选择空闲的执行服务器（符合预期）。

测试2：如果所有的执行器都忙碌，不执行路由，直接调度失败（job thread is running or has trigger queue）（符合预期）。

10、SHARDING_BROADCAST(分片广播) — 广播触发对应集群中所有机器执行一次任务，同时系统自动传递分片参数，可根据分片参数开发分片任务

测试1：运行3个执行器服务，注册列表排序143、220、116，每次会触发执行服务器（符合预期）。

测试2：获取并打印分片广播参数（ShardingUtil.getShardingVo()），得到对应的index和total值（符合预期）。

11、 阻塞策略：单机串行、丢弃后续调度、覆盖之前调度

测试1：运行3个执行器服务（服务等待6s），设置调用时间5s/次，阻塞策略单机串行，服务每次在143执行，且等待后继续执行（符合预期）。

测试2：运行3个执行器服务（服务等待6s），设置调用时间5s/次，阻塞策略丢弃后续调度，间隔性出现调度失败（block strategy effect：Discard Later）（符合预期）。

测试3：运行3个执行器服务（服务等待6s），设置调用时间5s/次，阻塞策略覆盖之前调度，全部出现调度成功，执行失败（block strategy effect：Cover Early [job running，killed]）（符合预期）。

12、使用建议

1）阻塞策略针对是的每个执行器节点的执行状况的处理，不是执行器集群的执行状况，请在使用时特别注意；

2）普通服务建议设置第一个/最后一个路由模式（主备）或一致性hash，防止出现未做好幂等多次执行相同服务的状况；

3）需要集群分片方式加快执行，可以使用分片广播方式，根据index和total做好分片处理逻辑；

4）阻塞策略根据需要可以选择单机串行 / 丢弃后续调度；

5）其他路由策略状况下请做好任务的幂等处理再尝试配置，同时根据业务设置好任务间隔时间和处理数据量。


⚠️线上问题实例

问题：发现两个服务器上毫秒级差别内执行相同单号的业务记录。

配置：路由策略 - 轮询， 任务时间 - 1分钟/次，阻塞策略 - 单机串行

查询对应时段的任务状况显示：

任务执行时间1分钟触发一次，两个节点交替触发，02:33:00 / 02:34:00 两次触发的任务分布在两台机器上执行，一次处理量667，另一次处理547，业务未做幂等处理，导致两次任务处理到相同数据；单机串行阻塞策略 02:35:00 / 02:36:00 两次任务推串行推迟执行，属于正常逻辑。


优化方案：

1、设置为路由策略为 第一个 / 最后一个 / 一致性hash，降低在多节点执行风险；

2、如果特别核心业务建议加入幂等处理逻辑；

3、限制每次服务处理数据量，保证设置的任务时间范围内能够执行完成。