本文收录于JavaStarter ，里面有我完整的Java系列文章，学习或面试都可以看看
 
 
本文将介绍分布式任务调度系统：xxl-job，开源地址如下：
 
码云地址：https://gitee.com/xuxueli0323/xxl-job
 
文档地址：https://www.xuxueli.com/xxl-job/
 
（一）定时任务的场景
 
在开发中，定时任务是一种十分常见的应用场景，比如每天晚上12点同步数据，又或者每隔一个小时拉取一次数据。
 
在Java中，实现定时任务的方式有很多，最简单的在线程中通过Thread.sleep睡眠线程，或者采用SpringBoot中的@Schedule注解，又或者采用定时线程池ScheduledExecutorService来实现。
 
（二）上面的定时任务会有什么问题？
 
在单机环境下，上面的这种定时任务实现方式问题主要有一个，无法进行管理，没有容错机制。
 
但是在集群环境下，如果不对代码作控制，就会导致集群的每一台机器都会执行一次定时任务。
 
常见的解决方式，我通过配置文件进行控制，只让定时任务在某一台机器上执行，如果项目比较小，就几台机器组成的集群环境，这样的方式确实可以，只不过在任务的管理上需要想办法解决。
 
如果是一个很庞大的分布式微服务系统，可能会有成千上万个定时任务，那上面的方法就不合理了。因此许多互联网公司会采用分布式任务调度系统，主要为了实现高可用、容错管理、负载均衡、管理机制等功能，我目前所在公司使用的是xxl-job作为分布式任务调度平台。
 
（三）xxl-job的使用
 
xxl-job的一大优势就是使用简单，学习成本低，xxl-job作者已经给出了很详细的使用说明，下面我们就通过源码直接来跑一下。
 
3.1 初始化调度数据库
 
git上clone的项目中保存了初始化sql脚本，位置在：
 
/xxl-job/doc/db/tables_xxl_job.sql
 
执行完毕后会在数据库中新建库以及表结构。
 
3.2 修改配置
 
修改主配置文件：
 
/xxl-job/xxl-job-admin/src/main/resources/application.properties
 
主要修改jdbc的连接信息，以及报警邮件，xxl-job支持通过邮件报警的方式。
 
 
3.3 运行项目
 
直接运行xxl-job-admin中的XxlJobAdminApplication，正常启动后访问http://localhost:8080/xxl-job-admin，输入用户名密码：admin/123456，然后就能看到任务调度中心页面了
 
 
到这里为止，xxl-job的管理平台已经搭建完成，接下来展示客户端使用xxl-job的案例。xxl-job支持多种执行方式，我这里演示Java Bean的使用。其余的可看官方提供的技术文档。
 
3.4 配置执行器
 
执行器管理页面点击新增执行器：
 
AppName: 是每个执行器集群的唯一标示AppName, 执行器会周期性以AppName为对象进行自动注册。可通过该配置自动发现注册成功的执行器, 供任务调度时使用;
名称: 执行器的名称, 因为AppName限制字母数字等组成,可读性不强, 名称为了提高执行器的可读性;
排序: 执行器的排序, 系统中需要执行器的地方,如任务新增, 将会按照该排序读取可用的执行器列表;
注册方式：调度中心获取执行器地址的方式；
    自动注册：执行器自动进行执行器注册，调度中心通过底层注册表可以动态发现执行器机器地址；
    手动录入：人工手动录入执行器的地址信息，多地址逗号分隔，供调度中心使用；
机器地址："注册方式"为"手动录入"时有效，支持人工维护执行器的地址信息；
 
我这里选择手动录入，并且自己输入执行器的地址，ip是本机ip，端口选择一个未使用过的端口。
 
 
3.5 编写客户端代码
 
接下来编写客户端的代码，在xxl开源项目中，已经有springboot的demo，我们自己写一个。
 
第一步引入依赖：
 
<dependency>
    <groupId>com.xuxueli</groupId>
    <artifactId>xxl-job-core</artifactId>
    <version>${project.parent.version}</version>
</dependency>
 
这里的version填写最新的稳定版本，因为我在xxljob的开源项目中新建了一个module进行测试，因此直接用父项目版本了。
 
第二步编写配置文件：
 
server.port=8081

