XXL-JOB任务调度中心
参考文章

任务类型

1. BEAN模式: 类形式、方法形式
   Bean模式任务，支持基于方法的开发模式，每个任务对应一个方法。
   优点:
   每个任务只需要开发一个方法，并添加**@XxlJob注解**即可，方便简单快捷
   支持自动扫描并添加至执行器容器中。
   缺点:
   要求spring开发环境，基本现在项目spring必备，所以无伤大雅。
   新定时任务的CRUD需要项目的重新构建和项目启动，如果遇到未执行完毕的情况，可能会多次执行，但是保证多次执行和一次执行的结果不影响，对系统也不会有影响

2. GLUE模式：Java / Shell / Python / Nodejs / Php
   定时任务以源码方式维护在调度中心，不需要在本地编写任何代码，我们在使用过程中，经常是在本地编码完毕后，直接复制到线上维护中心中
   优点:
   支持通过Web IDE在线更新，实时编译和生效，因此不需要指定JobHandler和重启项目
   缺点：
   如果你依赖了某个框架和服务，需要先依赖到自己项目中，然后在Web IDE中才能依赖，否则会执行报错，正常可以理解为，把代码从项目中搬到线上，可以实时编辑，但是和自己在本地写代码的要求一样，依赖和服务必须全部具备，多用于定时任务经常调整的场景中使用

路由策略

路由策略：当执行器集群部署时，选择哪一台机器进行执行job任务

1. 第一个： 当选择该策略时，会选择执行器注册地址的第一台机器执行，如果第一台机器出现故障，则调度任务失败。

2. 最后一个： 当选择该策略时，会选择执行器注册地址的最后一台机器执行，如果第二台机器出现故障，则调度任务失败。

3. 轮询：当选择该策略时，会按照执行器注册地址轮询分配任务，如果其中一台机器出现故障，调度任务失败，任务不会转移。（常用）

4. 随机：当选择该策略时，会按照执行器注册地址随机分配任务，如果其中一台机器出现故障，调度任务失败，任务不会转移。

5. 一致性HASH： 当选择该策略时，每个任务按照Hash算法固定选择某一台机器。如果那台机器出现故障，调度任务失败，任务不会转移。

6. 最不经常使用： 当选择该策略时，会优先选择使用频率最低的那台机器，如果其中一台机器出现故障，调度任务失败，任务不会转移。（实践表明效果和轮询策略一致）

7. 最近最久未使用： 当选择该策略时，会优先选择最久未使用的机器，如果其中一台机器出现故障，调度任务失败，任务不会转移。（实践表明效果和轮询策略一致）

8. 故障转移： 当选择该策略时，按照顺序依次进行心跳检测，如果其中一台机器出现故障，则会转移到下一个执行器，若心跳检测成功，会选定为目标执行器并发起调度。

9. 忙碌转移： 当选择该策略时，按照顺序依次进行空闲检测，如果其中一台机器出现故障，则会转移到下一个执行器，若空闲检测成功，会选定为目标执行器并发起调度。

10. 分片广播： 当选择该策略时，广播触发对应集群中所有机器执行一次任务，同时系统自动传递分片参数；可根据分片参数开发分片任务。如果其中一台机器出现故障，则该执行器执行失败，不会影响其他执行器。

阻塞处理策略

阻塞处理策略：调度过于密集执行器来不及处理时的处理策略

1. 单机串行（默认）：调度请求进入单机执行器后，调度请求进入FIFO队列并以串行方式运行。

2. 丢弃后续调度：调度请求进入单机执行器后，发现执行器存在运行的调度任务，本次请求将会被丢弃并标记为失败。生产环境下，一般使用丢弃后续调度。

3. 覆盖之前调度：新的调度请求进入单机执行器后，发现执行器存在运行的调度任务，将会终止运行中的调度任务并清空队列，然后运行本次新的调度任务。

调度过期策略

1. 忽略：调度过期后，忽略过期的任务，从当前时间开始重新计算下次触发时间。

2. 立即执行一次：调度过期后，立即执行一次，并从当前时间开始重新计算下次触发时间。