xxlJob，路由策略，阻塞处理策略，应该怎么选？
路由策略
路由策略：（任务分发给哪个执行器实例）
阻塞处理策略
阻塞处理策略：（当任务还在执行、下一个周期又到了怎么处理）。
一、 路由策略（Route Strategy）怎么选？
路由策略决定了当有多个执行器（Executor）节点在线时，Cron 触发的任务究竟由哪一台机器来执行。
| 策略名称 | 核心机制 | 适用场景 | 选型建议 |
|---|---|---|---|
| FIRST（第一个） | 每次都选择注册地址列表的第一个节点。 | 单机运行、热备场景。 | 极少单独用，除非强制要求固定机器。 |
| LAST（最后一个） | 每次都选择最后一个节点。 | 同上。 | 极少用。 |
| ROUND（轮询） | 依次循环分发给所有在线节点。 | 无状态的普通定时任务、均摊压力。 | 最常用默认推荐。多台机器平摊任务量。 |
| RANDOM（随机） | 随机选择一个节点执行。 | 无状态任务。 | 可选，但均匀度不如轮询。 |
| CONSISTENT_HASH（一致性哈希） | 同一个参数的任务总会被路由到固定机器（通过 Param 算哈希）。 | 分片任务、需要缓存亲和性（如某台机器加载了特定数据缓存）。 | 针对有状态或需要参数路由的场景。 |
| LEAST_FREQUENTLY_USED（最不经常使用） | 优先选择近期使用次数最少的机器。 | 机器性能差异较大、动态负载均衡。 | 较少使用。 |
| LEAST_RECENTLY_USED（最近最少使用） | 优先选择一段时间内没有被执行过的机器。 | 同上。 | 较少使用。 |
| FAILOVER（故障转移） | 按照顺序依次心跳检测，选择第一个存活的机器。 | 高可用、对单点故障极度敏感的任务。 | 关键任务强烈推荐。确保只要有一台机器活着就能跑。 |
| BUSYOVER（忙碌转移） | 按照顺序依次心跳检测，选择第一个空闲（不忙碌）的机器。 | 耗时较长、单机容易并发冲突的任务。 | 适合长耗时任务。 |
| SHARDING_BROADCAST（分片广播） | 不是路由到一台，而是把任务参数广播给所有在线机器（每台机器拿自己的 index 和总数 total）。 |
大数据量跑批、海量数据并行处理（如每天凌晨百万级数据对账、群发短信）。 | 大批量数据处理的唯一标准解法。 |
二、 阻塞处理策略（Blocking Strategy）怎么选？
当任务的执行耗时超过了 Cron 的调度周期（例如任务每 5 分钟跑一次，但这次跑了 10 分钟还没跑完，下一个周期的任务又触发了），就会触发阻塞策略。
XXL-JOB 提供了三种处理方式：
| 策略名称 | 核心机制 | 风险 / 副作用 | 适用场景 |
|---|---|---|---|
| 单机串行（SERIAL_EXECUTION）（默认） | 后续的触发请求在单机内存中排队等待。等上一个任务跑完，当前机器接着跑。 | 如果堆积过多，会导致线程池爆满、任务严重滞后。 | 绝大多数标准定时任务的首选。保证数据不乱、逻辑不重入。 |
| 丢弃后续调度（DISCARD_LATER） | 如果上一个任务还在跑，直接丢弃当前周期的触发请求，并记录日志。 | 会漏掉某个周期的执行。 | 对实时性要求不高、允许漏跑的周期性统计/同步任务（例如每分钟同步一次状态，这次没跑完，等下一分钟再同步无所谓）。 |
| 覆盖之前调度（COVER_EARLY） | 强行干掉（或终止）正在执行的上一个任务，让当前最新的任务立刻执行。 | 容易导致正在执行的一半的业务逻辑被中断、数据出现半事务状态（除非代码做了严谨的幂等和中断捕获）。 | 极少使用，除非是那种“后面覆盖前面”且不怕中断的场景（如大盘实时指标全量刷新）。 |
三、 经典组合拳推荐（生产环境套路）
在日常开发中，绝大多数任务可以直接套用以下两套“黄金组合”：
- 常规稳妥型（90% 的业务任务，如对账、对表、状态扫描）
- 路由策略：
ROUND（轮询）或FAILOVER（故障转移） - 阻塞策略：
单机串行 (SERIAL_EXECUTION) - 效果：多台机器均摊，单台机器上严格排队，绝对不会因为重复调度把数据库写崩。
- 海量跑批型（大数据量清洗、分片并行处理）
- 路由策略：
分片广播 (SHARDING_BROADCAST) - 阻塞策略：
单机串行 (SERIAL_EXECUTION)（配合分片，每台机器各跑各的互不影响） - 效果：把 100 万数据拆成 N 份，所有机器同时开跑，极大缩短跑批时间。