xxl.job.admin.addresses=http://127.0.0.1:8080/xxl-job-admin
xxl.job.accessToken=

xxl.job.executor.appname=test-xxl-job
xxl.job.executor.address=
xxl.job.executor.ip=172.18.2.49
xxl.job.executor.port=8999
xxl.job.executor.logpath=/data/applogs/xxl-job/jobhandler
xxl.job.executor.logretentiondays=30
 
几个注意点：
 
xxl.job.admin.addresses是管理平台的地址
 
xxl.job.executor.appname是我们上面的执行器appname
 
xxl.job.executor.address不填的话就是xxl.job.executor.ip:xxl.job.executor.port
 
其他的就按照执行器配置的填。
 
第三步编写配置类
 
@Configuration
public class XxlConfig {
    private Logger logger = LoggerFactory.getLogger(XxlConfig.class);

    @Value("${xxl.job.admin.addresses}")
    private String adminAddresses;

    @Value("${xxl.job.accessToken}")
    private String accessToken;

    @Value("${xxl.job.executor.appname}")
    private String appname;

    @Value("${xxl.job.executor.address}")
    private String address;

    @Value("${xxl.job.executor.ip}")
    private String ip;

    @Value("${xxl.job.executor.port}")
    private int port;

    @Value("${xxl.job.executor.logpath}")
    private String logPath;

    @Value("${xxl.job.executor.logretentiondays}")
    private int logRetentionDays;
    @Bean
    public XxlJobSpringExecutor xxlJobExecutor() {
        logger.info(">>>>>>>>>>> xxl-job config init.");
        XxlJobSpringExecutor xxlJobSpringExecutor = new XxlJobSpringExecutor();
        xxlJobSpringExecutor.setAdminAddresses(adminAddresses);
        xxlJobSpringExecutor.setAppname(appname);
        xxlJobSpringExecutor.setAddress(address);
        xxlJobSpringExecutor.setIp(ip);
        xxlJobSpringExecutor.setPort(port);
        xxlJobSpringExecutor.setAccessToken(accessToken);
        xxlJobSpringExecutor.setLogPath(logPath);
        xxlJobSpringExecutor.setLogRetentionDays(logRetentionDays);
        return xxlJobSpringExecutor;
    }
}
 
第四步编写demo代码：
 
@Component
public class DemoJobHandler {

    @XxlJob("demoJobHandler")
    public void demoJobHandler(){
        System.out.println("执行定时任务");
        XxlJobHelper.log("执行定时任务");
    }
}
 
通过@XxlJob(“demoJobHandler”)，指定任务的名称。
 
3.5 配置任务
 
代码写好了，接下来配置具体的任务了，进管理平台的任务管理，在test执行器下新建一个任务，简单如下配置：
 
 
Cron配置了每10s执行一次，配置任务完成后启动任务，定时Job就开始工作了，通过日志可以查看是否执行成功。
 
（四）xxl-job集群下的使用
 
既然被称为分布式任务调度平台，xxl-job如何体现分布式场景下的任务调度呢？在任务配置的高级配置中，提供了多种路由策略：
 
 
我现在选择轮询，然后修改一下执行器的配置，加入两个地址：
 
http://172.18.2.49:8999,http://172.18.2.49:8998
 
同时将测试项目启动两个，两者的配置文件分别为：
 
#第一个项目
server.port=8081
xxl.job.admin.addresses=http://127.0.0.1:8080/xxl-job-admin
xxl.job.accessToken=
xxl.job.executor.appname=test-xxl-job
xxl.job.executor.address=
xxl.job.executor.ip=172.18.2.49
xxl.job.executor.port=8999
xxl.job.executor.logpath=/data/applogs/xxl-job/jobhandler
xxl.job.executor.logretentiondays=30

#第二个项目
server.port=8082
xxl.job.admin.addresses=http://127.0.0.1:8080/xxl-job-admin
xxl.job.accessToken=
xxl.job.executor.appname=test-xxl-job
xxl.job.executor.address=
xxl.job.executor.ip=172.18.2.49
xxl.job.executor.port=8998
xxl.job.executor.logpath=/data/applogs/xxl-job/jobhandler
xxl.job.executor.logretentiondays=30
 
