xxl-job是一个分布式定时任务调度框架，功能强大，底层使用自己实现的rpc框架进行注册和管理，数据库使用mysql，调度触发使用数据库锁来作为调度锁。
xxl-job主要分为调度中心admin以及任务，任务引入依赖jar包并配置启动类为spring所管理的bean后，将自动通过spring-bean提供的initMethod进行启动线程选择一个端口进行注册以及监听任务调度。
公司目前引入xxl-job框架代替quartz框架作为分布式任务调度组件，并在其之上进行一定开发以及优化，所以这篇文章主要分享一些深入使用，主要是概念的详细介绍。
由于篇幅有限，这里没有写的很详细，有需要完整版和更多知识点介绍的朋友可以点一点下方链接免费领取
链接：1103806531暗号：CSDN
系统关键概念介绍
执行器
配置中心配置的执行器，概念上对应执行定时任务的服务，支持分布式调度以及调度的各种路由规则配置。注册方式支持自动注册和手动配置机器地址两种方式，心跳时间间隔默认为30s，失效时间90s。
执行器自动注册后，调度中心页面依旧有最长30秒的延迟显示，原因是数据库中注册表更新后，展示执行器的表是由另一个守护线程去更新的，更新频率为默认心跳时间30s，所以管理台展示会有延迟，但不影响任务调度。
任务
任务以执行器为维度配置，每个任务必须属于一个执行器，当任务触发时会根据该任务所属的执行器去寻找执行器的地址列表，然后通过配置的路由规则以及阻塞规则去去执行。
任务支持本地任务以及远程任务，本地任务即按照执行方写好的业务逻辑执行。远程任务通过GLUE，在调度中心管理台写好代码，分发到执行方去执行。建议无特殊需求的话，统一使用本地任务。
任务配置项描述
- 执行器：选择该任务由哪个执行器去执行
- 任务描述：简单描述该任务的功能以及作用，如：订单定时跑批
- 路由策略：设置任务执行时，如何去选择执行器，高频任务建议使用一致性哈希或者第一台执行
- Cron：Cron表达式，描述任务运行的时间
- 运行模式：BEAN即为接入服务配置在本地对应的handler运行，其他方式均为管理台设置代码交由接入服务远程执行
- JobHandler：运行模式为BEAN时必填，值应当为接入服务本地执行任务的handler
- 阻塞策略：当同一任务多次调度到同一台执行器时，执行器应当使用的策略
- 子任务ID：如配置，则该任务完成后自动触发一次子任务的执行
- 任务超时时间：配置后当任务超时时将自动终止任务执行。
- 失败重试次数：任务失败后重试的次数。
- 负责人：一般为该任务接入方的负责人
- 报警邮件：任务报警后发送的邮件地址
- 任务参数：若配置了任务参数，任务调度时将发送任务参数至执行方handler。
阻塞策略
阻塞策略即同一个任务在执行器的阻塞执行策略。由执行器端控制。典型场景为：任务A分发到执行器A执行，此时任务A再次触发并分发到执行器A，此时根据阻塞策略选择的不同将会有以下三种执行策略：
- 单机串行 该策略下，同一执行器收到同一任务的调度触发时，若已有任务正在执行，会将后续的任务放入执行线程的队列中，等待线程轮询继续执行，可能会导致线程队列阻塞过多任务导致内存过高，高频且耗时较长任务慎用。
- 丢弃后续调度 该策略下，同一执行器收到同一任务的调度触发时，若已有任务正在执行，会直接丢弃后续同一任务的调度，推荐使用。
- 覆盖之前调度 该策略下，同一执行器收到同一任务的调度触发时，若已有任务正在执行，将会直接停止正在执行的任务（通过线程InterruptedException异常以及volatile变量判断），并将新任务放入队列。一般情况下不建议使用。
路由策略
路由策略即任务在配置中心进行调度分发时，选择执行器的策略。由配置中心端控制。典型场景为：任务A触发执行，任务A对应的执行器有执行器A，B，C，D，此时根据路由策略的选择将会有以下几种分发情况
- 第一个：始终选择第一台执行器作为任务执行器，不论该任务执行器是否正常。
- 最后一个：始终选择最后一台作为任务执行器
- 轮询：每个执行器轮流执行
- 随机：随机选择一个执行器执行
- 一致性HASH：根据任务ID做一致性哈希选择执行器，同一个任务必定只分发到同一个执行器。高频或耗时较长任务推荐使用
- 最不经常使用：选择平均使用频率最低的执行器。
- 最近最久未使用：选择最近的最久未使用的执行器。
- 故障转移：分别进行心跳检测，选择第一台心跳检测正常的机器执行。
- 忙碌转移：分别进行忙碌检测，选择第一台空闲的机器执行。
- 分片广播：广播到所有执行器执行，并提供分片参数，分片参数获取方式如下，应用在被触发时动态获取自己是第几个分片，共有几个分片：
日志问题
xxl-job相关日志使用默认使用slf4j作为日志框架，使用专门的API写入日志时，会输出2种日志，客户端日志与服务端日志
客户端日志
客户端日志根据配置文件中配置的logpath指定，根据源码分析，客户端日志将通过FileOutputStream写到对应文件，且无法通过配置修改，所以只好修改了源码中的逻辑，改为该值为空未配置时，直接通过slf4j写入。
服务端日志
使用xxljob的日志api输出日志时，日志也会在调度管理台看到，能看到的原理是xxl-job管理台会通过rpc调用执行器的接口，执行器收到请求后从指定的日志文件中读取执行的日志并返回，这里存在一个比较麻烦的问题，就是xxl-job这种日志的逻辑，无法很好的兼容到项目统一的日志模块里，十分不便。
所以实际使用过程中，我们在xxl-job管理台查询日志时，对其进行了改造，修改为不从rpc查询，而是走我们日志管理的搜索引擎根据执行的jobid查询相关日志，结合客户端日志输出的改造，从而统一xxl-job和我们系统间的日志管理。
框架目前发现的缺点以及存在的问题
- 目前定时任务的调度串行是依赖db锁的，某个子微服务或者子系统内部使用还好，但是不适合整个公司级别共用，这点和数据库的耦合比较高，并没有本地缓存之类的，对数据库的HA依赖非常高。
- 管理模块以及权限模块，组内和小公司用用可以，不适合作为多个系统多个部门之间共用的中间件。
- 管理台存在一些简单的安全bug，sql注入和js脚本注入非常简单。（公司的安全测试测出来的）
- 相关协议支持较差，使用自己实现的RPC协议,如果需要dubbo或者spring cloud，需要自己拓展。并且虽然底层是netty，但是本身对netty异常的封装并不是很好，导致一些奇怪的网络问题或者其他的协议，会报莫名其妙的错，没有一定netty理解的人是看不懂的，这点我提了Issue，不过出于这套框架解耦与独立的设计，估计是不会支持dubbo和spring cloud的。
- 上面提到的，日志模块更建议自己整体修改下写入逻辑，管理台看不到无所谓，（毕竟定时任务也没谁会去管理台看日志，并且这部分日志写多了对性能和网络开销有影响的），写到本地使用elk之类的再查就可以了。
- 定时任务触发的流水号或者跟踪id，需要改动原框架，否则也会影响后续日志追踪的问题。
总体而言这是一个很不错的框架，关于定时任务的执行器和调度器关系也很优雅,值得拓展或者进行一定定制开发。目前使用来，稳定性也没有问题。
最后
为大家整理了各个知识点模块整理文档（微服务、数据库、mysql、jvm、Redis等都有）和更多大厂面试真题，有需要的朋友可以点一点下方链接免费领取
链接：1103806531暗号：CSDN
