xxl-job工作中比较少用的特性（分片任务，父子任务，GLUE模式）

一般情况下我们开发一个定时任务的时候，就从隔壁的定时任务copy一下，加一些必要的注解，然后再到调度中心配置一下，也没怎么去关注其他的功能。

最近无聊看了一遍xxl-job的文档，发现一些自己没怎么去关注过的特性，可能以后工作中可以用起来，先记录一下。

一、分片广播

int shardIndex = XxlJobHelper.getShardIndex(); //分片序号

int shardTotal = XxlJobHelper.getShardTotal(); //总分片数

这两个值是我们可以直接获取到的，只要依赖了xxl-job的包

分片：我们可以理解成总的任务节点数，一般微服务我们都是部署在集群里边的，一个服务可能有好几个节点，那么分片总数就是总节点数，分片序号也可以理解成执行定时任务的节点序号

有了这两个值，我们可以将我们的任务分解成多个，分布式去执行，这样效率就会快很多。

比如说，我们的定时任务需要对数据库里的数据做处理，服务节点有3个，那么我们可以把数据分成三份去处理，比如 数据id/shardTotal == shardIndex ，判断是否由当前节点去处理，如何分解任务到多个节点去执行我们可以自己根据具体的业务去决定。

另外也可以执行广播任务，一般情况下我们都是希望任务在一个节点执行就行，但我们选择分片广播，如果我们不对任务进行分解，那么每个节点丢会执行一样的任务，适用的场景比如广播集群节点进行缓存更新等

注：这时候的路由策略我们需要选择“SHARDING_BROADCAST(分片广播)”

二、父子任务

有时候我们的定时任务执行是有先后顺序的，某个定时任务依赖另一个定时任务，我们可能会选择把需要后执行的任务执行时间设置到晚于依赖的定时任务，比如晚5分钟，半小时执行这样子，但这样如果前一个任务突然故障或者说执行了很久，导致还没执行完依赖的任务就开始执行了，就会造成一些数据混乱或者说异常。

因此我们在配置任务的时候可以配置子任务的id，当父任务执行结束且执行成功后将会主动触发一次子任务的执行, 多个子任务用逗号分隔；

三、GLUE模式

大部分情况我们都是选择Bean模式，将定时任务作为一个类写在服务里面，服务启动的时候再自动注册到调度中心。但是GLUE模式源码是维护在调度中心的，我们可以直接在页面编辑源码，而且支持多种语言，比如java、shell、python等，还有版本回溯功能，这样当我们要开发一些和业务关系不大的定时任务的时候可以直接在平台上开发，在平台上维护。