coding
This commit is contained in:
xueli.xue
parent
8048b0c78c
commit
88dc10684d
94
README.md
94
README.md
|
|
@ -17,6 +17,8 @@ XXL-JOB是一个轻量级分布式任务调度框架，其核心设计目标是
|
|||
- 10、邮件报警：任务失败时支持邮件报警，支持配置多邮件地址群发报警邮件；
|
||||
- 11、支持登录验证；
|
||||
- 12、GLUE：提供Web IDE，支持在线开发任务逻辑代码，动态发布，实时编译生效，省略部署上线的过程。支持30个版本的历史版本回溯。
|
||||
- 12、数据加密：调度中心和执行器之间的通讯进行数据加密，提升调度信息安全性；
|
||||
- 14、任务依赖：支持配置子任务依赖，当父任务执行结束且执行成功后将会主动触发一次子任务的执行；
|
||||
|
||||
#### 1.3 发展
|
||||
于2015年中，我在github上创建XXL-JOB项目仓库并提交第一个commit，随之进行系统结构设计，UI选型，交互设计……
|
||||
|
|
@ -59,7 +61,7 @@ XXL-JOB是一个轻量级分布式任务调度框架，其核心设计目标是
|
|||
技术交流群(仅作技术交流)：367260654 [](http://shang.qq.com/wpa/qunwpa?idkey=4686e3fe01118445c75673a66b4cc6b2c7ce0641528205b6f403c179062b0a52 )
|
||||
|
||||
|
||||
Tips: 历史Release版本下载位置如下图所示,请自行前往进行选择和下载。
|
||||
**Download**: 历史Release版本下载位置如下图所示,请自行前往进行选择和下载。
|
||||
|
||||
|
||||
|
||||
|
|
@ -140,9 +142,9 @@ Tips: 历史Release版本下载位置如下图所示,请自行前往进行选择
|
|||
|
||||
- **步骤一（新建任务）**：登陆调度中心，点击下图所示“新建任务”按钮，新建示例任务。然后，参考下面截图中任务的参数配置，点击保存。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
- **步骤二（GLUE任务开发）**：请点击下图中所示“GLUE入口按钮”，进入“GLUE编辑器开发界面”，见下图。GLUE任务默认已经初始化了示例任务代码，即打印Hello World。
|
||||
（GLUE实际上是一段继承自IJobHandler的Java类代码，它在执行器项目中运行，可使用@Resource/@Autowire注入执行器里中的其他服务，详细介绍请查看第三章节）
|
||||
|
|
@ -191,6 +193,7 @@ Tips: 历史Release版本下载位置如下图所示,请自行前往进行选择
|
|||
- 执行参数：任务执行所需的参数，多个参数时用逗号分隔，任务执行时将会把多个参数抓换成数组传入；
|
||||
- 报警邮件：任务调度失败时邮件通知的邮箱地址，支持配置多邮箱地址，配置多个邮箱地址时用逗号分隔；
|
||||
- 负责人：任务的负责人；
|
||||
- 子任务Key：每个任务都拥有一个唯一的任务Key，当本任务执行结束并且执行成功时，将会触发子任务Key所对应的任务的一次主动调度。
|
||||
|
||||
#### 3.1 BEAN模式任务
|
||||
Bean模式任务：任务逻辑以JobHandler的形式存在于“执行器”所在项目中，开发流程如下：
|
||||
|
|
@ -207,7 +210,7 @@ Bean模式任务：任务逻辑以JobHandler的形式存在于“执行器”所
|
|||
|
||||
参考上文“配置属性详细说明”对新建的任务进行参数配置，需要注意的是“JobHandler + GLUE复选框”任务属性，需要按照“GLUE模式”任务进行配置；
|
||||
|
||||
|
||||
|
||||
|
||||
#### 3.2 GLUE模式任务
|
||||
GLUE模式任务：任务逻辑以GLUE代码的形式存储在DB中，支持通过Web IDE在线更新，实时编译和生效，因此不需要指定JobHandler。开发流程如下：
|
||||
|
|
@ -216,7 +219,7 @@ GLUE模式任务：任务逻辑以GLUE代码的形式存储在DB中，支持通
|
|||
|
||||
参考上文“配置属性详细说明”对新建的任务进行参数配置，需要注意的是“JobHandler + GLUE复选框”任务属性，需要按照“GLUE模式”任务进行配置；
|
||||
|
||||
|
||||
|
||||
|
||||
- **步骤二：开发GLUE代码**：
|
||||
|
||||
|
|
@ -230,16 +233,16 @@ GLUE模式任务：任务逻辑以GLUE代码的形式存储在DB中，支持通
|
|||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
#### 4.2 编辑任务
|
||||
进入任务管理界面，选中指定任务。点击该任务右侧“编辑”按钮，在弹出的“编辑任务”界面更新任务属性后保存即可，可参考下图：
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
#### 4.3 编译GLUE代码
|
||||
#### 4.3 编辑GLUE代码
|
||||
|
||||
该操作仅针对GLUE任务。
|
||||
|
||||
|
|
@ -340,13 +343,20 @@ XXL-JOB首先定制了Quartz原生表结构前缀（XXL_JOB_QRTZ_）。
|
|||
##### 5.3.3 架构图（绘制中）
|
||||
|
||||
|
||||
#### 5.4 调度模块
|
||||
##### 5.4.1 RemoteHttpJobBean
|
||||
#### 5.4 调度模块剖析
|
||||
##### 5.4.1 quartz的不足
|
||||
Quartz作为开源作业调度中的佼佼者，是作业调度的首选。但是集群环境中Quartz采用API的方式对任务进行管理，从而可以避免上述问题，但是同样存在以下问题：
|
||||
- 问题一：调用API的的方式操作任务，不人性化；
|
||||
- 问题二：需要持久化业务QuartzJobBean到底层数据表中，系统侵入性相当严重。
|
||||
- 问题三：调度逻辑和QuartzJobBean耦合在同一个项目中，这将导致一个问题，在调度任务数量逐渐增多，同时调度任务逻辑逐渐加重的情况加，此时调度系统的性能将大大受限于业务；
|
||||
XXL-JOB弥补了quartz的上述不足之处。
|
||||
|
||||
##### 5.4.2 RemoteHttpJobBean
|
||||
常规Quartz的开发，任务逻辑一般维护在QuartzJobBean中，耦合很严重。XXL-JOB中“调度模块”和“任务模块”完全解耦，调度模块中的所有调度任务使用同一个QuartzJobBean，即RemoteHttpJobBean。不同的调度任务将各自参数维护在各自扩展表数据中，当触发RemoteHttpJobBean执行时，将会解析不同的任务参数发起远程调用，调用各自的远程执行器服务。
|
||||
|
||||
这种调用模型类似RPC调用，RemoteHttpJobBean提供调用代理的功能，而执行器提供远程服务的功能。
|
||||
|
||||
##### 5.4.2 调度中心HA（集群）
|
||||
##### 5.4.3 调度中心HA（集群）
|
||||
基于Quartz的集群方案，数据库选用Mysql；集群分布式并发环境中使用QUARTZ定时任务调度，会在各个节点会上报任务，存到数据库中，执行时会从数据库中取出触发器来执行，如果触发器的名称和执行时间相同，则只有一个节点去执行此任务。
|
||||
|
||||
```
|
||||
|
|
@ -358,7 +368,7 @@ org.quartz.jobStore.isClustered: true
|
|||
org.quartz.jobStore.clusterCheckinInterval: 1000
|
||||
```
|
||||
|
||||
##### 5.4.3 调度线程池
|
||||
##### 5.4.4 调度线程池
|
||||
默认线程池中线程的数量为10个，避免单线程因阻塞而引起任务调度延迟。
|
||||
|
||||
```
|
||||
|
|
@ -368,12 +378,12 @@ org.quartz.threadPool.threadPriority: 5
|
|||
org.quartz.threadPool.threadsInheritContextClassLoaderOfInitializingThread: true
|
||||
```
|
||||
|
||||
##### 5.4.4 @DisallowConcurrentExecution
|
||||
##### 5.4.5 @DisallowConcurrentExecution
|
||||
XXL-JOB调度模块的“调度中心”默认不使用该注解，即默认开启并行机制，因为RemoteHttpJobBean为公共QuartzJobBean，这样在多线程调度的情况下，调度模块被阻塞的几率很低，大大提高了调度系统的承载量。
|
||||
|
||||
XXL-JOB的每个调度任务虽然在调度模块是并行调度执行的，但是任务调度传递到任务模块的“执行器”确实串行执行的，同时支持任务终止。
|
||||
|
||||
##### 5.4.5 misfire
|
||||
##### 5.4.6 misfire
|
||||
错过了触发时间，处理规则。
|
||||
可能原因：服务重启；调度线程被QuartzJobBean阻塞，线程被耗尽；某个任务启用了@DisallowConcurrentExecution，上次调度持续阻塞，下次调度被错过；
|
||||
|
||||
|
|
@ -394,14 +404,14 @@ CronScheduleBuilder cronScheduleBuilder = CronScheduleBuilder.cronSchedule(jobIn
|
|||
CronTrigger cronTrigger = TriggerBuilder.newTrigger().withIdentity(triggerKey).withSchedule(cronScheduleBuilder).build();
|
||||
```
|
||||
|
||||
##### 5.4.6 日志回调服务
|
||||
##### 5.4.7 日志回调服务
|
||||
调度模块的“调度中心”作为Web服务单独部署，除此之外，内部嵌入jetty服务器提供日志回调服务。
|
||||
|
||||
“执行器”在接收到任务执行请求后，执行任务，在执行结束之后会将执行结果回调通知“调度中心”，回调端口如下图所示。
|
||||
|
||||
|
||||
|
||||
##### 5.4.7 任务HA（Failover）
|
||||
##### 5.4.8 任务HA（Failover）
|
||||
任务“执行器地址”支持配置多个，用逗号分隔，如“127.0.0.1:9998,127.0.0.1:9999”。
|
||||
|
||||
如果任务配置多个执行器地址，当调度中心每次发起调度请求时，会按照地址配置的顺序依次对执行器发出心跳检测请求，第一个检测为存活状态的执行器将会被选定。
|
||||
|
|
@ -411,7 +421,7 @@ CronTrigger cronTrigger = TriggerBuilder.newTrigger().withIdentity(triggerKey).w
|
|||
|
||||
“调度备注”可以查看执行器地址选择日志，任务配置的地址“227.0.0.1:9999,127.0.0.1:9999”，首先对第一个执行器地址“227.0.0.1:9999”进行心跳检测，心跳失败因此跳过；然后对第二个执行器地址“127.0.0.1:9999”进行心跳检测，心跳检测成功，选定为“目标执行器”；然后对“目标执行器”发送调度请求，调度流程结束，等待执行器回调执行结果。
|
||||
|
||||
##### 5.4.8 调度日志
|
||||
##### 5.4.9 调度日志
|
||||
调度中心每次进行任务调度，都会记录一条任务日志，任务日志主要包括以下三部分内容：
|
||||
|
||||
- 任务信息：包括“执行器地址”、“JobHandler”和“执行参数”等属性，根据这些参数，可以精确的定位任务执行的具体机器和任务代码；
|
||||
|
|
@ -433,14 +443,18 @@ CronTrigger cronTrigger = TriggerBuilder.newTrigger().withIdentity(triggerKey).w
|
|||
- 执行备注：执行器，任务执行的备注信息，如异常日志等；
|
||||
- 执行日志：任务执行过程中，业务代码中打印的完整执行日志，见“4.7 查看执行日志”；
|
||||
|
||||
##### 5.4.9 quartz的不足
|
||||
Quartz作为开源作业调度中的佼佼者，是作业调度的首选。但是集群环境中Quartz采用API的方式对任务进行管理，从而可以避免上述问题，但是同样存在以下问题：
|
||||
- 问题一：调用API的的方式操作任务，不人性化；
|
||||
- 问题二：需要持久化业务QuartzJobBean到底层数据表中，系统侵入性相当严重。
|
||||
- 问题三：调度逻辑和QuartzJobBean耦合在同一个项目中，这将导致一个问题，在调度任务数量逐渐增多，同时调度任务逻辑逐渐加重的情况加，此时调度系统的性能将大大受限于业务；
|
||||
XXL-JOB弥补了quartz的上述不足之处。
|
||||
##### 5.4.10 任务依赖
|
||||
原理：XXL-JOB中每个任务都对应有一个任务Key，同时，每个任务支持设置属性“子任务Key”，因此，通过“任务Key”可以匹配任务依赖关系。
|
||||
|
||||
#### 5.5 执行模块
|
||||
当父任务执行结束并且执行成功时，将会根据“子任务Key”匹配子任务依赖，如果匹配到子任务，将会主动触发一次子任务的执行。
|
||||
|
||||
在任务日志界面，点击任务的“执行备注”的“查看”按钮，可以看到匹配子任务以及触发子任务执行的日志信息，如无信息则表示未触发子任务执行，可参考下图。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
#### 5.5 执行模块剖析
|
||||
##### 5.5.1 Bean模式任务
|
||||
开发步骤：见章节三；
|
||||
原理：每个Bean模式任务都是一个Spring的Bean类实例，它被维护在“执行器”项目的Spring容器中。任务类需要加“@JobHander(value="名称")”注解，因为“执行器”会根据该注解识别Spring容器中的任务。任务类需要继承统一接口“IJobHandler”，任务逻辑在execute方法中开发，因为“执行器”在接收到调度中心的调度请求时，将会调用“IJobHandler”的execute方法，执行任务逻辑。
|
||||
|
|
@ -551,30 +565,30 @@ XXL-JOB会为每次调度请求生成一个单独的日志文件，通过重写L
|
|||
- 3、【重要】在 “调度中心” 支持HA的基础上，扩展执行器的Failover支持，支持配置多执行期地址；
|
||||
|
||||
#### 6.6 版本 V1.4.0 新特性
|
||||
- 1、执行器底层实现代码进行重度重构, 优化底层建表脚本;
|
||||
- 2、执行器中任务线程分组逻辑优化: 之前根据执行器JobHandler进行线程分组,当多个任务复用Jobhanlder会导致相互阻塞。现改为根据调度中心任务进行任务线程分组,任务与任务执行相互隔离;
|
||||
- 3、执行器调度通讯方案优化, 通过Hex + HC实现建议RPC通讯协议, 优化了通讯参数的维护和解析流程;
|
||||
- 4、调度中心, 新建/编辑任务, 界面属性调整:
|
||||
- 4.1、任务新增/编辑界面中去除 "任务名JobName"属性 ,该属性改为系统自动生成: 该字段之前主要用于在 "调度中心" 唯一标示一个任务, 现实意义不大, 因此计划淡化掉该字段,改为系统生成UUID,从而简化任务新建的操作;
|
||||
- 4.2、任务新增/编辑界面中去除 "GLUE模式" 复选框位置调整, 改为贴近"JobHandler"输入框右侧;
|
||||
- 4.3、任务新增/编辑界面中去除 "报警阈值" 属性;
|
||||
- 5、问题修复:
|
||||
- 5.1、执行器jetty关闭优化,解决一处可能导致jetty无法关闭的问题;
|
||||
- 5.2、执行器任务终止时,执行队列回调优化,解决一处导致任务无法回调的问题；
|
||||
- 5.3、调度中心中列表分页参数优化,解决一处因服务器限制post长度而引起的问题;
|
||||
- 5.4、执行器Jobhandler注解优化,解决一处因事务代理导致的容器无法加载JobHandler的问题;
|
||||
- 5.5、远程调度优化,禁用retry策略,解决一处可能导致重复调用的问题;
|
||||
- 1、任务依赖: 通过事件触发方式实现, 任务执行成功并回调时会主动触发一次子任务的调度;
|
||||
- 2、执行器底层实现代码进行重度重构, 优化底层建表脚本;
|
||||
- 3、执行器中任务线程分组逻辑优化: 之前根据执行器JobHandler进行线程分组,当多个任务复用Jobhanlder会导致相互阻塞。现改为根据调度中心任务进行任务线程分组,任务与任务执行相互隔离;
|
||||
- 4、执行器调度通讯方案优化, 通过Hex + HC实现建议RPC通讯协议, 优化了通讯参数的维护和解析流程;
|
||||
- 5、调度中心, 新建/编辑任务, 界面属性调整:
|
||||
- 5.1、任务新增/编辑界面中去除 "任务名JobName"属性 ,该属性改为系统自动生成: 该字段之前主要用于在 "调度中心" 唯一标示一个任务, 现实意义不大, 因此计划淡化掉该字段,改为系统生成UUID,从而简化任务新建的操作;
|
||||
- 5.2、任务新增/编辑界面中去除 "GLUE模式" 复选框位置调整, 改为贴近"JobHandler"输入框右侧;
|
||||
- 5.3、任务新增/编辑界面中去除 "报警阈值" 属性;
|
||||
- 6、问题修复:
|
||||
- 6.1、执行器jetty关闭优化,解决一处可能导致jetty无法关闭的问题;
|
||||
- 6.2、执行器任务终止时,执行队列回调优化,解决一处导致任务无法回调的问题；
|
||||
- 6.3、调度中心中列表分页参数优化,解决一处因服务器限制post长度而引起的问题;
|
||||
- 6.4、执行器Jobhandler注解优化,解决一处因事务代理导致的容器无法加载JobHandler的问题;
|
||||
- 6.5、远程调度优化,禁用retry策略,解决一处可能导致重复调用的问题;
|
||||
|
||||
Tips: 历史版本(V1.3.x)目前已经Release至稳定版本, 进入维护阶段, 地址见分支 [V1.3](https://github.com/xuxueli/xxl-job/tree/v1.3) 。新特性将会在master分支持续更新。
|
||||
|
||||
|
||||
#### 规划中
|
||||
- 1、任务依赖: 通过事件触发方式实现, 任务执行成功并回调SUCCESS时, 会主动触发一次依赖任务的调度;
|
||||
- 2、任务执行规则自定义：假如前一个任务正在执行，后续调度执行规则支持自定义；
|
||||
- 1、任务执行规则自定义：假如前一个任务正在执行，后续调度执行规则支持自定义；
|
||||
串行（默认，当前逻辑）：后续调度入调度队列；
|
||||
并行：后续调度并行执行；
|
||||
Pass：后续调度被Pass；
|
||||
- 3、兼容oracle；
|
||||
- 2、兼容oracle；
|
||||
|
||||
|
||||
## 七、其他
|
||||
|
|
|
|||
|
|
@ -43,6 +43,7 @@ public class XxlJobLogCallbackServerHandler extends AbstractHandler {
|
|||
if (log!=null) {
|
||||
|
||||
// trigger success, to trigger child job, and avoid repeat trigger child job
|
||||
String childTriggerMsg = null;
|
||||
if (!ResponseModel.SUCCESS.equals(log.getHandleStatus())) {
|
||||
XxlJobInfo xxlJobInfo = DynamicSchedulerUtil.xxlJobInfoDao.load(log.getJobGroup(), log.getJobName());
|
||||
if (xxlJobInfo!=null && StringUtils.isNotBlank(xxlJobInfo.getChildJobKey())) {
|
||||
|
|
@ -54,13 +55,15 @@ public class XxlJobLogCallbackServerHandler extends AbstractHandler {
|
|||
boolean ret = DynamicSchedulerUtil.triggerJob(childJobInfo.getJobName(), childJobInfo.getJobGroup());
|
||||
|
||||
// add msg
|
||||
String msg = requestModel.getMsg();
|
||||
msg += MessageFormat.format("<br> 触发子任务执行, jobKey:{0}, status:{1}, 描述:{2}", xxlJobInfo.getChildJobKey(), ret, childJobInfo.getJobDesc());
|
||||
requestModel.setMsg(msg);
|
||||
childTriggerMsg += MessageFormat.format("<br> 触发子任务成功, 子任务Key: {0}, status: {1}, 子任务描述: {2}", xxlJobInfo.getChildJobKey(), ret, childJobInfo.getJobDesc());
|
||||
} catch (SchedulerException e) {
|
||||
logger.error("", e);
|
||||
}
|
||||
} else {
|
||||
childTriggerMsg = "<br> 触发子任务失败, 子任务xxlJobInfo不存在, 子任务Key:" + xxlJobInfo.getChildJobKey();
|
||||
}
|
||||
} else {
|
||||
childTriggerMsg = "<br> 触发子任务失败, 子任务Key格式错误, 子任务Key:" + xxlJobInfo.getChildJobKey();
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
@ -68,7 +71,7 @@ public class XxlJobLogCallbackServerHandler extends AbstractHandler {
|
|||
// save log
|
||||
log.setHandleTime(new Date());
|
||||
log.setHandleStatus(requestModel.getStatus());
|
||||
log.setHandleMsg(requestModel.getMsg());
|
||||
log.setHandleMsg(requestModel.getMsg() + childTriggerMsg);
|
||||
DynamicSchedulerUtil.xxlJobLogDao.updateHandleInfo(log);
|
||||
responseModel = new ResponseModel(ResponseModel.SUCCESS, null);
|
||||
} else {
|
||||
|
|
|
|||
Loading…
Reference in New Issue