先简单介绍下分布式定时任务调度框架的使用场景和功能和架构，然后再介绍世面上常见的产品
我们在大型的复杂的系统下，会有大量的跑批，定时任务的功能，如果在独立的子项目中单独去处理这些任务，随着业务的复杂度的提高，大量的任务将很难进行统一的管理，出现bug以后问题也很难排查，最后将成为一种灾难。所以我们引入了分布式定时任务调度框架，统一管理这些定时任务和跑批的功能，出现问题也容易统一管理
1. 分布式定时任务功能
1.1 定时任务的执行、任务管理、执行日志管理
1.2 定时任务架构的高可用。集群、分片、执行失败任务的处理
1.3 一些扩展功能:可视化的运维，多语言支持、任务编排等
2. 调度中心的整体架构
一个分布式定时任务框架主要分为下面三个模块
2.1 调度中心: 负责接收并分配任务，并按照置顶的配置规则执行
2.2 任务执行: 处理实际业务处理并执行，执行完成以后反馈给调度中心
2.3 监控中心: 主要负责节点管理，任务队列管理，监控管理等。
常见的分布式调度框架:xxljob
xxl-job是我极力推荐的框架，在我待过的几家中小型的互联网公司基本上都选用该框架。xxl-job开放源码，简单高效，中小企业用的很多。
1.xxl-job经过持续的迭代，修复了很多bug。2.0开始引入新特性，耦合性降低
2.搭建起来也非常简单，开箱即用。
3.源码开放
4.源码也有很多值得学习的地方，虽然刚发布的时候会有很多资深的程序员诟病，但经过多年的发展维护，已经非常稳定。代码非常朴实，没有那些花里胡哨的花样
xxl-job架构如下图
调度中心: 用于发布我们需要的执行任务，并且可以控制任务的添加、删除、启动和停止，以及维护日志。并且可以在操作界面进行设置。
执行器: 执行具体业务端,调度中心根据注册的执行器，按照算法分配任务执行。每一个执行器有唯一的appname，与调度中心管理的执行器名称一致，调度中心才分配任务给执行器
任务: 设置执行策略、分片机制、任务、执行器等信息。执行器管理中的appname找到执行器的appname,这样任务就会分配给对应的执行器。
xxl-job的调度原理:
1.调度中心通过http协议请求执行器中的服务，默认的端口是9999
2.执行器执行业务逻辑代码
3.执行器执行完成业务代码后回调调度中心的服务，调度中心开放了一套针对执行器材的API
xxl-job的分片原理
当执行器以集群方式部署的情况下,调度任务的策略选择"分片广播"的情况下，一次调度任务会以广播的形势触发集群中所有的执行器，同时传递分片参数，可以根据分片参数开发分片任务。
xxl-job的架构虽然简单但是用起来是真的爽，没有那一套高大上的架构设计，但是就是好用
常见的分布式调度架构:elastic-job
elastic-job分为两个独立的大块。一个是lite-core(核心去中心化的调度),一个是cloud(监控平台).
schedule: 会选取一个leader，作为分配执行任务的(包括分片)的机器。
simple: 实现simplejob接口，该接口提供单一的方法覆盖，该方法定时执行并提供了弹性扩容和分片的功能
dataflow: dataflow类型用于处理数据流，需实现DataflowJob接口。该接口提供2个方法可供覆盖，分别用于抓取(fetchData)和处理(processData)数据
script: script类型作业意为脚本类型作业，支持shell，python，perl等所有类型脚本。只需通过控制台或代码配置scriptCommandLine即可，无需编码。执行脚本路径可包含参数，参数传递完毕后，作业框架会自动追加最后一个参数为作业运行时信息。
调度原理
elastic-job的分布式锁
通过zookeeper做的分布式锁，先选取leader再做分配工作
常见的分布式调度框架:Schedulerx2.0
分布式任务调度SchedulerX是阿里巴巴自研的基于Akka架构的分布式任务调度平台，兼容开源XXL-JOB、ElasticJob，支持Cron定时、一次性任务、任务编排、分布式执行批量任务等功能，具备高可用、可视化、可运维、低延时等能力。如下图所示；
常见分布式调度框架:quartz
整体架构图如下:
常见的分布式调度框架:LTS
使用容器化的技术，定时启动执行器执行任务。
我们使用图表方式对以上几个框架做个总结
一般情况下中小型的业务的首选就是xxl-job。