再启动任务后，会发现定时任务会在两个项目中轮询的执行：
 

 
 
除了轮询之外，像故障转移、忙碌转移策略可以实现容错，一致性哈希可以保证同一个任务只在一台机器上执行。
 
（五）总结
 
目前分布式任务调度的开源框架有很多，xxl-job是最常用的，功能确实很完善，同时完全开源。也难怪大量互联网企业在使用它。我是鱼仔，我们下期再见！

 
任务调度是后端重要的组成部分，用于的场景非常广泛，比如生产系统中跑一些定时任务，涉及到上千台机器管理就很困难；Web应用中用户触发的操作比较耗时，这部分可以放到异步任务中处理；离线数据处理多个任务，并且任务间直接有依赖关系...
 
分布式任务调度通常有以下几类实现方式，一类是基于机器调度的方式，如CT(Contab Task)，百度内部是这种方式，定时执行指定机器上的具体指令，通常需要先把任务脚本发布到具体机器，提供给机器调度(worker)；第二类如Gearman/Celery，Client将任务发送给Job Server，Server根据后端负载情况，将任务投递到Worker；还有一类是编程框架层面提供的Schedule，功能相对局限，比如只能当前这台机器执行，当前机器挂了，任务也就挂了。
 
目前自己工作内容涉及到不少离线数据计算，这类任务是基于Python实现，公司内部现用调度系统对非Java支持不完善，而离线任务较多，其中任务间还有依赖关系，使用系统自带的Contab，不管从任务稳定性，还是任务间依赖关系的处理都不完善，最终选择部署Celery集群作为离线任务调度框架。Celery是一个专注于实时处理的任务队列，同时也支持任务调度，配套的任务监控也很完善，可以使用Flower作为可视化监控工具。
 
1、Celery任务架构
 

 
Celery有三个核心组件：Celery client: 用于发布后台作业，当与应用一起工作的时候，客户端与 Flask 应用一起运行。
 
Celery workers: 运行后台作业的进程。Celery 支持本地和远程的 workers，可以在本地服务器上启动一个单独的 worker，也可以在远程服务器上启动worker。
 
Broker: 消息代理，客户端通过消息队列和 workers 进行通信，Celery 支持多种方式来实现这些队列。最常用的代理就是 RabbitMQ 和 Redis。
 
2、编写任务实例
 
(1)安装celerypip install celery
 
(2)celery_con.pyfrom celery import Celery
 
import time
 
celery = Celery('tasks', broker='redis://localhost:6379/0')
 
(3)task.pyfrom celery_con import app
 
@app.task
 
def test(x, y):
 
time.sleep(5)
 
return x + y
 
@app.task
 
def scan(x,y):
 
time.sleep(1)
 
return x-y
 
(4)发布任务celery -A task worker -c 2
 
(5)触发任务from task import test,scan
 
res=test.delay(2,2)
 
print res.get()
 
3、任务依赖
 
任务间通常存在依赖关系，例如后续任务依赖前一个任务的结果，或者是依赖几个任务的完成，前几个任务有可能支持并行、也有可能串行，Celery提供了signature和chain，可以保证任务按照用户构想执行。比如：from celery import chain
 
from proj.tasks import add
 
# (4 + 4) * 8
 
chain(add.s(4, 4) | add.s(8))().get()
 
64
 
上面这种示例是后续任务依赖前一步的结果，有时候不需要前一步的结果，只需要前一步任务完成(add.s(4,4) | add.si(5,6)).get
 
4、异常处理@app.task(bind=True, default_retry_delay=300, max_retries=5)
 
def my_task_A():
 
try:
 
print("doing stuff here...")
 
except SomeNetworkException as e:
 
print("maybe do some clenup here....")
 
self.retry(e)
 
一般添加 default_retry_delay 重试等待时间和 max_retries 重试次数来限定，防止任务无限重试。
 
5、任务监控
 
作为一个完善的任务监控系统，需要有对任务的监控，Flower提供了对Celery任务的监控，使用起来也特别方便，可以通过UI对查看任务详细、终止任务、重试任务。
 
flower --port=5555 --broker=redis://localhost:6379/0
 
broker指定成Celery的broker即可
 
以上是Celery的简单用法，详细的可查看Celery官方文档。

1、前言
 
