|
|
|
@ -34,6 +34,7 @@ XXL-JOB是一个轻量级分布式任务调度框架,其核心设计目标是 |
|
|
|
|
- 20、脚本任务:支持以GLUE模式开发和运行脚本任务,包括Shell、Python等类型脚本; |
|
|
|
|
- 21、阻塞处理策略:调度过于密集执行器来不及处理时的处理策略,策略包括:单机串行(默认)、丢弃后续调度、覆盖之前调度; |
|
|
|
|
- 22、失败处理策略;调度失败时的处理策略,策略包括:失败告警(默认)、失败重试; |
|
|
|
|
- 23、分片广播任务:执行器集群部署时,任务路由策略选择"分片广播"情况下,一次任务调度将会广播触发集群中所有执行器执行一次任务,可根据分片参数开发分片任务; |
|
|
|
|
|
|
|
|
|
### 1.3 发展 |
|
|
|
|
于2015年中,我在github上创建XXL-JOB项目仓库并提交第一个commit,随之进行系统结构设计,UI选型,交互设计…… |
|
|
|
@ -272,7 +273,7 @@ XXL-JOB是一个轻量级分布式任务调度框架,其核心设计目标是 |
|
|
|
|
|
|
|
|
|
- 执行器:任务的绑定的执行器,任务触发调度时将会自动发现注册成功的执行器, 实现任务自动发现功能; 另一方面也可以方便的进行任务分组。每个任务必须绑定一个执行器, 可在 "执行器管理" 进行设置; |
|
|
|
|
- 描述:任务的描述信息,便于任务管理; |
|
|
|
|
- 路由策略:当执行器集群部署时,执行器路由规则; |
|
|
|
|
- 路由策略:当执行器集群部署时,提供丰富的路由策略,包括; |
|
|
|
|
FIRST(第一个):固定选择第一个执行器; |
|
|
|
|
LAST(最后一个):固定选择最后一个执行器; |
|
|
|
|
ROUND(轮询):; |
|
|
|
@ -282,6 +283,8 @@ XXL-JOB是一个轻量级分布式任务调度框架,其核心设计目标是 |
|
|
|
|
LEAST_RECENTLY_USED(最近最久未使用):单个JOB对应的每个执行器,最久为使用的优先被选举; |
|
|
|
|
FAILOVER(故障转移):按照顺序依次进行心跳检测,第一个心跳检测成功的机器选定为目标执行器并发起调度; |
|
|
|
|
BUSYOVER(忙碌转移):按照顺序依次进行空闲检测,第一个空闲检测成功的机器选定为目标执行器并发起调度; |
|
|
|
|
SHARDING_BROADCAST(分片广播):广播触发对应集群中所有执行器执行一次任务,同时传递分片参数;可根据分片参数开发分片任务; |
|
|
|
|
|
|
|
|
|
- Cron:触发任务执行的Cron表达式; |
|
|
|
|
- 运行模式: |
|
|
|
|
BEAN模式:任务以JobHandler方式维护在执行器端;需要结合 "JobHandler" 属性匹配执行器中任务; |
|
|
|
@ -679,24 +682,29 @@ XXL-JOB会为每次调度请求生成一个单独的日志文件,需要通过 |
|
|
|
|
|
|
|
|
|
为保证系统"轻量级"并且降低学习部署成本,没有采用Zookeeper作为注册中心,采用DB方式进行任务注册发现; |
|
|
|
|
|
|
|
|
|
#### 5.8 路由策略 |
|
|
|
|
执行器集群部署时提供丰富的路由策略,包括: |
|
|
|
|
|
|
|
|
|
FIRST(第一个):固定选择第一个执行器; |
|
|
|
|
LAST(最后一个):固定选择最后一个执行器; |
|
|
|
|
ROUND(轮询):; |
|
|
|
|
RANDOM(随机):随机选择在线的执行器; |
|
|
|
|
CONSISTENT_HASH(一致性HASH):分组下机器地址相同,不同JOB均匀散列在不同机器上,保证分组下机器分配JOB平均;且每个JOB固定调度其中一台机器; |
|
|
|
|
LEAST_FREQUENTLY_USED(最不经常使用):单个JOB对应的每个执行器,使用频率最低的优先被选举; |
|
|
|
|
LEAST_RECENTLY_USED(最近最久未使用):单个JOB对应的每个执行器,最久为使用的优先被选举; |
|
|
|
|
FAILOVER(故障转移):按照顺序依次进行心跳检测,第一个心跳检测成功的机器选定为目标执行器并发起调度; |
|
|
|
|
BUSYOVER(忙碌转移):按照顺序依次进行空闲检测,第一个空闲检测成功的机器选定为目标执行器并发起调度; |
|
|
|
|
|
|
|
|
|
#### 5.9 任务执行结果 |
|
|
|
|
#### 5.8 任务执行结果 |
|
|
|
|
自v1.6.2之后,任务执行结果通过 "IJobHandler" 的返回值 "ReturnT" 进行判断; |
|
|
|
|
当返回值符合 "ReturnT.code == ReturnT.SUCCESS_CODE" 时表示任务执行成功,否则表示任务执行失败,而且可以通过 "ReturnT.msg" 回调错误信息给调度中心; |
|
|
|
|
从而,在任务逻辑中可以方便的控制任务执行结果; |
|
|
|
|
|
|
|
|
|
#### 5.9 "分片广播" 特性 |
|
|
|
|
执行器集群部署时,任务路由策略选择"分片广播"情况下,一次任务调度将会广播触发对应集群中所有执行器执行一次任务,同时传递分片参数;可根据分片参数开发分片任务; |
|
|
|
|
|
|
|
|
|
"分片广播" 是以执行器集群进行分片,每个执行器属于一片,激情中多个执行器可协同分片处理大数据量任务; |
|
|
|
|
|
|
|
|
|
"分片广播" 和普通任务开发流程一致,不同之处在于可以可以获取分片参数,获取分片参数对象的代码如下(可参考example执行器中的示例任务"ShardingJobHandler" ): |
|
|
|
|
|
|
|
|
|
ShardingUtil.ShardingVO shardingVO = ShardingUtil.getShardingVo(); |
|
|
|
|
|
|
|
|
|
该分片参数对象拥有两个属性: |
|
|
|
|
|
|
|
|
|
index:当前分片序号(从0开始),执行器集群列表中当前执行器的序号; |
|
|
|
|
total:总分片数,执行器集群的总机器数量; |
|
|
|
|
|
|
|
|
|
该特性适用场景如: |
|
|
|
|
- 1、分片任务场景:10个执行器的集群来处理10w条数据,每台机器只需要处理1w条数据,耗时降低10倍; |
|
|
|
|
- 2、广播任务场景:广播执行器机器运行shell脚本、广播集群节点进行缓存更新等 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## 六、版本更新日志 |
|
|
|
|
#### 6.1 版本 V1.1.x,新特性[2015-12-05] |
|
|
|
@ -888,7 +896,7 @@ Tips: 历史版本(V1.3.x)目前已经Release至稳定版本, 进入维护阶段 |
|
|
|
|
- 11、调度中心任务注册检测逻辑优化; |
|
|
|
|
|
|
|
|
|
#### 6.18 版本 V1.8.1 特性[快照版本] |
|
|
|
|
- 1、任务分片:一个任务被拆分成N个独立的任务单元,然后由分布式部署的执行器分别执行某一个或几个分片单元; |
|
|
|
|
- 1、分片广播任务:执行器集群部署时,任务路由策略选择"分片广播"情况下,一次任务调度将会广播触发集群中所有执行器执行一次任务,可根据分片参数处理分片任务; |
|
|
|
|
- 2、执行器JobHandler禁止命名冲突; |
|
|
|
|
|
|
|
|
|
#### TODO LIST |
|
|
|
|