快速入门XXL-JOB搞定分布式调度

小T同学在面试的时候，面试官出了这样一个场景题：2017年我们系统是单机部署的，那时用户量不大，单体应用能满足当前业务需求。同时系统中有大量的定时任务（扣款、计算逾期、结算）。2018年初由于业务扩张用户量暴增，为了给用户更好的用户体验，系统采用集群部署，如下图所示：

系统集群部署后，第二天收到业务部门的投诉工单，工单反馈有用户被重复扣款多次，经过定位发现扣款服务集群部署的每个节点的定时都在00:00 分执行触发了一次扣款，而在实际业务中这种问题发生是不被允许的。请问该如何解决呢？

二、为什么会产生分布式调度问题
阶段1、在一个单机的系统，任务并不多的情况下，利用Linux自带的定时器或者系统框架提供的定时任务，实现好任务执行器，配置好任务触发的时间和频率，然后每天等待它自动触发，数据生成，任务搞定，似乎调度也没那么困难

阶段2、伴随着网站的发展，你发现任务处理的越来越慢，甚至偶尔会有任务超时的情况，原因是每天用户产生的数据量越来越大，每次任务捞起的数量已经超载，依次执行完每个任务，可能已是最初执行时间的几倍，但通过一系列的参数调优，串行变并行，任务运行的很平稳，暂时渡过难关。

阶段3、然而当任务变的规模更大，比如十倍于当前，一台机器已经不能处理所有的任务，这时候需要增加更多的机器，将任务分配到不同的机器上，于是便有了所谓的分布式调度的问题。

核心诉求：不管我们在软件从单机部署演进至集群部署，同⼀个定时任务程序部署多份，但同一个时刻有且仅有⼀个定时任务在执行。

三、如何解决分布式调度问题
我们遇到的问题，行业都有前辈想到了，不需要我们重复造轮子，我们需要针对面场景和问题使用行业中成熟稳定的技术解决方案即可。

现在分布式下任务调度有很多解决方案，可以基于Quartz开发任务管理平台，也可以使用开源的任务调度平台，行业常用成熟调度框架如下：

TBSchedule

TBSchedule可以将调度作业从业务系统中分离出来,降低或者是消除和业务系统的耦合度,进行高效异步任务处理。在互联网和电商领域TBSchedule的使用非常广泛,目前被应用于阿里巴巴、淘宝、支付宝、京东、聚美、汽车之家、国美等很多互联网企业的流程调度系统

elastic-job

ElasticJob 是面向互联网生态和海量任务的分布式调度解决方案，由两个相互独立的子项目 ElasticJob-Lite 和 ElasticJob-Cloud 组成。它通过弹性调度、资源管控、以及作业治理的功能，打造一个适用于互联网场景的分布式调度解决方案，并通过开放的架构设计，提供多元化的作业生态。它的各个产品使用统一的作业 API，开发者仅需一次开发，即可随意部署。
XXL-JOB

XXL-JOB是一个轻量级分布式任务调度平台,其核心设计目标是开发迅速、学习简单、轻量级、易扩展。现已开放源代码并接入多家公司线上产品线,开箱即用
本篇文章我们挑选XXL-JOB讲解、选它的原因是因为它容易上手，学习简单，开箱即用，并且目前使用的公司非常多。

四、XXL-JOB 总体设计
1、框架架构图

2、框架设计思想

1、将调度行为抽象形成“调度中心”公共平台，而平台自身并不承担业务逻辑，“调度中心”负责发起调度请求。

2、将任务抽象成分散的JobHandler，交由“执行器”统一管理，“执行器”负责接收调度请求并执行对应的JobHandler中业务逻辑。因此，“调度”和“任务”两部分可以相互解耦，提高系统整体稳定性和扩展性；

3、框架系统组成

调度模块（调度中心） 负责管理调度信息，按照调度配置发出调度请求，自身不承担业务代码。
执行模块（执行器） 负责接收调度请求并执行任务逻辑。任务模块专注于任务的执行等操作，开发和维护更加简单和高效；接收“调度中心”的执行请求、终止请求和日志请求等。
4、框架功能特性

