目录
背景
项目架构
核心流程1——执行器自动注册
核心流程2——调度任务
特性——分片广播
背景
为什么需要任务调度平台?
单机定时任务
Java中传统的定时任务实现方案，比如JDK 1.3 提供的 Timer、JDK 1.5 提供的 ScheduledExecutorService、Spring 3.0 提供的Spring Task
分布式定时任务
但如果一个系统为分布式部署，由多台主机组成，在某一时间只需要由一台主机运行定时任务，就需要一个分布式的调度框架来实现。
开源任务调度框架 Quartz 实现了这个功能。
但 Quartz 也存在一些问题：不支持集群、不支持统计、没有管理平台、没有失败报警、没有监控等等。
因此，xxl-job 应运而生：xxl-job 是一个开源的轻量级分布式任务调度平台，其核心设计目标是开发迅速、学习简单、轻量级、易扩展、开箱即用，其中“XXL”是主要作者，大众点评许雪里名字的缩写。
整体来说，xxl-job 就是 quartz 的一个增强版，其弥补了quartz不支持并行调度，不支持失败处理策略和动态分片的策略等诸多不足，同时其有管理界面，开箱即用，操作简易，上手快，与SpringBoot 有非常好的集成.
项目架构
调度中心（服务端）
- 管理调度信息，按照调度配置发出调度请求，自身不承担业务代码
- 支持可视化界面，可以在调度中心对任务进行新增，更新，删除，会实时生效
- 支持监控调度结果，查看执行日志，查看调度任务统计报表，任务失败告警等等。
执行器（客户端）
- 执行器启动后需要注册到调度中心，接收调度中心的发出的执行请求，终止请求，日志请求等等。
核心流程1——执行器自动注册
注册，即让调度中心保存 实现了某个执行器的所有主机ip，以便之后发送调度请求时使用。
-
服务端（调度中心）先启动
-
客户端启动，配置如下信息
客户端运行后，启动内置 netty 程序 （ xxl.job.executor.ip + xxl.job.executor.port），通过 http 请求服务端的 register 接口。
请求地址：xxl.job.admin.address
请求参数：xxl.job.executor.ip + xxl.job.executor.port、xxl.job.executor.appname 执行器名
调度中心接受到 http 请求后，存储客户端的 ip 列表到 db，xxl_job_group.
此时再刷新页面，将看到执行器以自动注册。
同样，客户端退出时，通过 http 请求服务端的 registerRemove 接口：删除 db 中客户端的 ip。
核心流程2——调度任务
找到需要执行的主机
后台管理页面中提供了配置主机调度的策略：
如随机策略的实现方式：
找到需要执行的
当调度中心也是集群分布时，为了避免同一批 job 被不同的主机同时筛选执行，需要加分布式锁控制。
🔐数据库锁
mysql 悲观锁：使用 select ... for update 语句 + 事务 实现
在进行事务操作时，通过“for update”语句，MySQL 会对查询结果集中每行数据都添加排他锁，其他线程对该记录的更新与删除操作都会阻塞
set autocommit = 0; -- 关闭数据库的自动提交
begin;
select * from goods where id = 1 for update; -- 加锁，其他线程的 select 请求将在此处被阻塞
update goods set stock = stock - 1 where id = 1;
commit; -- 释放锁任务调度
特性——分片广播
📍 作业分片适用哪些场景？
-
分片任务场景：10个执行器的集群来处理10w条数据，每台机器只需要处理1w条数据，耗时降低10倍；
-
广播任务场景：广播执行器同时运行shell脚本、广播集群节点进行缓存更新等。
分片广播策略：将集群中的执行器标上序号：0，1，2，3…，每次调度会向集群中所有执行器发送调度请求，请求中携带分片参数。
两个参数：
-
index ，当前主机在调度中心的注册序号
-
total，此任务组一共注册的主机数
每个执行器收到调度请求根据分片参数自行决定是否执行任务。每个执行器从数据表取任务时可以让任务id 模上 分片总数，如果等于分片序号则执行此任务。
如执行器实例那么分片总数为2，序号为0、1，从任务1开始，如下：
-
1 % 2 = 1 执行器2执行
-
2 % 2 = 0 执行器1执行
-
3 % 2 = 1 执行器2执行
-
以此类推