上一篇文章谈了单机的定时任务解决方案，只能在单个JVM进程中使用；而我们的现在基本上是分布式场景，需要一套在分布式环境下高性能、高可用、可扩展的分布式任务调度框架；是否将之前的单机解决方案部署到分布式就可以？面临的分布式场景如何实现分布式的任务调度，如何解决单点故障问题实现高可用？接下来我们首先分析分布式任务调度框架相对单机的优势以及结合几种任务调度框架分析是如何逐步实现分布式的高可用、效率的，最后综合比较下业界比较流行的框架，在项目开发中方便选择。
 
2、Why 分布式任务调度框架
 
背景
 
1、单点故障
 
举个例子，村里只有一口井，有口井突然被污染了，村里就都没有井水喝了；分布式就是平时挖了多口井，一口井出问题照样有水喝。
 
 
 
之前我们说到单机的定时任务可能机器存在异常，如果没有分布式任务调度，那这个机器上所有定时任务只能等到这个机器恢复后才可以执行，这显然可用性就很低。
 
分布式任务调度就是在集群中多台调度、多台执行，一台调度机器或者执行机器出问题，能够立刻故障转移，不影响后续任务的执行，提高整体的可用性。
 
2、性能瓶颈
 
都知道一台机器的CPU、内存资源是有限的，像我们单机任务都直接写在业务机器上，单机任务瓶颈立现；当定时任务多，每秒执行上W个定时任务，单机是难以支撑的，而且定时任务会影响到业务系统的资源，整个系统就会非常不可靠。单机靠多线程，单机瓶颈达到后就要依靠分布式集群来水平扩展，解决资源瓶颈问题。
 
3、协同效率
 
每个定时任务调度的使用业务方都需要自己在业务系统构造一套分布式定时任务调度框架吗？这显然是低效？专业分工是必然的发展趋势，这就需要分布式的任务调度框架的出现，其他业务作为接入方，使用即可，不需要再考虑分布式调度的调度策略的高可用、异常故障恢复、控制台配置等等问题，只需要专注业务逻辑即可。
 
3、演进过程
 
什么是分布式任务调度
 
分布式任务调度，三个关键词：分布式、任务调度、配置中心。
 分布式：平台是分布式部署的，各个节点之间可以无状态和无限的水平扩展（保证可扩展）；
 
任务调度：涉及到任务状态管理、任务调度请求的发送与接收、具体任务的分配、任务的具体执行；（集群中哪些机器什么时候执行什么任务，所以又需要一个可以感知整个集群运行状态的配置中心）
 
配置中心：可以感知整个集群的状态、任务信息的注册
 
常见的分布式任务调度框架一般有以下5个部分
 1、控制台：负责调度任务的配置、任务状态、信息展示
 2、接入：将控制台的任务转化下发给调度器，并且向注册中心注册任务
 3、调度器：接收接入下发的调度任务，进行任务拆分下发，在注册中心找执行器，然后把任务下发到执行器执行，同时也注册到注册中心
 4、执行器：接收调度任务，并且上报状态给注册中心
 5、注册中心：机器、任务状态的同步、协调
 
现在林林总总的框架，大部分都是在Quartz的基础上进行改进，我们先来看看经典的Quartz怎么做的？
 
Quartz
 
Quartz是OpenSymphony开源组织在任务调度领域的一个开源项目，完全基于java实现。作为一个优秀的开源框架，Quartz具有以下特点：强大的调度功能、灵活的应用方式、分布式和集群能力，另外作为spring默认的调度框架，很容易实现与Spring集成，实现灵活可配置的调度功能。
 
Quartz框架的核心对象
 
Scheduler – 核心调度器，就是任务调度、分配的控制器
 Job – 任务，代表具体要执行的任务，是个接口，里面有默认方法，开发者需要实现该接口，并且业务逻辑写在默认的execute方法中
 JobDetail – 任务描述，描述job的静态消息，是调度器需要的数据，跟Job区分开来，主要是为了一个Job可以在多台机器并行，每个调度器new一个Job的实现类
 Trigger – 触发器，用于定义任务调度的时间规则
 
#对象之间的关系
 
