概述

上一篇中对定时任务和定时任务的基础使用方式进行了说明。这一小节，把分布式场景下的定时任务进行一个大致的讲解。

什么是分布式场景呢，当单台服务器服务能力不够的时候，就需要更多的服务器进行水平向的扩展，由多台服务器分工（任务量上的水平划分，而非业务线上的垂直划分）的方式来增强服务能力，提供更强的并发请求处理，更短的时间响应。

像第一节说到的定时任务使用场景，大多是一次任务执行仅能有一个服务器在执行，如果是所有服务器都在执行相同的任务，一个是会造成错误，就算不会造成错误，很多服务器在做重复的工作也是极大的浪费。

所以，分布式场景下定时任务要做的一个基本难点就是：怎么让某一个定时任务，在一个触发时点上仅有一台服务器在执行。

更进一步，如果，你的定时任务涉及到很多同类型的数据要处理，比如说要处理100个输入文件，处理方式相同；再比如说你的数据库已经做了分库处理，业务数据被写入到了10个数据库实例中，处理方式相同。那么此时，可以让更多台服务器执行定时任务，每台执行其中的一部分，比如10个输入文件；再比如1个数据库实例中的业务数据。

以上两种场景怎么办呢？第一种很简单，后续会提供三种方式去做：1.设置某一台为任务执行服务器，其他服务器不执行；2.使用quartz的集群功能，实现某一台执行；3.使用当当开源的elastic-job，实现某一台执行。第二种场景只有第一种场景中的第3中方式可以做到。

接下来逐个看一下。

实现分布式的方式

设置某一台为任务执行服务器

这种方式可以采用环境变量的方式来实现，定时任务运行时检查本机的环境变量值是否为可执行，如果是则执行定时任务，如果不是则直接返回。

@Value("${ISTIMERRUNNER}")private String isTimerRunner;@Scheduled(cron="0 0 0 * * ? ")public void task(){    try {        if("true".equals(isTimerRunner)){                //do something.....            }        } catch (Exception e) {            e.printStackTrace();        }    }

这里有一个需要注意的事项，如果集群环境下，你使用了脚本部署的方式，而且是类似于作者的方式。也就是先把文件拷贝到一台服务器，启动好后，调用脚本（脚本参见：），逐个部署到其他服务器。那么，你就需要注意一下了。

远程ssh调用startup.sh时，tomcat取不到环境变量，这里需要把startup.sh的顶部进行修改：

#!/bin/sh --login

当然这里还有另外一种方式，就是在tomcat的bin目录中添加一个setenv.sh文件，startup.sh执行时会加载其中的内容。

export ISTIMERRUNNER=true

这种方式有十分明显的缺陷：1.单点，当任务执行节点出现问题时，整个定时任务全部over；2.资源分配不均衡，随着定时任务的增多，任务执行服务器的资源占用压力会越来越大。

当然了，这是在技术能力不够的时候，最简单有效的实现方式。

使用quartz的集群功能

quartz这个老牌的定时任务执行工具，在集群方面也提供了很好的支持。quartz的集群是借助数据库来实现的，所有的服务器实例共享一套数据库表中存储的任务、触发器和调度器信息，实现一个时间点，同一个任务仅有一台服务器在执行。而且提供了负载均衡和failover失败转移功能。

quartz的负载均衡大概是这样的策略：对于需要调度很多任务的调度器，会近似随机的选择服务器执行；对于调度的任务数比较少的（1个或者2个）的触发器，会尽量的在同一台服务器上执行。（可以参见这里:

quartz的集群使用也不复杂，接下来一起看一下：

1.导入数据库表

quartz的集群是基于数据库实现的，所以首先要把数据库表结构创建好。创建脚本在quartz的完整下载包里可以找到（官网下载地址：

解压之后，在docs/dbTable目录下可以找到你想要的所有常见数据库类型的创建脚本。

我使用的是sql数据库，所以使用了tables_mysql_innodb.sql。

这里导入的时候遇到了一个问题，就是创建索引时索引字段过长。这里我采用的方法是把所有的scheduler的长度变成了50，修改之后也就是会限制所有的scheduler的名字在50个字节以内。

2.创建支持集群的scheduler

集群和非集群的配置不同，关键就在于scheduler，集群时需要给scheduler配置数据源、将org.quartz.jobStore.isClustered设置为true、以及配置quartz.properties属性文件。详细的实现方式可以参见：

使用elastic-job

elastic-job是基于quartz实现的，最大的不同点是elastic-job把做为共享中心的数据库换成了zookeeper。所以要使用elastic-job首先要安装zookeeper。

安装好zookeeper之后，使用elastic-job也不难，它做了很好的spring集成支持，只需要配置注册中心和执行任务的job即可。

以下是一个配置文件的示例：

更详细的示例可以到github下载：

这里简单的说一下elastic-job相对于quartz的优势：

1.使用zookeeper做为协调，更加轻量级，这一点对于使用者来说也是一个困难项，因为无论再小的服务也有一个数据库，所以定时任务也使用数据库，那么用起来省事一点。但使用zookeeper一方面速度快，另一方面是不占用现有数据库的连接和计算资源。

2.支持任务的分片，quartz同一时点，同一任务只能在一台机器上运行，但是elastic-job可以在多台机器上运行，并且能够指定每台服务器上运行的输入分片。比如业务数据在10个数据库，这里总共有5台服务器，那么每台服务器在同一个时点，仅处理其中的2个数据库。做到将可纵向切分的任务，切分给不同的服务器，充分利用资源，加快计算速度。

elastic-job怎么做到的分片，在不同的场景下我们该怎么使用elastic-job，接下来的一节将从源代码的角度进行讲解。