分布式任务调度平台构建方案

吴宇星

摘 要：IT系统都免不了存在定时任务，传统的（JAVA体系）系统建设开发定时任务一般都是使用quartz或者spring-task，但是这两种方案都缺乏集群能力，难以进行水平扩展。随着大数据技术发展系统定时任务的服务很多，需要有统一定时任务调度服务提供定时任务的调度、管理、监控、高可用性、可扩展性。本文就基于Quartz构建分布式任务调度方案进行阐述。

关键词：分布式;任务;Quartz;监控

1.引言

现在IT系统都免不了存在定时任务，需要实现分布式任务调度平台，具备把定时任务通过集群的方式进行管理调度，并采用分布式部署，保证系统的高可用，提高了容错。那么如何保证定时任务只在集群的某一个节点上执行，或者一个任务如何拆分为多个独立的任务项，由分布式的机器去分别执行。

2.功能需求

分布式任务调度平台常用于高并发，高可用的定时任务处理，如：定时发送消息，处理业务数据，并需要具备特殊时候可人为干预。

总体能力目标：

√定时任务配置功能

包括任务的注册、取消功能。配置任务对应任务组。执行的任务中可以根据IP和端口进行扩充。实现定时规则的配置。

√定时任务的监控功能

监控当前任务组的状态，是否正在执行，有多少个任务在执行。

√支持定时任务的动态扩展

按定时任务配置的规则进行轮询。

√定时任务执行

支持配置定时任务后，N秒后生效。轮循进程开如轮循。

具体的技术目标：

√集群管理调度，分布式部署，保证系统的高可用性、伸缩性、负载均衡;

√友好的操作界面，通过控制台部署管理任务，方便灵活高效;

√任务持久化于数据库，远离宕机和数据丢失隐患，完善的任务失败重做机制，及详细的任务跟踪及告警策略;

√Server和Client分别支持集群和分布式部署;

√任务的执行与调度分离;

√任务支持异步调度;

√任务状态持久化于DB;

√完善的日志跟踪和告警策略。

3.建设方案

3.1.总体方案

分布式任务调度平台是基于Quartz的定时轮询功能，进行改造成服务端执行端分离模式，实现应用调度分布式型的结构，以及应用跟实际调度解耦：

WEB集群实现界面配置功能、并支持Quartz的定时解析，保证集群内一次只有一个服务支持定时任务，对任务的解析通过Quartz解析;

任务管理器负责任务的注册、停止、暂时以及保存状态信息;

为保证业务与定时功能的分离。任务对应的消息队列在数据库配置。为保证对原有代码的侵入性最小，任务不需要实现监听器。只需要在任务的service抽象类中实现监听器进行监听;

采用通用RPC服务框架进行定时任务的通讯，支撑异步操作，响应快。实现动态扩充服务来满足定时任务的处理要求，满足高可用的要求。

分布式任务调度平台具备如下主要特点：

负载均衡：执行端可集群部署，服务端会自动实现负载均衡调度;

分布式：根据模或其他方式的参数任务分配，实现同一批数据多个实例分配处理;

转移告警：任务配置超时且策略为转移情况下，应用卡死的任务会进行中断后转移到其他集群节点执行;

轨迹记录：根据任务运行的各个环节，以及节点，组成一条链的轨迹。

3.2.功能方案

分布式任务调度平台主要由四部分组成，管理端、客户端、服务端、执行端。由服务端进行管控派发任务，执行端来执行相应的任务，客户端进行提供对外的Java通信交互接口，Admin Web进行操作任务。

3.2.1.管理端

1）任务的注册、取消与暂停、手动启动，任务需要定义名称，绑定具体的任务执行器（JAVA类）上。

2）定时规则的配置，采用界面化配置，基于Quartz扩展，并且支持cron表达式。

3）增加或删除服务到任务上。具备按IP与端口增加或删除任务到任务组上。

4）任务和任务组的监控，具备监控调用日志实现任务执行状态查看。

3.2.2.客戶端

1）实现客户端，支持进行任务的操作。在管理平台的所有任务操作，全部由client端请求server端完成。

2）提供专门的对外接口类，只需要配置server端的地址即可new实例即可，可调用接口进行操作查询任务，client跟server之间采用长连接，通信损耗时间要小，可忽略不计。

3.2.3.服务端

服务端对应用端的分布式调用，采用quartz每开始一个子任务，启动一个线程去执行该子任务，直到子任务执行完毕就释放。

3.2.4.执行端

执行端是任务执行的承载体，服务端下发的业务任务实际上有执行端进行运行。

1）具备任务线程池

需要自定义线程池，进行可管控的让优先级高的任务进行优先执行。

2）可设定任务优先级

需要具备根据应用配置的任务优先级，进行调控优先级高的任务进行执行，优先级低的任务先排后面。

3）可上报执行信息

定时上报该执行端的线程池情况信息，包括工作中线程中对应的任务，方便线程dump分析应用的情况。

3.3.关键技术方案

3.3.1.任务轨迹查看

应用在查找任务不执行问题的时候，难以了解到任务的分部执行情况轨迹，以及服务端中各种任务的状态汇总情况，需要具备界面化的查看任务的轨迹情况、集群情况。

解决方案：

1、为了方便数据的实时性，直接采用通过客户端从服务端实时读取内存中的数据。

3.3.2.任务手动调整

实际应用中，运用场景较为复杂，有时候需要对已经创建的子任务的数据进行修改（包含任务层面修改数据以及子任务层面修改数据），则不能修改的话必须重新删除创建，如果子任务数量非常多，创建非常麻烦。

解决方案：

quartz目前版本并不支持修改子任务的对外接口或者可操作方法，则只能由客户端操作进行先删除重新新建的操作，但是要保证各个集群服务端中并无运行中的子任务、超时子任务等一切还未执行完毕的子任务存在。

3.3.3.任务均衡

任务分配任务算法是根据某个任务执行子任务的时候，如果某个应用有3个节点部署执行任务，创建了3个任务，每个任务的子任务数参考图中解释，单次触发多个任务的时候，会造成分配不均情况。

解决方案：

每次分配任务的时候，先查看各个节点已经容纳运行的子任务数量，然后做均衡算法分配到平均，每个节点运行数量相差个数不超过1。

3.3.4.异常重新执行

quartz提供异常任务的重新触发机制以及暂停任务的机制，由于考虑到一期轮询中quartz每触发一个子任务都消耗一个线程，除了异常暂停任务外，异常重新触发由服务端外部控制触发，并不交给quartz来处理。

解决方案：

异常的任务每次落地到数据库中，方便应用查看历史的异常记录情况。

4.结束语

本文就基于quartz设计实现分布式任务调度平台方案进行介绍，并且目前该实现方案已经在项目中应用，在应用系统的任务的管理、运行上有了很大的提升，很好了支撑了业务系统中的后台任务的运行，做到可管、可控，并且具备水平扩展能力。

参考文献：

[1] 分布式定时任务调度框架.https：//www.jianshu.com/p/ab438d944669