一、xxl-job 架构设计

总体分两个部分：

调度中心：负责管理调度信息，按照调度配置发出调度请求，自身不承担业务代码。调度系统和任务解耦，提高了系统可用性和稳定性。通调度性能不在受限于任务模块。
执行器：负责接收调度中的请求并执行任务逻辑。任务模块专注于任务的执行操作，开发和运维更加简单和高校。
设计思想：

调度和任务两个部分相互解耦，全异步化和轻量化，可以提高系统的稳定性和扩展性。

二、xxl-job原理
2.1、执行器注册

执行器启动主要是把自己注册到调度中心然后保存在数据库（xxl_job_registry表），并定时发送心跳，保持续约。执行器正常关闭，也主动告知调度中心注销，这种是主动注册。

如果执行器网络故障，调度中心就不知道执行器的情况，如果把任务路由给一个不可用的执行器，就会导致任务失败。所以调度中心需要不断的对执行器探活（RocketMQ的NameServer 管理broker一样），调度中心会启动一个后台线程定时调用执行器接口，如果发现异常就下线。

2.2、调度中心和任务执行

JobRegistryMonitorHelper 不停的更新注册表，把超时的执行器剔除（每隔30s执行一次）
创建线程池
调度器线程ScheduleThread：计算预读取的任务数（默认6000），然后while 循环不停的获取到期的任务
时间轮线程池
获取任务锁：第一步获取数据库排它锁，如果没有成功说明其他的调度中心在加载任务
查询任务：获取锁后， 查询任务
调度任务
任务触发，选择执行器：按照配置的路由策略，不通路由策略获取方式也不一样
远程执行：拿到执行器之后，runExecutor 触发远程的执行器
执行器处理远程调用，回调
2.3、 时间轮

一批任务都是不同的时间执行，执行时间精确到秒，如何实现对所有的任务调度这个就是时间轮。

2.4、任务超时

如果任务在指定的时间范围内没有返回结果，就不在等结果，抛出异常。FutureTask
2.5、失败重试

如果任务执行失败，会更新在xxl_job_log日志表里。调度中心有个后台线程monitorThread。第一步就是查日志表里结果不是200的任务，为了防止集群下同时处理一个失败任务，用了数据库的乐观锁（版本号），如果失败重试次数>0，代表重试，就要重新触发。

调度器启动：
JobFailMonitorHelper.getInstance().start();
1
2
2.6、故障转移

如果一个执行器挂了，就找另一个执行器执行，直到找到一个正常的执行器。

FAILOVER(I18nUtil.getString("jobconf_route_failover"), new ExecutorRouteFailover())
1
2.7、任务数据分片

这里的是数据分片，需要用到分片参数 sharding param，调度器负责把这个分片参数分发给每个执行器（执行器个数和参数个数相等），怎么根据分片参数对数据分片是Job自己的事情。

XxlJobTrigger#trigger
————————————————
版权声明：本文为CSDN博主「Heloise_yangyuchang」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq_35958391/article/details/124554693