这是单机Quartz最小的执行单元的关系
 
 
集群部署
 
 
上图3个节点在数据库中都有同一份Job定义，如果某一个节点失效，那么Job会在其他节点上执行。因为每个节点上的代码都是一样的，那么如何保证只有一台机器上触发呢？答案是使用了数据库锁。在quartz集群解决方案了有张scheduler_locks，采用了悲观锁的方式对triggers表进行了行加锁，以保证任务同步的正确性。
 
简单来说，quartz的分布式调度策略是以数据库为边界的一种异步策略。各个调度器都遵守一个基于数据库锁的操作规则从而保证了操作的唯一性，同时多个节点的异步运行保证了服务的可靠。（实际上是用数据库锁作为分布式锁解决同步问题实现异步运行，跟redis、zk做分布式锁时是一样的）
 
但这种策略有自己的局限性：集群特性对于高CPU使用率的任务效果特别好，但是对于大量的短任务，各个节点都会抢占数据库锁，这样就出现大量的线程等待资源。
 
因此Quartz的分布式只解决了任务高可用（减少单点故障）的问题，处理能力瓶颈会在数据库，而且没有执行层面的任务分片，无法最大化效率，只能依靠shedulex调度层面做分片，但是调度层做并行分片难以结合实际的运行资源情况做最优的分片。
 
quartz通过数据库锁的方式来保证分布式环境下定时任务调度的同步，解决了单点故障，只引入了数据库，整体的结构简单；但是在效率上，由于数据库锁带来的竞争冲突，会使得在短任务较多时的低效，并且没有在执行时对任务分片，无法充分利用集群性能，也就是说没法真正的做到水平扩展，瓶颈被数据库锁限制住了。
 
Elastic-job
 
要解决这个分布式的水平扩展、效率问题，我们知道需要引入注册中心进行协调，这里当当退出的Elastic-job就是Quartz的基础上，引入ZK做注册中心。并且在2.0版本后出现了两个相互独立的产品线：Elastic-job-lite和Elastic-job-cloud。Elastic-job-lite定位为轻量级无中心化的解决方案，使用jar包的形式提供分布式任务的协调服务，外部依赖仅依赖于zookeeper。
 
 
这款轻量级的架构做了很多的改进，这里只谈到两点，
 1、无中心调度节点
 Elastic-job-lite并无作业调度中心节点，不像我们谈到单机定时任务调度有统一的排序队列，它是基于部署作业框架的程序在到达相应时间点时各自触发调度。注册中心仅用于作业注册和监控信息存储，而主作业节点仅用于处理分片和清理的功能。
 2、实现弹性扩容
 通过zookeeper来动态给job节点分片。如果很大体量的用户需要我们在特定的时间段内计算完成，那么我们肯定是希望我们的任务可以通过集群达到水平的扩展，集群里的每个节点都处理部分的用户，不管用户的数量有多大，我们只需要增加机器就可以了。
 举个例子：比如我们希望3台机器跑job，我么将我们的任务分成3片，框架通过zk的协调，最终会让3台机器分配到0，1，2的任务片，比如server0->0、server1->1、server2->2，当server0执行时，可以只查询id%30的用户，server1可以只查询id%31的用户，server2可以只查询id%3==2的用户。
 
在以上的基础上再增加一个server3，此时，server3分不到任何的分片，没有分到任务分片的程序将不执行。如果此时server2挂了，那么server2被分到的任务分片将会分配给server3，所以server3就会代替server2执行。如果此时server3也挂了，那么框架也会自动的将server3的任务分片随机分配到server0或者server1，那么就可能成：server0->0、server1->1,2。
 
这样就没有基于数据库的锁冲突问题，也可以实现水平扩展
 
不过也是有问题的
 1、分片数是由业务代码层决定，调度执行协调时没法进一步优化，比较静态，机器扩容后其实没法直接用到扩容后的性能
 2、缺乏统一调度，每个调度任务有重复的调度开销（检测任务trigger），并且在实现复杂的dag调度时，只能把所有业务调度写在一个实现中，不够灵活。
 
阿里的定时任务框架
 
1、早期是：TBSchedule
 
也是基于Zk做注册中心
 优点：是支持集群、分布式，灵活的任务分片，并且有动态的服务扩容和资源回收
 缺点：使用的是Timer而不是线程池执行任务调度。TBSchedule的作业类型比较单一，只能是获取/处理数据一种模式，而且目前文档偏少
 
