定时工作是每个业务常见的需要

一：Java 中自带的解决方案Cloud Native

1
应用 Timer
创立 java.util.TimerTask 工作，在 run 办法中实现业务逻辑。通过 java.util.Timer 进行调度，反对依照固定频率执行。所有的 TimerTask 是在同一个线程中串行执行，相互影响。也就是说，对于同一个 Timer 里的多个 TimerTask 工作，如果一个 TimerTask 工作在执行中，其它 TimerTask 即便达到执行的工夫，也只能排队期待。如果有异样产生，线程将退出，整个定时工作就失败。

import java.util.Timer;import java.util.TimerTask;public class TestTimerTask {       public static void main(String[] args) {        TimerTask timerTask = new TimerTask() {            @Override            public void run() {                System.out.println("hell world");            }        };        Timer timer = new Timer();        timer.schedule(timerTask, 10, 3000);    }  }2应用 ScheduledExecutorService基于线程池设计的定时工作解决方案，每个调度工作都会调配到线程池中的一个线程去执行，解决 Timer 定时器无奈并发执行的问题，反对 fixedRate 和 fixedDelay。import java.util.concurrent.Executors;import java.util.concurrent.ScheduledExecutorService;import java.util.concurrent.TimeUnit;public class TestTimerTask {    public static void main(String[] args) {        ScheduledExecutorService ses = Executors.newScheduledThreadPool(5);        //依照固定频率执行，每隔5秒跑一次        ses.scheduleAtFixedRate(new Runnable() {            @Override            public void run() {                System.out.println("hello fixedRate");            }        }, 0, 5, TimeUnit.SECONDS);        //依照固定延时执行，上次执行完后隔3秒再跑        ses.scheduleWithFixedDelay(new Runnable() {            @Override            public void run() {                System.out.println("hello fixedDelay");            }        }, 0, 3, TimeUnit.SECONDS);    }}

复制代码
02
Spring 中自带的解决方案
Cloud Native
Springboot 中提供了一套轻量级的定时工作工具 Spring Task，通过注解能够很不便的配置，反对 cron 表达式、fixedRate、fixedDelay。
import org.springframework.scheduling.annotation.EnableScheduling;
import org.springframework.scheduling.annotation.Scheduled;
import org.springframework.stereotype.Component;

@Component
@EnableScheduling
public class MyTask {

/** * 每分钟的第30秒跑一次 */@Scheduled(cron = "30 * * * * ?")public void task1() throws InterruptedException {    System.out.println("hello cron");}/** * 每隔5秒跑一次 */@Scheduled(fixedRate = 5000)public void task2() throws InterruptedException {    System.out.println("hello fixedRate");}/** * 上次跑完隔3秒再跑 */@Scheduled(fixedDelay = 3000)public void task3() throws InterruptedException {    System.out.println("hello fixedDelay");}

}
复制代码
Spring Task 绝对于下面提到的两种解决方案，最大的劣势就是反对 cron 表达式，能够解决依照规范工夫固定周期执行的业务，比方每天几点几分执行。
03
业务幂等解决方案
Cloud Native
当初的利用根本都是分布式部署，所有机器的代码都是一样的，后面介绍的 Java 和 Spring 自带的解决方案，都是过程级别的，每台机器在同一时间点都会执行定时工作。这样会导致须要业务幂等的定时工作业务有问题，比方每月定时给用户推送音讯，就会推送屡次。
于是，很多利用很天然的就想到了应用分布式锁的解决方案。即每次定时工作执行之前，先去抢锁，抢到锁的执行工作，抢不到锁的不执行。怎么抢锁，又是形形色色，比方应用 DB、zookeeper、redis。
1
应用 DB 或者 Zookeeper 抢锁
应用 DB 或者 Zookeeper 抢锁的架构差不多，原理如下：

定时工夫到了，在回调办法里，先去抢锁。
抢到锁，则继续执行办法，没抢到锁间接返回。
执行完办法后，开释锁。

示例代码如下：
import org.springframework.scheduling.annotation.EnableScheduling;
import org.springframework.scheduling.annotation.Scheduled;
import org.springframework.stereotype.Component;

@Component
@EnableScheduling
public class MyTask {

/** * 每分钟的第30秒跑一次 */@Scheduled(cron = "30 * * * * ?")public void task1() throws Exception {    String lockName = "task1";    if (tryLock(lockName)) {        System.out.println("hello cron");        releaseLock(lockName);    } else {        return;    }}private boolean tryLock(String lockName) {    //TODO    return true;}private void releaseLock(String lockName) {    //TODO}

}
复制代码
以后的这个设计，认真一点的同学能够发现，其实还是有可能导致工作反复执行的。比方工作执行的十分快，A 这台机器抢到锁，执行完工作后很快就开释锁了。B 这台机器后抢锁，还是会抢到锁，再执行一遍工作。
2
应用 redis 抢锁
应用 redis 抢锁，其实架构上和 DB/zookeeper 差不多，不过 redis 抢锁反对过期工夫，不必被动去开释锁，并且能够充分利用这个过期工夫，解决工作执行过快开释锁导致工作反复执行的问题，架构如下：

示例代码如下：
@Component
@EnableScheduling
public class MyTask {

/** * 每分钟的第30秒跑一次 */@Scheduled(cron = "30 * * * * ?")public void task1() throws InterruptedException {    String lockName = "task1";    if (tryLock(lockName, 30)) {        System.out.println("hello cron");        releaseLock(lockName);    } else {        return;    }}private boolean tryLock(String lockName, long expiredTime) {    //TODO    return true;}private void releaseLock(String lockName) {    //TODO}

}
复制代码
看到这里，可能又会有同学有问题，加一个过期工夫是不是还是不够谨严，还是有可能工作反复执行？
——确实是的，如果有一台机器忽然长时间的 fullgc，或者之前的工作还没解决完（Spring Task 和 ScheduledExecutorService 实质还是通过线程池解决工作），还是有可能隔了 30 秒再去调度工作的。
3
应用 Quartz
Quartz  [  1]   是一套轻量级的任务调度框架，只须要定义了 Job（工作），Trigger（触发器）和 Scheduler（调度器），即可实现一个定时调度能力。反对基于数据库的集群模式，能够做到工作幂等执行。

Quartz 反对工作幂等执行，其实实践上还是抢 DB 锁，咱们看下 quartz 的表构造：

其中，QRTZ_LOCKS 就是 Quartz 集群实现同步机制的行锁表，其表构造如下：
--QRTZ_LOCKS表构造
CREATE TABLE QRTZ_LOCKS (
LOCK_NAME varchar(40) NOT NULL,
PRIMARY KEY (LOCK_NAME)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

--QRTZ_LOCKS记录
+-----------------+
| LOCK_NAME |
+-----------------+
| CALENDAR_ACCESS |
| JOB_ACCESS |
| MISFIRE_ACCESS |
| STATE_ACCESS |

TRIGGER_ACCESS

复制代码
能够看出 QRTZ_LOCKS 中有 5 条记录，代表 5 把锁，别离用于实现多个 Quartz Node 对 Job、Trigger、Calendar 拜访的同步控制。
04
开源任务调度中间件
Cloud Native
下面提到的解决方案，在架构上都有一个问题，那就是每次调度都须要抢锁，特地是应用 DB 和 Zookeeper 抢锁，性能会比拟差，一旦任务量减少到肯定的量，就会有比拟显著的调度延时。还有一个痛点，就是业务想要批改调度配置，或者减少一个工作，得批改代码从新公布利用。
于是开源社区涌现了一堆任务调度中间件，通过任务调度零碎进行工作的创立、批改和调度，这其中国内最火的就是 XXL-JOB 和 ElasticJob。
1
ElasticJob
ElasticJob  [  2]   是一款基于 Quartz 开发，依赖 Zookeeper 作为注册核心、轻量级、无中心化的分布式任务调度框架，目前曾经通过 Apache 开源。
ElasticJob 绝对于 Quartz 来说，从性能上最大的区别就是反对分片，能够将一个工作分片参数分发给不同的机器执行。架构上最大的区别就是应用 Zookeeper 作为注册核心，不同的任务分配给不同的节点调度，不须要抢锁触发，性能上比 Quartz 上弱小很多，架构图如下：

开发上也比较简单，和 springboot 联合比拟好，能够在配置文件定义工作如下：
elasticjob:
regCenter:

serverLists: localhost:2181namespace: elasticjob-lite-springboot

jobs:

simpleJob:  elasticJobClass: org.apache.shardingsphere.elasticjob.lite.example.job.SpringBootSimpleJob  cron: 0/5 * * * * ?  timeZone: GMT+08:00  shardingTotalCount: 3  shardingItemParameters: 0=Beijing,1=Shanghai,2=GuangzhouscriptJob:  elasticJobType: SCRIPT  cron: 0/10 * * * * ?  shardingTotalCount: 3  props:    script.command.line: "echo SCRIPT Job: "manualScriptJob:  elasticJobType: SCRIPT  jobBootstrapBeanName: manualScriptJobBean  shardingTotalCount: 9  props:    script.command.line: "echo Manual SCRIPT Job: "

复制代码
实现工作接口如下：
@Component
public class SpringBootShardingJob implements SimpleJob {

@Overridepublic void execute(ShardingContext context) {    System.out.println("分片总数="+context.getShardingTotalCount() + ", 分片号="+context.getShardingItem()        + ", 分片参数="+context.getShardingParameter());}

}
复制代码
运行后果如下：
分片总数=3, 分片号=0, 分片参数=Beijing
分片总数=3, 分片号=1, 分片参数=Shanghai
分片总数=3, 分片号=2, 分片参数=Guangzhou
复制代码
同时，ElasticJob 还提供了一个简略的 UI，能够查看工作的列表，同时反对批改、触发、进行、失效、生效操作。

遗憾的是，ElasticJob 暂不反对动态创建工作。
2
XXL-JOB
XXL-JOB  [  3]  是一个开箱即用的轻量级分布式任务调度零碎，其外围设计指标是开发迅速、学习简略、轻量级、易扩大，在开源社区宽泛风行。
XXL-JOB 是 Master-Slave 架构，Master 负责工作的调度，Slave 负责工作的执行，架构图如下：

XXL-JOB 接入也很不便，不同于 ElasticJob 定义工作实现类，是通过@XxlJob 注解定义 JobHandler。
@Component
public class SampleXxlJob {

private static Logger logger = LoggerFactory.getLogger(SampleXxlJob.class);/** * 1、简略工作示例（Bean模式） */@XxlJob("demoJobHandler")public ReturnT<String> demoJobHandler(String param) throws Exception {    XxlJobLogger.log("XXL-JOB, Hello World.");    for (int i = 0; i < 5; i++) {        XxlJobLogger.log("beat at:" + i);        TimeUnit.SECONDS.sleep(2);    }    return ReturnT.SUCCESS;}/** * 2、分片播送工作 */@XxlJob("shardingJobHandler")public ReturnT<String> shardingJobHandler(String param) throws Exception {    // 分片参数    ShardingUtil.ShardingVO shardingVO = ShardingUtil.getShardingVo();    XxlJobLogger.log("分片参数：以后分片序号 = {}, 总分片数 = {}", shardingVO.getIndex(), shardingVO.getTotal());    // 业务逻辑    for (int i = 0; i < shardingVO.getTotal(); i++) {        if (i == shardingVO.getIndex()) {            XxlJobLogger.log("第 {} 片, 命中分片开始解决", i);        } else {            XxlJobLogger.log("第 {} 片, 疏忽", i);        }    }    return ReturnT.SUCCESS;}

}
复制代码
XXL-JOB 相较于 ElasticJob，最大的特点就是性能比拟丰盛，可运维能力比拟强，岂但反对控制台动态创建工作，还有调度日志、运行报表等性能。

XXL-JOB 的历史记录、运行报表和调度日志，都是基于数据库实现的：

由此能够看出，XXL-JOB 所有性能都依赖数据库，且调度核心不反对分布式架构，在任务量和调度量比拟大的状况下，会有性能瓶颈。不过如果对工作量级、高可用、监控报警、可视化