分布式任务经历
在这说说之间碰到的一些问题，项目是由分布式dubbo组件开发，每个单独应用模块都多少带有定时任务的需求。
一直想做一个公共的抽离业务的任务调度中心，也是缺少技术论证环节，遇到需求直接采用一些临时解决方案，其中不免遇到好多坑，好多BUG，有时将就，有时又困扰。
经历1：第一次遇到相关问题就是多节点部署，定时任务重复问题。
将就的解决方案：任务内容是根据时间判断状态，重复执行不会出现结果不一致的情况，没做处理，浪费一些性能。
竞争的解决方案：采用锁的机制，利用redis缓存做排他锁，多节点资源竞争，竞争到的节点执行任务，实际上多节点只有一个节点执行任务，执行效率低，无法通过横向扩展。
轮子的解决方案：在针对问题寻找一些方案时，有同事用过elastic-job，在部分项目上采用elastic-job方案解决。使用简单的配置方式，不支持动态任务调度，也不支持监控等功能，没有做过深的应用。
经历2：遇到动态任务调度的需求，要求可按周期，或定期触发定时任务执行业务方法。
临时的解决方案：每当生成一次任务请求，将其周期，参数等存入数据库，由一个定时任务业务：每分钟查询符合执行周期的任务记录，并将任务信息推送至消息队列，由其他消费者通过消费消息，达到业务定时执行的需求。无法部署多节点，任务与业务耦合，每当需要支持新的业务需重新部署任务中心。消息队列无法精准控制任务执行时间，有一定的延迟。
一些想法
通过多个不同业务间的定时任务开发过程中发现，急需一个任务调度中心系统来解决这些问题，于是大胆的想了几种办法，必须抽离业务，只做任务调度，可以分布式集群部署，对任务监控，日志，动态启停，修改任务周期，自动检索可定时执行业务。
任务调度，可以分布式集群部署，对任务动监控，日志，动态启停，修改任务周期，这些在看了Quartz框架后发现都可以完成。
于是就想如何解决抽离业务，自动检索可定时执行业务。项目用的是dubbo框架，service是支持多节点负载均衡的，是否可以采用api对应业务，由任务调度中心按周期执行api的调用来激活业务方法。或者有没有办法在dubbo的注册中心中自动扫描到支持任务调度的业务方法，对这种业务进行任务管理。带着这些问题，我开始寻找合适的解决方案，目前找到了一个方向，并做了一些简单的技术验证，发现这个方案还是可行的，特此写篇文章做下记录，xxl-job任务调度框架，下面对选型做下介绍，并且在后面几篇文章中对xxl-job进行详细的demo案例，以及最终如何解决我项目中的需求做下详细的分享。
为何选用 xxl-job
最近项目上一直有分布式定时任务的需求，也是一边尝试着用自己的思路解决项目中的一些定时任务问题，一边寻找着更合适的方案，项目周期紧张，很难空出时间来做一些技术论证，选用xxl-job之前也是对quartz，elastic-job,spring-task做过一些了解和尝试。最终觉得还是xxl-job在多个方面更适合。
首先对比一下上述几个定时任务框架的特征：
spring-task：
优点：原生于spring，不需要其他依赖和配置，直接使用注解即可启用，使用简单。
缺点：不支持分布式，集群，功能单一，无监控及管理。
quartz：
优点：强大的任务调度框架，支持分布式，集群，任务可动态管理，功能丰富。
缺点：只提供监控、日志、调度的相关API操作，需要针对API二次开发。不支持任务失败重试。
elastic-job：
优点：基于quartz框架开发，脱离mysql管理，采用zookeeper，提供任务调度平台，支持分片。
缺点：（可能不算缺点）文档不完善，案例不清晰，配置复杂，我是没看懂。
xxl-job：
优点：基于quartz框架开发，提供任务调度平台，支持动态插入代码实现任务（多种语言，java，python等）。
选用xxl-job，是因为实现较简单，功能满足，节省时间。（最缺的就是时间）
xxl-job 简介
XXL-JOB是一个轻量级分布式任务调度平台，其核心设计目标是开发迅速、学习简单、轻量级、易扩展。现已开放源代码并接入多家公司线上产品线，开箱即用。
xxl-job 特性
- 1、简单：支持通过Web页面对任务进行CRUD操作，操作简单，一分钟上手；
- 2、动态：支持动态修改任务状态、启动/停止任务，以及终止运行中任务，即时生效；
- 3、调度中心HA（中心式）：调度采用中心式设计，“调度中心”自研调度组件并支持集群部署，可保证调度中心HA；
- 4、执行器HA（分布式）：任务分布式执行，任务”执行器”支持集群部署，可保证任务执行HA；
- 5、注册中心: 执行器会周期性自动注册任务, 调度中心将会自动发现注册的任务并触发执行。同时，也支持手动录入执行器地址；
- 6、弹性扩容缩容：一旦有新执行器机器上线或者下线，下次调度时将会重新分配任务；
- 7、路由策略：执行器集群部署时提供丰富的路由策略，包括：第一个、最后一个、轮询、随机、一致性HASH、最不经常使用、最近最久未使用、故障转移、忙碌转移等；
- 8、故障转移：任务路由策略选择”故障转移”情况下，如果执行器集群中某一台机器故障，将会自动Failover切换到一台正常的执行器发送调度请求。
- 9、阻塞处理策略：调度过于密集执行器来不及处理时的处理策略，策略包括：单机串行（默认）、丢弃后续调度、覆盖之前调度；
- 10、任务超时控制：支持自定义任务超时时间，任务运行超时将会主动中断任务；
- 11、任务失败重试：支持自定义任务失败重试次数，当任务失败时将会按照预设的失败重试次数主动进行重试；其中分片任务支持分片粒度的失败重试；
- 12、任务失败告警；默认提供邮件方式失败告警，同时预留扩展接口，可方便的扩展短信、钉钉等告警方式；
- 13、分片广播任务：执行器集群部署时，任务路由策略选择”分片广播”情况下，一次任务调度将会广播触发集群中所有执行器执行一次任务，可根据分片参数开发分片任务；
- 14、动态分片：分片广播任务以执行器为维度进行分片，支持动态扩容执行器集群从而动态增加分片数量，协同进行业务处理；在进行大数据量业务操作时可显著提升任务处理能力和速度。
- 15、事件触发：除了”Cron方式”和”任务依赖方式”触发任务执行之外，支持基于事件的触发任务方式。调度中心提供触发任务单次执行的API服务，可根据业务事件灵活触发。
- 16、任务进度监控：支持实时监控任务进度；
- 17、Rolling实时日志：支持在线查看调度结果，并且支持以Rolling方式实时查看执行器输出的完整的执行日志；
- 18、GLUE：提供Web IDE，支持在线开发任务逻辑代码，动态发布，实时编译生效，省略部署上线的过程。支持30个版本的历史版本回溯。
- 19、脚本任务：支持以GLUE模式开发和运行脚本任务，包括Shell、Python、NodeJS、PHP、PowerShell等类型脚本;
- 20、命令行任务：原生提供通用命令行任务Handler（Bean任务，”CommandJobHandler”）；业务方只需要提供命令行即可；
- 21、任务依赖：支持配置子任务依赖，当父任务执行结束且执行成功后将会主动触发一次子任务的执行, 多个子任务用逗号分隔；
- 22、一致性：“调度中心”通过DB锁保证集群分布式调度的一致性, 一次任务调度只会触发一次执行；
- 23、自定义任务参数：支持在线配置调度任务入参，即时生效；
- 24、调度线程池：调度系统多线程触发调度运行，确保调度精确执行，不被堵塞；
- 25、数据加密：调度中心和执行器之间的通讯进行数据加密，提升调度信息安全性；
- 26、邮件报警：任务失败时支持邮件报警，支持配置多邮件地址群发报警邮件；
- 27、推送maven中央仓库: 将会把最新稳定版推送到maven中央仓库, 方便用户接入和使用;
- 28、运行报表：支持实时查看运行数据，如任务数量、调度次数、执行器数量等；以及调度报表，如调度日期分布图，调度成功分布图等；
- 29、全异步：任务调度流程全异步化设计实现，如异步调度、异步运行、异步回调等，有效对密集调度进行流量削峰，理论上支持任意时长任务的运行；
- 30、跨平台：原生提供通用HTTP任务Handler（Bean任务，”HttpJobHandler”）；业务方只需要提供HTTP链接即可，不限制语言、平台；
- 31、国际化：调度中心支持国际化设置，提供中文、英文两种可选语言，默认为中文；
- 32、容器化：提供官方docker镜像，并实时更新推送dockerhub，进一步实现产品开箱即用；
- 33、线程池隔离：调度线程池进行隔离拆分，慢任务自动降级进入”Slow”线程池，避免耗尽调度线程，提高系统稳定性；；
- 34、用户管理：支持在线管理系统用户，存在管理员、普通用户两种角色；
- 35、权限控制：执行器维度进行权限控制，管理员拥有全量权限，普通用户需要分配执行器权限后才允许相关操作；