####2、目前推出了基于Akka架构的Schedulerx2.0
 新一代定时任务，提供分布式执行、多种任务类型、统一日志等框架，用户只要依赖schedulerx-worker这个jar包，通过schedulerx2.0提供的编程模型，简单几行代码就能实现一套高可靠可运维的分布式执行引擎。在海量数据并行任务、复杂dag调度
 
可扩展的执行引擎
 
Worker总体架构参考Yarn的架构，分为TaskMaster, Container, Processor三层：
 
 
TaskMaster：类似于yarn的AppMaster，支持可扩展的分布式执行框架，进行整个jobInstance的生命周期管理、container的资源管理，同时还有failover等能力。默认实现StandaloneTaskMaster（单机执行），BroadcastTaskMaster（广播执行），MapTaskMaster（并行计算、内存网格、网格计算），MapReduceTaskMaster（并行计算、内存网格、网格计算）。
Container：执行业务逻辑的容器框架，支持线程/进程/docker/actor等。
Processor：业务逻辑框架，不同的processor表示不同的任务类型。
 
以MapTaskMaster为例，大概的原理如下图所示：
 
 
其借鉴了MapReduce的模式，支持Map、MapReduce模型，在海量数据分发多台机器的效率上非常方便，支持分布跑批，针对不同的跑批场景，map模型作业还提供了并行计算、内存网格、网格计算三种执行方式：
 
并行计算：子任务300以下，有子任务列表。
 内存网格：子任务5W以下，无子任务列表，速度快。
 网格计算：子任务100W以下，无子任务列表。
 
 
考拉的kSchedule
 
这里再说一个考拉的分布式定时任务框架kSchedule，大体与elastic-job类似，
 
 
这里说一点，kSchedule的无侵入性做的更好，对于简单任务不需要事先Job接口，只需要把任务bean注册成容器的Service的public方法即可，然后再配置界面配置调度任务的方法和参数即可，大大的方便的简单任务的开发和配置工作；（其实就是实现了普通类的方法级别的定时任务配置，而一般的定时任务都是类继承Job类，重写execute方法）
 
这点在其他框架中实现时需要写个简单任务的调度分配任务，然后把普通类的方法和入参作为动态参数传到调度分配任务，然后利用反射，进行动态执行。
 
4、综合比较选型
 
简单几条原则
 1、业务起步阶段：没有自主研发运维能力，选择业界使用最多最成熟的，最好是直接买，比如阿里云的Schedulerx2.0，把技术、运维都交给阿里云，只开发业务逻辑即可；或者Elastic-job-cloud版本，在私有云上部署，功能支持也比较完善，花钱都能解决
 2、业务发展阶段：数据规模和任务规模都在扩大，有一定的研发能力，可以考虑接入成熟开源框架，比如quartz或者Elastic-job-lite都是开源的，几台机器搭建起来就可以跑，出问题了开源用解答的也比较多。每秒几千个任务没问题
 3、业务成熟阶段：每秒任务扩大到几万、几十万个，而且业务个性化需要越来越多，比如各种调度策略，批处理任务的个性化支持，这时候要选择一个开源框架的基础上进行二次开发，目前quartz或者Elastic-job-lite都是不错的选择
 
具体的对比表格
 各个框架对比文档—转自：分布式调度框架大集合
 
5、参考文章
 
分布式调度框架大集合
 详解应对平台高并发的分布式调度框架TBSchedule
 Quartz架构整理
 开源的作业调度框架Quartz
 考拉定时任务框架kSchedule
 Schedulerx2.0分布式计算原理&最佳实践

导语：在前面我们讲过了阿里云分布式任务调度平台，今天我们从架构和技术实现上来为大家讲解腾讯云分布式任务调度系统TCT(Tencent Cloud Task)如何实现任务调度的精准实时、稳定高效，以及任务的切分和编排。
 
 
 
01
 
背景介绍
 
 
 
 
 
