鉴于平台定时任务执行缺陷：
- 占用线程资源严重：严重依赖于大量的线程池（一般）
- 执行延时操作，直接选用delay线程方案，会导致大量线程阻塞（严重）
- 当需扫描的数据量很大时，每秒执行不完全，会导致自动化不执行或者重复执行，可靠性低（一般）
- 控制中心和执行引擎没有完全分离出来，代码逻辑复杂，难以定位问题（一般） 需要选择一款优秀的分布式任务调度组件。
目前国内常见的分布式定时框架：
Elastic-Job
ddframe中dd-job的作业模块中分离出来的分布式弹性作业框架。去掉了和dd-job中的监控和ddframe接入规范部分。该项目基于成熟的开源产品Quartz和Zookeeper及其客户端Curator进行二次开发。
- 优点：比较成熟，重量级的分布式定时任务框架 ，并发量高
- 缺点：依赖 Zookeeper及其它组件，改造困难，上手难度高，且部分特性不支持，目前github已没有人员维护
xxl-job
XXL-JOB是一个轻量级分布式任务调度平台，其核心设计目标是开发迅速、学习简单、轻量级、易扩展。现已开放源代码并接入多家公司线上产品线，开箱即用。
- 优点：开发迅速、学习简单、轻量级、易扩展，目前用户比Elastic-Job略高，文档全面，且一直在更新版本，有问题可以联系开源作者
- 缺点：并发量没有Elastic-Job高。但最新的稳定版本已支持调度全异步处理
spring单节点@Scheduled调度组件
- 优点：支持spring，使用简单。
- 缺点：
1 节点不能水平扩展 , 多个节点之间任务是无感知的 , 会造成多余的资源浪费 , 一些调度任务多节点并行执行还可能导致资源争用造成一些异常问题
2 管理方式不灵活 , 一些特定场景下不能及时主动进行触发或者开关
3 调度任务的监控功能需要自己实现 , 调度体系大了 , 难以做到比较全面的管理、监控 , 并且此功能需要投入额外的开发成本
quartz，TBSchedule等
不支持分片或者无人维护无文档，不考虑
引入定时框架后解决的问题
1.由于开源定时任务框架经历了很多的场景考验，对于线程池分配方便会把控较好，不存在滥用情况。可以完全取消掉ifttt-trigger，ifttt-handler中的常驻进程，避免产生线程资源耗尽等状况
2.延时操作目前考虑将一个含delay定时任务拆分成多个任务，解决线程阻塞问题。
3.去除扫描操作，由控制中心统一调度，由被动的轮询改为主动的中心调度，可靠性百分百。
4.开源框架调度中心和执行器是完全隔离的，我们只需要复写例如执行器等，不用考虑任务调度过程。简化定时任务执行逻辑。
3、xxljob介绍
xxl-job官方介绍([http://www.xuxueli.com/xxl-job/#]
概述
XXL-JOB是一个轻量级分布式任务调度平台，其核心设计目标是开发迅速、学习简单、轻量级、易扩展。现已开放源代码并接入多家公司线上产品线，开箱即用。
-
示例图:
image.png
特性
简单：支持通过Web页面对任务进行CRUD操作，操作简单，一分钟上手；
动态：支持动态修改任务状态、启动/停止任务，以及终止运行中任务，即时生效；
调度中心HA（中心式）：调度采用中心式设计，“调度中心”基于集群Quartz实现并支持集群部署，可保证调度中心HA；
执行器HA（分布式）：任务分布式执行，任务"执行器"支持集群部署，可保证任务执行HA；
注册中心: 执行器会周期性自动注册任务, 调度中心将会自动发现注册的任务并触发执行。同时，也支持手动录入执行器地址；
弹性扩容缩容：一旦有新执行器机器上线或者下线，下次调度时将会重新分配任务；
路由策略：执行器集群部署时提供丰富的路由策略，包括：第一个、最后一个、轮询、随机、一致性HASH、最不经常使用、最近最久未使用、故障转移、忙碌转移等；
故障转移：任务路由策略选择"故障转移"情况下，如果执行器集群中某一台机器故障，将会自动Failover切换到一台正常的执行器发送调度请求。
阻塞处理策略：调度过于密集执行器来不及处理时的处理策略，策略包括：单机串行（默认）、丢弃后续调度、覆盖之前调度；
任务超时控制：支持自定义任务超时时间，任务运行超时将会主动中断任务；
任务失败重试：支持自定义任务失败重试次数，当任务失败时将会按照预设的失败重试次数主动进行重试；其中分片任务支持分片粒度的失败重试；
任务失败告警；默认提供邮件方式失败告警，同时预留扩展接口，可方便的扩展短信、钉钉等告警方式；
分片广播任务：执行器集群部署时，任务路由策略选择"分片广播"情况下，一次任务调度将会广播触发集群中所有执行器执行一次任务，可根据分片参数开发分片任务；
动态分片：分片广播任务以执行器为维度进行分片，支持动态扩容执行器集群从而动态增加分片数量，协同进行业务处理；在进行大数据量业务操作时可显著提升任务处理能力和速度。
事件触发：除了"Cron方式"和"任务依赖方式"触发任务执行之外，支持基于事件的触发任务方式。调度中心提供触发任务单次执行的API服务，可根据业务事件灵活触发。
任务进度监控：支持实时监控任务进度；
Rolling实时日志：支持在线查看调度结果，并且支持以Rolling方式实时查看执行器输出的完整的执行日志；
GLUE：提供Web IDE，支持在线开发任务逻辑代码，动态发布，实时编译生效，省略部署上线的过程。支持30个版本的历史版本回溯。
脚本任务：支持以GLUE模式开发和运行脚本任务，包括Shell、Python、NodeJS、PHP、PowerShell等类型脚本;
命令行任务：原生提供通用命令行任务Handler（Bean任务，"CommandJobHandler"）；业务方只需要提供命令行即可；
任务依赖：支持配置子任务依赖，当父任务执行结束且执行成功后将会主动触发一次子任务的执行, 多个子任务用逗号分隔；
一致性：“调度中心”通过DB锁保证集群分布式调度的一致性, 一次任务调度只会触发一次执行；
自定义任务参数：支持在线配置调度任务入参，即时生效；
调度线程池：调度系统多线程触发调度运行，确保调度精确执行，不被堵塞；
数据加密：调度中心和执行器之间的通讯进行数据加密，提升调度信息安全性；
邮件报警：任务失败时支持邮件报警，支持配置多邮件地址群发报警邮件；
推送maven中央仓库: 将会把最新稳定版推送到maven中央仓库, 方便用户接入和使用;
运行报表：支持实时查看运行数据，如任务数量、调度次数、执行器数量等；以及调度报表，如调度日期分布图，调度成功分布图等；
全异步：任务调度流程全异步化设计实现，如异步调度、异步运行、异步回调等，有效对密集调度进行流量削峰，理论上支持任意时长任务的运行；
跨平台：原生提供通用HTTP任务Handler（Bean任务，"HttpJobHandler"）；业务方只需要提供HTTP链接即可，不限制语言、平台；
国际化：调度中心支持国际化设置，提供中文、英文两种可选语言，默认为中文；
容器化：提供官方docker镜像，并实时更新推送dockerhub，进一步实现产品开箱即用；
线程池隔离：调度线程池进行隔离拆分，慢任务自动降级进入"Slow"线程池，避免耗尽调度线程，提高系统稳定性；；
4、xlljob 使用
4.1、server服务调度端
- 部署方式:
- 访问路径: [ip]:[port]/retail_xxljob
- 默认账密: admin / 123456
4.2、client业务端
maven 依赖配置:
<!--netty模块依赖请放置在<dependencys>里最前面(第一个),避免maven使用其他低版本netty造成问题-->
<dependency>
<groupId>io.netty</groupId>
<artifactId>netty-all</artifactId>
<version>${netty.version}</version>
</dependency>
<dependency>
<groupId>com.xuxueli</groupId>
<artifactId>xxl-job-core</artifactId>
<version>${com.xuxueli.xxl-job-core}</version>
</dependency>
bean配置类
xxl 配置类:(复制即可 , 目标模块有就不需要再配置)
@Configuration
public class XxlJobConfig {
private Logger logger = LoggerFactory.getLogger(XxlJobConfig.class);
@Value("${xxl.job.admin.addresses}")
private String adminAddresses;
@Value("${xxl.job.executor.appname}")
private String appName;
@Value("${xxl.job.executor.ip}")
private String ip;
@Value("${xxl.job.executor.port}")
private int port;
@Value("${xxl.job.accessToken}")
private String accessToken;
@Value("${xxl.job.executor.logpath}")
private String logPath;
@Value("${xxl.job.executor.logretentiondays}")
private int logRetentionDays;
@Bean(initMethod = "start", destroyMethod = "destroy")
public XxlJobSpringExecutor xxlJobExecutor() {
logger.info(">>>>>>>>>>> xxl-job config init.");
XxlJobSpringExecutor xxlJobSpringExecutor = new XxlJobSpringExecutor();
xxlJobSpringExecutor.setAdminAddresses(adminAddresses);
xxlJobSpringExecutor.setAppName(appName);
xxlJobSpringExecutor.setIp(ip);
xxlJobSpringExecutor.setPort(port);
xxlJobSpringExecutor.setAccessToken(accessToken);
xxlJobSpringExecutor.setLogPath(logPath);
xxlJobSpringExecutor.setLogRetentionDays(logRetentionDays);
return xxlJobSpringExecutor;
}
}
配置文件yaml
- application.yml配置文件(只需要修改 appname、port 配置):
注: port 端口号设置请按 [新零售整体文档] -> [开发配置总汇] -> [各模块端口登记] 中的约定进行注册、使用
xxl:
job:
### 执行器通讯TOKEN [选填]：非空时启用；
accessToken: ''
executor:
### 执行器AppName [选填]：执行器心跳注册分组依据；为空则关闭自动注册
appname: lumi-retail-xxljob-pc
### 执行器IP [选填]：默认为空表示自动获取IP，多网卡时可手动设置指定IP，该IP不会绑定Host仅作为通讯实用；地址信息用于 "执行器注册" 和 "调度中心请求并触发任务"；
ip: ''
### 执行器运行日志文件存储磁盘路径 [选填] ：需要对该路径拥有读写权限；为空则使用默认路径；
logpath: ${user.home}/data/logs/xxljob
### 执行器日志保存天数 [选填] ：值大于3时生效，启用执行器Log文件定期清理功能，否则不生效；
logretentiondays: 7
### 执行器端口号 [选填]：小于等于0则自动获取；默认端口为9999，单机部署多个执行器时，注意要配置不同执行器端口；
port: 9402
- application-dev.yml配置文件(只需要修改 addresses中的ip)
注: ip 即为 server 服务调度端设置的 Ip
xxl:
job:
admin:
### 调度中心部署跟地址 [选填]：如调度中心集群部署存在多个地址则用逗号分隔。执行器将会使用该地址进行"执行器心跳注册"和"任务结果回调"；为空则关闭自动注册；
addresses: http://10.0.14.152:9400/retail_xxljob
业务定时任务类(根据业务定制)
注: 以下仅为 demo 示例
@Slf4j
//此值配置即为下图使用使用的JobHandler任务名
@JobHandler(value = "afterAlarmRelieveJob")
@Component
public class AfterAlarmRelieveJobHandler extends IJobHandler {
@Autowired
AlarmRecordService alarmRecordService;
@Override
public ReturnT<String> execute(String param) throws Exception {
log.info("售后工单预警解除任务开始...");
long start = System.currentTimeMillis();
alarmRecordService.afterAlarmRelieve();
log.info("售后工单预警解除任务完成，共耗时：" + (System.currentTimeMillis() - start) / 1000 + "s");
return SUCCESS;
}
}
4.3、调度模块管理页面配置
访问
根据需要分别启动对应环境的 xll 模块( lumi_retail_xxljob_admin )
调度管理模块访问页面: [ip]:9300/retail_xxljob
账密: admin / 123456
效果如下:
新增执行器
注: 一个模块只需配置一次即可
执行器 , 顾名思义即为执行调度任务的执行器,示例如下
appname: 即为 client业务端yaml 配置文件中对应的 appname
机器地址: 即 client 端的地址,多个以,号分隔(英文逗号)
新增调度任务
- 路由策略: 建议默认为轮询
- JobHandler: 即为上文 [client业务端] -> [业务定时任务类] 注解中@JobHandler(value = "afterAlarmRelieveJob")的value值
- cron: 相应的执行策略
- 任务描述、负责人: 填写相关描述、人员
任务管理页面开启、执行
新增完即可配置定时执行/主动执行等:
按钮解释:
[启动/停止]: 是针对 cron 是否开启/停止的开关控制 , 开启则会根据 cron 规则去操作执行相应业务逻辑
[执行]: 是否主动触发 , 立即执行此任务逻辑
注: 点击执行按钮后 , 会出现如下图示框 , 无须关注参数输入框 , 直接点保存(即执行).
- 调度任务查看/监控等:
