分布式调度任务系统调研及选型

一篇旧文了，之前在公众号”CurdBoys” 中发过，文章链接 ，现在发一下在博客园上

目前的场景是这样的，我们组内现在有很多旧或新的定时任务都是在直接在某些服务器上跑。如果遇到要下线某台服务器，要先检查一下这个服务器上是否还存在定时任务脚本。通常情况下，即使找到该运行的定时任务脚本，也不知道它是用来做的或者是否能迁移到其他机器上。另外，如果某台机器挂了，上面的定时任务脚本也会挂了，不能自动切换到其他机器上。

由于存在着这种情况，我们就想着把这些定时任务脚本管理起来，并且需要具备高可用。这就需要一个分布式调度任务系统。🧐

概述

关于定时执行任务的工具或框架系统有很多，一般情况下针对不同的应用场景可以选择适合该场景下工具或框架。例如：如果不想引入其他语言，只使用shell来执行的，可以使用 linux Crontab 来执；如果是基于Spring 想着简单实现一个定时任务，可以使用@Scheduled注解。如果按照是否为单独的系统来分可以分为两类：1. 系统或框架自带的定时执行方法或工具。2. 单独作为一个服务的调度任务系统。

系统或框架自带的定时执行方法或工具

Linux Crontab

只能单机执行与linux机器固定绑定，可以通过cron 表达式定时执行shell脚本。简单易使用，不好后期维护，只能执行shell脚本。

Java 原生的定时器Timer

优点：简单，不用引入其他框架。

缺点：

1. Timer在执行所有定时任务时只会创建一个线程，如果某个任务的执行时间过长，那么将破坏其他TimerTask的定时精确性
2. Timer的另一个问题是，如果TimerTask抛出了一个未检查的异常，那么Timer线程不会捕获异常，此时会终止定时线程，并且不会恢复。
   参考：java定时器之Timer使用与原理分析

Spring 的 @Scheduled注解

一般集成于项目中，小任务很方便，不能分布式。注意，如果使用了，在集群部署的时候需要使用分布式锁来限制

单独作为一个服务的调度任务系统

这部分主要的调度任务系统都是开源系统，并且大部分是基于Java的Quratz框架来封装的

XXL-JOB

XXL-JOB是一个分布式任务调度平台，其核心设计目标是开发迅速、学习简单、轻量级、易扩展。

（美团公司个人开放）“调度中心”基于集群Quartz实现，提供官方docker镜像，作业与语言无关。社区较活跃，一直有维护状态。 较多公司使用。

elastic-job

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

当当开源的，使用 Zookeeper 实现分布式分布式部署。2019年10月前停止维护过一段时间，后面才重新维护。并且在2020 年 5 月 28 日成为 Apache ShardingSphere 的子项目未来前景应该很不错。

Saturn

Saturn (任务调度系统)是唯品会Venus体系的一个组成部分，负责分布式的定时任务的调度，取代传统的Linux Cron/Spring Batch Job的方式，做到全域统一配置，统一监控，任务高可用以及分片并发处理。Saturn基于当当Elastic Job代码基础上自主研发的任务调度系统。

唯品会开源的，基于elastic-job。支持多种语言作业，语言无关(Java/Go/C++/PHP/Python/Ruby/shell)。社区活跃度一般，小部分公司使用。

基于Quartz自己开发

开源的有个好处就是大部分都是开箱即用。但是通常来说，如果直接使用开源的系统，后期改造起来都是比较麻烦，而且如果有什么问题，排查起来也比较麻烦，毕竟不是自己的系统。基于我们要求的调度任务系统，并不需要太多功能，所以我们计划自己基于Quartz框架来开发调度任务系统。

原生quartz任务的缺点

1. 只能在单个服务器上运行，或者在多个服务器上集群运行，在单个数据库的情况下，不能指定不同服务器运行不同任务。

为了解决原生Quartz的确定，我们基于Quartz和GRPC框架来开发任务调度系统，具体方案如下：

1. 利用一台服务器部署quartz服务和作为服务注册中心（rpc调用中心）。
2. 通过创建不同的cron定时任务，通过传入服务器地址，要执行的方法，定时远程rpc调用不同服务器上的方法。
3. 定义每个master和slaver都定义http请求调度，命令行请求调度和邮箱发送请求调度，当不需要指定执行机器时，则通过随机找一个slaver去执行。

初版项目地址：https://github.com/KANLON/job-scheduling (这个还不太完善，目前执行还不支持执行的高可用，后面需要修改执行任务的机器为一个列表，遍历该列表执行)

总结

如果没有时间或资源搭一套调度任务系统，可以使用系统或框架自带的定时执行方法或工具来简单使用。如果需要统一管理，方便后期维护建议首先使用开源系统的。开源的分布式调度任务系统中建议使用xxl-job，该开源系统社区活跃度高，使用的公司数量相对较多，而且一直有在维护。

以下是我整理的思维导图：