缘起缘灭，自有因果
 
 
首先, 我们来思考一些几个业务场景：
 
 
XX信用卡中心，每月28日凌晨1:00到3:00需要完成全网用户当月的费用清单的生成。
 
 
XX服饰，需要每天上午9:00开始向会员推送送生日祝福短信。
 
 
XX游戏平台，新用户注册后，需要为当前用户生成定时任务， 在月底清算虚拟货币兑换的佣金额度。
 
 
XX公司，需要定时执行Python脚本，清理掉某文件服务系统中无效的tmp文件。
 
 
XX保险公司，需要每天凌晨2:00统计前一天新增保单数量，并触发报表生成任务，完成后抄送邮件。
 
类似上述批量处理海量定时任务的业务场景，企业从单体架构向微服务架构、云化服务架构演进过程中已经屡见不鲜，基于Quartz的常规调度框架已无法应对这种分布式场景下的需求，既无法实现任务调度的精准实时、稳定高效，也无法实现任务的切分、编排、失败补充。因此企业迫切需要一款一站式分布式调度任务解决方案，帮助企业统一管理繁杂纷乱的定时任务，增强企业微服平台服务化能力，支撑企业云化服务转型。
 
 
 
02
 
现有的开源方案
 
 
 
 
 
 
 
 
 
它山之石可以攻玉 ...
 
 
在过往的发展中, 前人留下了不少优秀的方案, 各有利弊。常见开源产品: Quartz、XXL-Job、ElasticJob、Antares、SIA-TASK 等。
 
 
Quartz：该框架应用最为广泛，其完全基于Java实现，Quartz 对单个任务的控制基本做到了极致，以其强大功能和应用灵活性，成为开源任务调度领域的权威及同类开源产品如Antares的基石；
 
 
XXL-JOB：一个轻量级分布式任务调度平台，其核心设计目标是开发迅速、学习简单、轻量级、易扩展。XXL-JOB 支持分片，支持简单任务依赖，支持子任务依赖，不支持跨平台的。
 
 
Elastic-Job：支持任务分片（作业分片一致性），没有任务编排，不支持跨平台；
 
 
SIA-TASK：具有跨平台、可编排、高可用、无侵入、一致性、异步并行、动态扩展、实时监控等特点。
 
 
开源方案的逻辑架构图
 
 
 
 
开源方案的技术实现图
 
 
 
从开源方案的逻辑架构和技术实现上，我们也能直观的看出开源方案的不足：
 
 
架构方面：调度器职责划分不清晰、系统扩展性不足。面对大规模虚拟化&复杂的网络环境，简单的远程调用并不能完成胜任。
 
 
性能方面：ZooKeeper集群伴随任务量和高频事件的增多，成为系统性能瓶颈。简的远程调用或者任务拉取等方案, 满足不了量大频高的业务诉求。
 
 
功能方面：缺乏完整认证鉴权方面的系统设计，安全性无法保障。任务干预、监控告警等系统运维方面能力较弱。
 
 
 
03
 
TCT简介
 
 
 
 
 
 
 
为了解决上述问题，我们进行了深入的探索，并设计出了一套企业级的分布式任务调度系统TCT（Tencent Cloud Task）。TCT提供一站式分布式调度任务解决方案，支持随机、广播多种任务类型，具备任务分片、任务编排能力，提供完善的监控告警体系。我们结合了用户实际的业务场景，吸取了历史经验，主要解决了面几个核心问题：
 
 
以上核心要素，对系统的要求各不相同，可提供如下总结进行参考:
 
 
04
 
技术架构
 
 
 
 
 
 
 
 
技术架构图
 
下面我们解释下架构图中的各个功能模块：
 
 
 
 
05
 
功能架构
 
 
 
 
 
 
 
 
功能架构图
 
这样设计分布式任务调度系统，有以下几个优点：
 
优点一：模块化微服务架构设计, 职责清晰
 
触发器
 
 
只需根据任务执行规则，计算解析出不同时点的任务触发事件。通过MQ的实现可靠性投递(后续文章会逐步讲解如何实现可靠性投递)，起到削峰填谷，避免高峰IO等问题, 提高吞吐量。
 
 
通过合理的分片策略和容灾策略，解决传统多节点锁竞争轮训的解析加载策略，降低对存储的压力。
 
 
冷热数据隔离加载机制，进一步降低对存储压力和系统开销。
 
 
根据高频的任务执行策略，采取预加载策略和动态调整预加载算法，解决高频触发导致系统负载高的问题。
 
