一、XXL-JOB任务调度平台

二、传统的定时任务存在哪些缺陷？

定时任务业务逻辑代码和非定时业务逻辑代码放在同一个jar中
耦合，其中一个出问题了容易影响到另一个
给定时任务设置开关或者分开部署

定时任务非常占用内存，一直要去判断时间

三、分布式任务调度架构设计原理

注册中心和分布式任务调度中心在同一个项目中
定时任务项目分片集群

1.定时任务和业务逻辑代码完全分开，定时任务代码肯定单独的一个项目；

原理分析：
1.定时任务的项目将自己服务器地址注册到分布式任务调度平台中；
2.我们的定时任务的规则都会在“分布式任务调度中心”触发；
3.当我们的任务调度中心触发定时任务规则时，读取“定时任务项目服务器集群地址”，
取一个定时任务地址，调度中心向定时任务发一个通知根据java反射机制执行定时任务项目。

一句话总结分布式任务调度平台的原理：
1.将我们的定时任务项目（执行器）服务ip和端口号统一注册到分布式任务调度平台中，
触发的所有的定时任务，先走分布式任务调度中心；
2. 分布式任务调度中心在获取执行器集群列表，采用负载均衡算法获取一个地址，采用rpc通知

四、如何在集群中，保证我们的定时任务只会触发一次

1.将业务逻辑和定时任务逻辑完全分开部署，只对业务逻辑实现集群，不对我们的定时任务逻辑集群；
2.对我们Jar包加上一个开关，项目启动的时候读取该开关 如果为true的情况下则加载定时任务类，否则情况下就不加载该定时任务类；
3.在数据库加上一个主键能够创建成功，则触发定时任务，否则就不触发定时任务；
4.分布式锁实，只要jar能够拿到分布式锁就能够执行定时任务，否则情况下不执行；

五、传统定时任务的实现方案

多线程形式、timetask、线程池、springboot注解形式、quartz

六、常用的任务调度框架

xxl-job/elasticjob/springalibaba cloud schedulerX

七、定时任务最大的缺陷

占用cpu资源

admin包括了注册中心和任务调度模块

八、

九、

十、

十一、

十二、

十三、

十四、

十五、

十六、

十七、

十八、

十九、

二十、

二十一、

二十二、

二十三、

二十四、

二十五、

二十六、

二十七、

二十八、

二十九、

三十、