背景：
现有软件中定时调度需求一直存在；不论是业务系统亦或者是大数据等等；带着这样的背景学习了两个开源且社区活跃的框架：XXL-Job、DolphinScheduler。
学习目标：
出四篇相关文章分别是：
《XXL-Job官网学习心得》、
《XXL-Job源码下载并部署使用》、
《DolphinScheduler官网学习心得》、
《DolphinScheduler源码下载并部署使用》
本文就先完成第一个目标；
官方文档：https://www.xuxueli.com/xxl-job/
一、简介：
XXL-JOB也是一款任务调度系统，也是一种分布式架构，组件分为：调度中心、执行器、MySQL;
二、运行模式：
1. 支持Bean模式；
2. Glue模式（Java、Shell、Python、PHP、NodeJs、PowerShell）
Bean模式是以Java代码的方式写在【执行器】中，最后跟随执行器一起发布；
Glue模式是以源码方式维护在调度中心中，其中Glue-Java是以groovy方式维护；
三、调度中心
调度中心集群通过 DB锁 来控制并发，保证同一时刻只有一个调度中心在进行任务筛选，并将符合调度的任务从DB中筛选出来通过RPC分发给执行器。
四、执行器介绍：
执行器在启动时，内部会维护一张表，表中包含了该执行器所有Bean模式的任务name；
执行器接收到调度中心的请求，负责执行具体的任务；
由于 运行模式 有两大类：Bean模式与Glue模式，执行器执行不同类别任务，处理逻辑有点不同；若某个执行器接收到了调度请求为Bean模式，则执行器会先去查找自身启动时就维护的Bean表，匹配到了，则执行其具体的执行逻辑；若接受到的为Glue模式任务，如Java，则会以groovy方式实例化Java字符串成Java对象，再去执行对应逻辑；
三、任务注册、任务自动发现（执行器）
xxl-job官方表示，为了不增加部署与学习成本，不打算引入zk作为任务注册、发现，而是采用了DB方式；
执行器注册: 任务注册Beat周期默认30s; 执行器以一倍Beat进行执行器注册与保活, 调度中心以一倍Beat进行动态任务发现; 注册信息的失效时间为三倍Beat;
四、定时框架：
xxl-job 早期版本使用的是Quartz进行定时调度、在V2.1.0版本废弃了Quartz，采用xxl系列自研调度组件;
三、优点：
1. 分片广播
该特性适用场景如：10个执行器的集群来处理10w条数据，每台机器只需要处理1w条数据，耗时降低10倍；2、广播任务场景：广播执行器机器运行shell脚本、广播集群节点进行缓存更新等，同时分片支持动态分片，即已经发布的任务会动态感知分片数的变化进而进行执行（摘自官网）。
2. 任务路由策略
执行器的路由策略丰富，但很多策略都是针对“执行器”为集群模式而言，在一个执行器集群中进行轮训或者分片广播等路由策略。
3. 执行器隔离
每个执行器都有 AppName 属性，相同AppName的执行器集合为一个执行器集群，新增任务时选择执行的最小单元为 执行器/执行器集群；不同执行器集群/执行器不可能同时运行一个任务；
4. 调度线程池隔离
调度中心从DB中筛选出符合执行的任务之后，会根据这些任务以往的触发调度表现，选择性的将调度任务放在Fast线程池或Slow线程池中，以避免因某些执行器的网络问题导致调度中心在与执行器RPC通信时异常的慢，导致整个线程池被拖慢，影响后续任务调度；
四、缺点：
1. 任务与调度中心或执行器耦合
任务以两种形式存在：Bean、Glue。而这两种方式都会与调度器或执行器强耦合在一起。尤其是任务以Bean模式发布，这种方式需要提交对应的执行器代码；
2. 分布式锁
DB作为分布式锁性能开销比较大，没有ZK或Redis快；
3. 任务之间的依赖关系简单
无法做到DAG方式有复杂依赖关系
4. 任务发布不遍历
无法拖拽任务（个人感觉第三点和第四点有因果关系）
结语：本文为学习官网心得，大多数为自己所思所想，必定存在不足之处，欢迎留言给出宝贵评论。
网友评论