调度器
 
 
整个任务调度系统中控制逻辑最为复杂的组件，IO密集型组件。
 
 
通过订阅MQ消息事件，与触发器解耦，有效提升系统的吞吐。
 
 
专注于任务调度的逻辑控制，如任务执行调度、负载均衡、容错、限流、计费等。
 
接入网关
 
 
独立承担客户端的接入认证和鉴权，提供有效的权限校验策略。
 
 
负责上下行信道的回话管理，与复杂的业务逻辑完成解耦。
 
 
客户端节点及服务节点上下线自动探测感知机制，有效实现会话管理。
 
 
数据透传及路由，实现组件内闭环。
 
 
配合SDK/Agent侧设计，有效避免了单节点连接数瓶颈以及服务节点冷起场景下的高并发tcp建立连接问题。
 
优点二：无状态化设计，简便水平扩展
 
触发器
 
 
通过有效的分片策略，在实现避免触发压力集中化的情况下，可快捷的完成服务的弹性扩缩容，实现近似无状态的水平扩展。
 
调度器
 
 
完全无状态的设计方案，无需考虑任务的回源问题，实现无状态的水平扩容。
 
接入网关
 
 
完全无状态的设计方案，可实现无状态的水平扩容，实现理论上TCP连接数无上限。
 
优点三：功能完备
 
灵活的触发规则
 
 
支持Cron表达式，例如 * 0/5 * * * ? 等。
 
 
特定周期频率的触发规则，例如 间隔36分钟等。
 
便捷的管理能力，提供暂停、恢复、停止、重试等多种多样的管控能力。
 
 
 
任务管理
 
支持三种执行方式
 
 
随机节点执行：选择集群中一个可用的执行节点执行调度任务。适用场景：定时对账。
 
 
广播执行：在集群中所有的执行节点分发调度任务并执行。适用场景：批量运维。
 
 
分片执行：按照用户自定义分片逻辑进行拆分，分发到集群中不同节点并行执行，提升资源利用效率。适用场景：海量日志统计。
 
 
任务调度执行方式
 
支持三种触发方式
 
 
手动触发：用户在任务管理列表选择特定任务手动执行一次，调度器立即进行任务分发，并产生一个执行批次。适用场景：周期执行任务补充。
 
 
周期触发：通过设置任务触发的间隔时间来设置任务的执行时间；可支持 cron 表达式所不支持的周期设置。适用场景：定时备份。
 
 
工作流触发：工作流是一组任务集合，可以编排任务的上下游逻辑依赖，进行任务触发。适用场景：海量数据处理，如数据采集，数据过滤，数据清洗，数据聚合的流程编排。
 
 
任务触发方式
 
日志溯源能力
 
通过日志服务, 方便用户查询任务执行日志。用户可以通过执行记录所有任务的执行批次详情，能够对当前状态为执行中的批次进行停止执行操作，能够对当前已经终止的批次触发重新执行操作；点击批次ID进入该批次的执行详情，点击任务ID进入该任务的执行批次列表，点击执行部署组进入资源详情列表。
 
 
日志查询
 
支持复杂的任务编排能力
 
可以实现多种场景的任务工作流。通过构建调度任务的上下游依赖关系完成复杂的任务调度逻辑。适用于大数据流程处理、任务执行工单、批量运维流程编排等应用场景。
 
 
任务编排
 
 
 
06
 
总结
 
 
 
一个平台性的系统，从产品功能到技术架构都存在着方方面面的挑战，需要层层抽象和逐步优化才能完成一个成熟产品落地。在大数据时代，面对海量的数据和用户规模，任何一种架构设计，都面临着网络响应、 容错、幂等、数据可靠性/一致性等诸多问题。
 
 
 
对于平台而言，任务的可靠性是第一优先级需要考虑的，次之任务执行的时效性。合理地进行功能模块化拆分，针对不同场景，设计不同的扩展方案，保证SLA的前提下提升系统整体吞吐，实现可靠有效触达，应对频高量大的业务场景。
 
 
 
对于用户而言，多样化的管理手段、多维度的运行指标查询， 全方位的链路监控则是用户追求的，只有让用户从复杂混乱的定时任务场景中抽离出来，才能更加专注在业务研发。