1、简单：支持通过Web页面对任务进行CRUD操作，操作简单，一分钟上手；
2、动态：支持动态修改任务状态、启动/停止任务，以及终止运行中任务，即时生效；
3、调度中心HA（中心式）：调度采用中心式设计，“调度中心”自研调度组件并支持集群部署，可保证调度中心HA；
4、执行器HA（分布式）：任务分布式执行，任务”执行器”支持集群部署，可保证任务执行HA；
5、注册中心: 执行器会周期性自动注册任务, 调度中心将会自动发现注册的任务并触发执行。同时，也支持手动录入执行器地址；
6、弹性扩容缩容：一旦有新执行器机器上线或者下线，下次调度时将会重新分配任务；
7、触发策略：提供丰富的任务触发策略，包括：Cron触发、固定间隔触发、固定延时触发、API（事件）触发、人工触发、父子任务触发；
8、调度过期策略：调度中心错过调度时间的补偿处理策略，包括：忽略、立即补偿触发一次等；
9、阻塞处理策略：调度过于密集执行器来不及处理时的处理策略，策略包括：单机串行（默认）、丢弃后续调度、覆盖之前调度；
10、任务超时控制：支持自定义任务超时时间，任务运行超时将会主动中断任务；
11、任务失败重试：支持自定义任务失败重试次数，当任务失败时将会按照预设的失败重试次数主动进行重试；其中分片任务支持分片粒度的失败重试；
12、任务失败告警；默认提供邮件方式失败告警，同时预留扩展接口，可方便的扩展短信、钉钉等告警方式；
13、路由策略：执行器集群部署时提供丰富的路由策略，包括：第一个、最后一个、轮询、随机、一致性HASH、最不经常使用、最近最久未使用、故障转移、忙碌转移等；
14、分片广播任务：执行器集群部署时，任务路由策略选择”分片广播”情况下，一次任务调度将会广播触发集群中所有执行器执行一次任务，可根据分片参数开发分片任务；
15、动态分片：分片广播任务以执行器为维度进行分片，支持动态扩容执行器集群从而动态增加分片数量，协同进行业务处理；在进行大数据量业务操作时可显著提升任务处理能力和速度。
16、故障转移：任务路由策略选择”故障转移”情况下，如果执行器集群中某一台机器故障，将会自动Failover切换到一台正常的执行器发送调度请求。
17、任务进度监控：支持实时监控任务进度；
18、Rolling实时日志：支持在线查看调度结果，并且支持以Rolling方式实时查看执行器输出的完整的执行日志；
19、GLUE：提供Web IDE，支持在线开发任务逻辑代码，动态发布，实时编译生效，省略部署上线的过程。支持30个版本的历史版本回溯。
20、脚本任务：支持以GLUE模式开发和运行脚本任务，包括Shell、Python、NodeJS、PHP、PowerShell等类型脚本;
21、命令行任务：原生提供通用命令行任务Handler（Bean任务，”CommandJobHandler”）；业务方只需要提供命令行即可；
22、任务依赖：支持配置子任务依赖，当父任务执行结束且执行成功后将会主动触发一次子任务的执行, 多个子任务用逗号分隔；
23、一致性：“调度中心”通过DB锁保证集群分布式调度的一致性, 一次任务调度只会触发一次执行；
24、自定义任务参数：支持在线配置调度任务入参，即时生效；
25、调度线程池：调度系统多线程触发调度运行，确保调度精确执行，不被堵塞；
26、数据加密：调度中心和执行器之间的通讯进行数据加密，提升调度信息安全性；
27、邮件报警：任务失败时支持邮件报警，支持配置多邮件地址群发报警邮件；
28、推送maven中央仓库: 将会把最新稳定版推送到maven中央仓库, 方便用户接入和使用;
29、运行报表：支持实时查看运行数据，如任务数量、调度次数、执行器数量等；以及调度报表，如调度日期分布图，调度成功分布图等；
30、全异步：任务调度流程全异步化设计实现，如异步调度、异步运行、异步回调等，有效对密集调度进行流量削峰，理论上支持任意时长任务的运行；
31、跨语言：调度中心与执行器提供语言无关的 RESTful API 服务，第三方任意语言可据此对接调度中心或者实现执行器。除此之外，还提供了 “多任务模式”和“httpJobHandler”等其他跨语言方案；
32、国际化：调度中心支持国际化设置，提供中文、英文两种可选语言，默认为中文；
33、容器化：提供官方docker镜像，并实时更新推送dockerhub，进一步实现产品开箱即用；
34、线程池隔离：调度线程池进行隔离拆分，慢任务自动降级进入”Slow”线程池，避免耗尽调度线程，提高系统稳定性；
35、用户管理：支持在线管理系统用户，存在管理员、普通用户两种角色；
36、权限控制：执行器维度进行权限控制，管理员拥有全量权限，普通用户需要分配执行器权限后才允许相关操作；
五、XXL-JOB 快速入门
————————————————
版权声明：本文为CSDN博主「许友运」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：blog.csdn.net/weixin_37854829/arti...

本作品采用《CC 协议》，转载必须注明作者和本文链接