當我們的業務服務需要定時的執行業務接口時，我們就需要考慮引入定時任務，那么問題又來了，我們是選擇“分布式定時任務”呢，還是“本地Job”呢。

好吧，這里就從技術和架構的角度帶著大家一起看一下這個問題。

線程和線程池

熟悉線程和線程池的技術人都應該知道，使用它們是可以實現定時功能的。

RocketMQ中比較常見的定時任務的寫法，就是利用線程來實現的定時任務，也就是Thread類，說的簡單一點就是線程等待。

如下代碼的語義就是按照固定周期waitInterval去執行負載均衡。

@Override
public void run() {
    log.info(this.getServiceName() + " service started");
    while (!this.isStopped()) {
        this.waitForRunning(waitInterval);
        this.mqClientFactory.doRebalance();
    }
    log.info(this.getServiceName() + " service end");
}

RocketMQ中還有一種比較常見的定時任務的寫法就是用線程池來實現定時任務的，也就是ScheduledExecutorService類。

如下代碼的語義就是周期性的注冊Broker Server。

this.scheduledExecutorService.scheduleAtFixedRate(new Runnable() {
    @Override
    public void run() {
        try {
            BrokerController.this.registerBrokerAll(true, false, 
                brokerConfig.isForceRegister());
                } catch (Throwable e) {
                    log.error("registerBrokerAll Exception", e);
                }
            }
        }, 1000 * 10, Math.max(10000, Math.min(brokerConfig.
           getRegisterNameServerPeriod(), 60000)), TimeUnit.MILLISECONDS);

好吧，既然RocketMQ可以利用線程和線程池來完成定時任務，那么我們的業務服務也是可以的。

JDK自帶的定時器Timer和TimerTask

定時器Timer和TimerTask本質上也是線程實現的定時功能，所以說RocketMQ就直接使用線程和線程池來實現個性化的定時任務，人家那樣做也不是沒有道理。比如在RocketMQ的延遲消息就是使用TimerTask來實現的，當然使用定時器Timer和TimerTask會存在很多缺陷，比如沒有分布式調度的功能，不能確保分布式環境下執行Job的數據一致性等，但是人家RocketMQ不需要考慮這樣的場景，它的分布式問題利用其他的替代方式解決了，比如集群選舉等。

Spring Framework自帶的定時器

熟悉Spring Framework框架的技術人應該知道，可以使用注解@EnableScheduling和@Scheduled就可以開啟一個定時任務，我們可以這樣寫一個定時器。

@Component
@EnableScheduling
public class SimulatingMultithreadedOrder {
    @Scheduled(fixedRate = 2000)
    public void producerMessage() throws MQClientException {
        //定時執行的邏輯
    }
}

使用Spring Framework框架自帶的本地定時任務非常方便，如果你的基礎框架采用Spring Boot或者更加高級一點Spring Cloud Alibaba，你不需要添加額外的Jar包依賴，因為@EnableScheduling和@Scheduled是Spring Context提供給我們的定時任務注解，只要你是Spring Framework生態的業務服務，你就可以使用它，非常的簡單。

Quartz

Quartz可以說是非常古老的定時任務框架，目前最新的版本為2.3.2，項目最近一次更新是2019年，也就是說處于停更狀態，不過這個不影響它的關注度，畢竟它是制定規范的。

看過Quartz底層源碼的技術人應該都知道，Quartz中大量使用了線程來實現定時任務的功能，比如執行任務的線程池和調度任務的線程池等。

xxl-job

筆者在很多年之前就已經接觸過xxl-job了，也是看著它成長起來的，該框架的作者也是非常的厲害，并且這個框架是個人維護到現在，如果我沒記錯的話應該有快10年了。

在Github上搜索xxl-job，目前Fork數為8.9k，Star 20.9k，這個成績已經超過了很多Apache頂級項目的數據了，目前它的最新版本為v2.3.0，社區活躍度還是非常活躍的。

xxl-job給自己的定位是分布式任務調度平臺，也就是說它不僅是要做定時任務，而是要做調度，這點就和云原生的理念不謀而合了。

關于xxl-job的原理大家可以參考官方https://github.com/xuxueli/xxl-job，分布式Job的原理其實不難，多實踐一下，看看源碼大致能知道它是如何完成調度的。

筆者也下載了它的源碼大致看了一下，其實它本質上也是用線程來實現的定時Job，只不過加了一些動態調度的規則而已，并且能夠做到非常優雅的和動態的殺死運行Job的線程，并完成線程Job的調度。

筆者當初關注過xxl-job，主要原因是它在那個版本把ZooKeeper去掉了，自己寫了一套分布式一致性的框架，具體是在哪個版本改進的，這里我大概忘記了。

Elastic-job

Elastic-job是Apache的頂級項目，目前已經改名為shardingsphere-elasticjob，具體數據如下。

shardingsphere-elasticjob和xxl-job一個最大的不同點在于，前者還是重度依賴ZooKeeper的，畢竟ZooKeeper也是Apache的項目，哈哈，肯定不會去掉的。

還有一個比較大的不同點就是shardingsphere-elasticjob的定時任務規范是依賴Quartz的二次開發的產品，而xxl-job是完全自己寫的。

目前shardingsphere-elasticjob最新的版本為3.0.1，社區活躍度是非常高的，如果大家對源碼感興趣可以下載相關源碼，https://github.com/apache/shardingsphere-elasticjob。

shardingsphere-elasticjob包含兩個部分：

• E lastic-Job-Lite 定位 為輕量級無中心化解決方案，使用 jar 包的形式提供分布式任務 的協調服務；
• Ela stic-Job-Cloud 使用 Mesos + Docker(TBD) 的解決方案，額外提供資源治理、應用分發以及進程隔離等服務。

Saturn

Saturn是唯品會在github開源的一款分布式任務調度產品。它是基于當當elastic-job 1.0版本來開發的，其上完善了一些功能和添加了一些新的feature。

Saturn目前最新的版本為v3.5.1，社區活躍度不是很高。

antares

Antares是一個完全自研的個人維護的定時任務框架。

Antares目前最新的版本為1.4.0，最近一次更新是2017年，幾乎處于停止維護狀態。

Spring Cloud Alibaba Cloud SchedulerX

SchedulerX（分布式任務調度） 是隸屬于阿里云EDAS產品的組件， Spring Cloud AliCloud SchedulerX 提供了在Spring Cloud的配置規范下，分布式任務調度的功能支持。SchedulerX可提供秒級、精準、高可靠、高可用的定時任務調度服務，并支持多種類型的任務調度，如簡單單機任務、簡單多機任務、腳本任務以及網格任務。

阿里巴巴并沒有開放Spring Cloud Alibaba Cloud SchedulerX的源碼，這個是一個硬傷，咱們只能使用阿里云的商業版本。

總之，不論是哪一種分布式定時Job，都會有它適用的業務場景，并沒有誰是絕對的好和絕對的不好，就像是RPC框架一樣，合適才是最重要的。優秀的框架的架構和設計思想是非常有用的，我們能夠把它學過來，并為自己所用也是一種能力的提升，畢竟咱們要先學會模仿，才能夠學會創新。