背景

業(yè)務(wù)場(chǎng)景

1. 定期執(zhí)行任務(wù)：如每天0點(diǎn)做資源稽查；

需求和痛點(diǎn)

1. 集群部署服務(wù)時(shí)，如何確保任務(wù)不被重復(fù)執(zhí)行？---最急迫

2. 如何監(jiān)控、告警等；

3. 高可用、無(wú)單點(diǎn)故障；

4. 優(yōu)秀的并行處理能力、分片能力；

自研 or 開源

任何工具的使用都要結(jié)合自身的業(yè)務(wù)場(chǎng)景，脫落業(yè)務(wù)場(chǎng)景談技術(shù)選型就是耍流氓。
考慮私有云場(chǎng)景業(yè)務(wù)量一般，高并發(fā)場(chǎng)景很少遇到，同一時(shí)間也不會(huì)有超大量定時(shí)任務(wù)同時(shí)需要執(zhí)行，所以考慮自研也未嘗不可。
目前自研最急需解決的問題并不是高并發(fā)，而是如何避免任務(wù)被重復(fù)執(zhí)行；
場(chǎng)景就變成了：

多個(gè)應(yīng)用在同一個(gè)時(shí)間都嘗試去執(zhí)行任務(wù)，但最終只有一個(gè)應(yīng)用真正執(zhí)行。

這樣的話，立馬就會(huì)讓人聯(lián)想到使用鎖去解決，因?yàn)槭嵌鄠€(gè)應(yīng)用，所以就是分布式鎖。那么，場(chǎng)景又變了：

多個(gè)應(yīng)用在同一個(gè)時(shí)間都嘗試去獲取分布式鎖，只有一個(gè)應(yīng)用能搶到這把鎖，搶到鎖的應(yīng)用可以執(zhí)行定時(shí)任務(wù)，其他應(yīng)用則直接放棄，等待下一次執(zhí)行時(shí)間。

搶鎖的時(shí)機(jī)是每次定時(shí)任務(wù)執(zhí)行之前，這又讓我聯(lián)想到了AOP，那么利用注解也就順理成章了。

下面的 ShedLock就是基于AOP + 注解的思想。

ShedLock

與Spring的集成挺方便；

Distributed lock for your scheduled tasks

Github: start: 1K  Fork: 192，最近一次代碼提交 6months ago

ShedLock makes sure that your scheduled tasks are executed at most once at the same time. If a task is being executed on one node, it acquires a lock which prevents execution of the same task from another node (or thread). Please note, that if one task is already being executed on one node, execution on other nodes does not wait, it is simply skipped.

ShedLock uses external store like Mongo, JDBC database, Redis, Hazelcast, ZooKeeper or others for coordination.

ShedLock is not a distributed scheduler

Please note that ShedLock is not and will never be full-fledged scheduler, it's just a lock. If you need a distributed scheduler, please use another project. ShedLock is designed to be used in situations where you have scheduled tasks that are not ready to be executed in parallel, but can be safely executed repeatedly.

重要信息：

1. ShedLock可使用MongoDB、JDBC-DB、Redis或Zookeeper等來實(shí)現(xiàn)分布式鎖，具體采用哪種方式，由使用者決定；

2. 它僅僅是一個(gè)分布式鎖，并不是調(diào)度程序；

與Spring的集成很簡(jiǎn)單（官方文檔的示例，自己并未測(cè)試過），示例：

假設(shè)一個(gè)task每15分鐘執(zhí)行一次，每次運(yùn)行的時(shí)間都不是很長(zhǎng)（即：應(yīng)該在15min分鐘內(nèi)可以運(yùn)行完），更重要的是，不管起多少個(gè)實(shí)例，都只希望在15分鐘內(nèi)該任務(wù)有且只被運(yùn)行一次！

//示例：與Spring的原生注解 @Scheduled配合使用
import net.javacrumbs.shedlock.core.SchedulerLock;

@Scheduled(cron = "0 */15 * * * *")//每15分鐘運(yùn)行一次
@SchedulerLock(name = "scheduledTaskName", lockAtMostFor = "14m", lockAtLeastFor = "14m")
public void scheduledTask() {
   // do something
}
//lockAtMostFor : 表示最多鎖定14分鐘，主要用于防止執(zhí)行任務(wù)的節(jié)點(diǎn)掛掉（即使這個(gè)節(jié)點(diǎn)掛掉，在14分鐘后，鎖也被釋放），一般將其設(shè)置為明顯大于任務(wù)的最大執(zhí)行時(shí)長(zhǎng)；如果任務(wù)運(yùn)行時(shí)間超過該值（即任務(wù)14分鐘沒有執(zhí)行完），則該任務(wù)可能被重復(fù)執(zhí)行！
//lockAtLeastFor : 至少鎖定時(shí)長(zhǎng)，確保在15分鐘內(nèi)，該任務(wù)不會(huì)運(yùn)行超過1次；

額外補(bǔ)充一句，關(guān)于 @Scheduled的一些不注意的細(xì)節(jié)（單線程執(zhí)行），需要特別注意：SpringTask實(shí)現(xiàn)定時(shí)任務(wù)

Configure LockProvider

使用JdbcTemplete來實(shí)現(xiàn)分布式鎖

CREATE TABLE shedlock(
    name VARCHAR(64),
    lock_until TIMESTAMP(3) NULL,
    locked_at TIMESTAMP(3) NULL,
    locked_by  VARCHAR(255),
    PRIMARY KEY (name)
)

依賴

<dependency>
    <groupId>net.javacrumbs.shedlock</groupId>
    <artifactId>shedlock-provider-jdbc-template</artifactId>
    <version>4.5.1</version>
</dependency>

配置

import net.javacrumbs.shedlock.provider.jdbctemplate.JdbcTemplateLockProvider;

...

@Bean
public LockProvider lockProvider(DataSource dataSource) {
    return new JdbcTemplateLockProvider(dataSource);
}

@Bean
    public ScheduledLockConfiguration scheduledLockConfiguration(LockProvider lockProvider) {
        return ScheduledLockConfigurationBuilder
                .withLockProvider(lockProvider)
                .withPoolSize(10)
                .withDefaultLockAtMostFor(Duration.ofMinutes(10))
                .build();
    }

基于Piston的思路（異步監(jiān)控），重寫一個(gè)

todo

思路：

1. 還是基于Innodb引擎的行鎖；

2. 狀態(tài)：應(yīng)該基于調(diào)度時(shí)間去判斷狀態(tài)；

選型參考

1. 簡(jiǎn)單、易上手；

2. 額外依賴較少，比如是否需要依賴MQ、Zookeeper等；

3. 是否方便集成；

開源產(chǎn)品對(duì)比

開源產(chǎn)品：任務(wù)調(diào)度系統(tǒng)匯總

Quartz

Java事實(shí)上的定時(shí)任務(wù)標(biāo)準(zhǔn)。但Quartz關(guān)注點(diǎn)在于定時(shí)任務(wù)而非數(shù)據(jù)，并無(wú)一套根據(jù)數(shù)據(jù)處理而定制化的流程。雖然Quartz可以基于數(shù)據(jù)庫(kù)實(shí)現(xiàn)作業(yè)的高可用，但缺少分布式并行調(diào)度的功能

原理

獨(dú)立的Quratz節(jié)點(diǎn)之間是不需要通信的，不同節(jié)點(diǎn)之間是通過數(shù)據(jù)庫(kù)表來感知另一個(gè)應(yīng)用，只有使用持久的JobStore才能完成Quartz集群。如果某一個(gè)節(jié)點(diǎn)失效，那么Job會(huì)在其他節(jié)點(diǎn)上執(zhí)行。

如何保證只在一臺(tái)機(jī)器上觸發(fā)？

• 數(shù)據(jù)庫(kù)悲觀鎖

• 一旦某一節(jié)點(diǎn)線程獲取了該鎖，那么Job就會(huì)在這臺(tái)機(jī)器上被執(zhí)行，其他節(jié)點(diǎn)進(jìn)行鎖等待；

缺點(diǎn)

1. 不適合大量的短任務(wù) & 不適合過多節(jié)點(diǎn)部署；

2. 解決了高可用的問題，并沒有解決任務(wù)分片的問題，存在單機(jī)處理的極限（即：不能實(shí)現(xiàn)水平擴(kuò)展）。

3. 需要把任務(wù)信息持久化到業(yè)務(wù)數(shù)據(jù)表，和業(yè)務(wù)有耦合

4. 調(diào)度邏輯和執(zhí)行邏輯并存于同一個(gè)項(xiàng)目中，在機(jī)器性能固定的情況下，業(yè)務(wù)和調(diào)度之間不可避免地會(huì)相互影響。

5. quartz集群模式下，是通過數(shù)據(jù)庫(kù)獨(dú)占鎖來唯一獲取任務(wù)，任務(wù)執(zhí)行并沒有實(shí)現(xiàn)完善的負(fù)載均衡機(jī)制。

Elastic-Job

官方文檔

GitHub: star 5.7K Fork:2.6K

Elastic-Job is a distributed scheduled job framework, based on Quartz and Zookeeper

Elastic Job是當(dāng)當(dāng)網(wǎng)架構(gòu)師開發(fā)，是一個(gè)分布式調(diào)度解決方案，由兩個(gè)相互獨(dú)立的子項(xiàng)目Elastic-Job-Lite和Elastic-Job-Cloud組成；定位為輕量級(jí)無(wú)中心化解決方案，使用 jar 包的形式提供分布式任務(wù)的協(xié)調(diào)服務(wù)。支持分布式調(diào)度協(xié)調(diào)、彈性擴(kuò)容縮容、失效轉(zhuǎn)移、錯(cuò)過執(zhí)行作業(yè)重觸發(fā)、并行調(diào)度、自診斷和修復(fù)等等功能特性。

Elastic-Job-Lite定位為輕量級(jí)無(wú)中心化解決方案，使用jar包的形式提供分布式任務(wù)的協(xié)調(diào)服務(wù)；Elastic-Job-Cloud采用自研Mesos Framework的解決方案，額外提供資源治理、應(yīng)用分發(fā)以及進(jìn)程隔離等功能；

Elastic-Job-Lite并沒有宿主程序，而是基于部署作業(yè)框架的程序在到達(dá)相應(yīng)時(shí)間點(diǎn)時(shí)各自觸發(fā)調(diào)度。它的開發(fā)也比較簡(jiǎn)單，引用Jar包實(shí)現(xiàn)一些方法即可，最后編譯成Jar包運(yùn)行。Elastic-Job-Lite的分布式部署全靠ZooKeeper來同步狀態(tài)和原數(shù)據(jù)。實(shí)現(xiàn)高可用的任務(wù)只需將分片總數(shù)設(shè)置為1，并把開發(fā)的Jar包部署于多個(gè)服務(wù)器上執(zhí)行，任務(wù)將會(huì)以1主N從的方式執(zhí)行。一旦本次執(zhí)行任務(wù)的服務(wù)器崩潰，其他執(zhí)行任務(wù)的服務(wù)器將會(huì)在下次作業(yè)啟動(dòng)時(shí)選擇一個(gè)替補(bǔ)執(zhí)行。如果開啟了失效轉(zhuǎn)移，那么功能效果更好，可以保證在本次作業(yè)執(zhí)行時(shí)崩潰，備機(jī)之一立即啟動(dòng)替補(bǔ)執(zhí)行。

Elastic-Job-Lite的任務(wù)分片也是通過ZooKeeper來實(shí)現(xiàn)，Elastic-Job并不直接提供數(shù)據(jù)處理的功能，框架只會(huì)將分片項(xiàng)分配至各個(gè)運(yùn)行中的作業(yè)服務(wù)器，開發(fā)者需要自行處理分片項(xiàng)與真實(shí)數(shù)據(jù)的對(duì)應(yīng)關(guān)系?？蚣芤差A(yù)置了一些分片策略：平均分配算法策略，作業(yè)名哈希值奇偶數(shù)算法策略，輪轉(zhuǎn)分片策略。同時(shí)也提供了自定義分片策略的接口。

另外Elastic-Job-Lite還提供了一個(gè)任務(wù)監(jiān)控和管理界面：Elastic-Job-Lite-Console。它和Elastic-Job-Lite是兩個(gè)完全不關(guān)聯(lián)的應(yīng)用程序，使用ZooKeeper來交換數(shù)據(jù)，管理人員可以通過這個(gè)界面查看、監(jiān)控和管理Elastic-Job-Lite的任務(wù)，必要的時(shí)候還能手動(dòng)觸發(fā)任務(wù)

功能列表

• 分布式調(diào)度協(xié)調(diào)

• 彈性擴(kuò)容縮容

• 失效轉(zhuǎn)移

• 錯(cuò)過執(zhí)行作業(yè)重觸發(fā)

• 作業(yè)分片一致性，保證同一分片在分布式環(huán)境中僅一個(gè)執(zhí)行實(shí)例

• 自診斷并修復(fù)分布式不穩(wěn)定造成的問題

• 支持并行調(diào)度

• 支持作業(yè)生命周期操作

• 豐富的作業(yè)類型

• Spring整合以及命名空間提供

• 運(yùn)維平臺(tái)

優(yōu)缺點(diǎn)

優(yōu)點(diǎn)：

• 基于成熟的定時(shí)任務(wù)作業(yè)框架Quartz cron表達(dá)式執(zhí)行定時(shí)任務(wù)；

• 支持任務(wù)分片：可以拆分任務(wù)，分別由不同節(jié)點(diǎn)執(zhí)行；

• 官網(wǎng)文檔齊全，全中文；

• 彈性擴(kuò)容縮容：運(yùn)行中的作業(yè)服務(wù)器崩潰，或新增N臺(tái)作業(yè)服務(wù)器，作業(yè)框架將在下次作業(yè)執(zhí)行前重新分片，不影響當(dāng)前作業(yè)執(zhí)行；

• 任務(wù)監(jiān)控和管理界面；

缺點(diǎn)：

• 依賴Zookeeper；

XXL-JOB

官方文檔

GitHub: star: 12.9K  Fork:5.5K

使用該框架的公司：>300家

XXL-Job官網(wǎng)是大眾點(diǎn)評(píng)員工徐雪里于2015年發(fā)布的分布式任務(wù)調(diào)度平臺(tái)，其核心設(shè)計(jì)目標(biāo)是開發(fā)迅速、學(xué)習(xí)簡(jiǎn)單、輕量級(jí)、易擴(kuò)展。現(xiàn)已開放源代碼并接入多家公司線上產(chǎn)品線，開箱即用。

設(shè)計(jì)思想

將調(diào)度行為抽象形成“調(diào)度中心”公共平臺(tái)，而平臺(tái)自身并不承擔(dān)業(yè)務(wù)邏輯，“調(diào)度中心”負(fù)責(zé)發(fā)起調(diào)度請(qǐng)求。

將任務(wù)抽象成分散的JobHandler，交由“執(zhí)行器”統(tǒng)一管理，“執(zhí)行器”負(fù)責(zé)接收調(diào)度請(qǐng)求并執(zhí)行對(duì)應(yīng)的JobHandler中業(yè)務(wù)邏輯。

因此，“調(diào)度”和“任務(wù)”兩部分可以相互解耦，提高系統(tǒng)整體穩(wěn)定性和擴(kuò)展性；

系統(tǒng)組成

• 調(diào)度模塊（調(diào)度中心）：
  負(fù)責(zé)管理調(diào)度信息，按照調(diào)度配置發(fā)出調(diào)度請(qǐng)求，自身不承擔(dān)業(yè)務(wù)代碼。調(diào)度系統(tǒng)與任務(wù)解耦，提高了系統(tǒng)可用性和穩(wěn)定性，同時(shí)調(diào)度系統(tǒng)性能不再受限于任務(wù)模塊；
  支持可視化、簡(jiǎn)單且動(dòng)態(tài)的管理調(diào)度信息，包括任務(wù)新建，更新，刪除，GLUE開發(fā)和任務(wù)報(bào)警等，所有上述操作都會(huì)實(shí)時(shí)生效，同時(shí)支持監(jiān)控調(diào)度結(jié)果以及執(zhí)行日志，支持執(zhí)行器Failover。

• 執(zhí)行模塊（執(zhí)行器）：
  負(fù)責(zé)接收調(diào)度請(qǐng)求并執(zhí)行任務(wù)邏輯。任務(wù)模塊專注于任務(wù)的執(zhí)行等操作，開發(fā)和維護(hù)更加簡(jiǎn)單和高效；
  接收“調(diào)度中心”的執(zhí)行請(qǐng)求、終止請(qǐng)求和日志請(qǐng)求等。

---

其他

uncode-schedule

基于zookeeper，比較小眾，不推薦

基于zookeeper+spring task/quartz的分布式任務(wù)調(diào)度組件，確保所有任務(wù)在集群中不重復(fù)，不遺漏的執(zhí)行。支持動(dòng)態(tài)添加和刪除任務(wù)。

LTS

最近一次更新在2年前，目前不是很活躍；也比較小眾，不推薦

light-task-scheduler

LTS(light-task-scheduler)主要用于解決分布式任務(wù)調(diào)度問題，支持實(shí)時(shí)任務(wù)，定時(shí)任務(wù)和Cron任務(wù)。有較好的伸縮性，擴(kuò)展性；

TBSchedule

阿里早期開源的分布式任務(wù)調(diào)度系統(tǒng)。代碼略陳舊，使用timer而非線程池執(zhí)行任務(wù)調(diào)度。眾所周知，timer在處理異常狀況時(shí)是有缺陷的。而且TBSchedule作業(yè)類型較為單一，只能是獲取/處理數(shù)據(jù)一種模式。還有就是文檔缺失比較嚴(yán)重。

依賴Zookeeper；

代碼太久沒更新

TBSchedule是一款非常優(yōu)秀的高性能分布式調(diào)度框架，廣泛應(yīng)用于阿里巴巴、淘寶、支付寶、京東、聚美、汽車之家、國(guó)美等很多互聯(lián)網(wǎng)企業(yè)的流程調(diào)度系統(tǒng)。tbschedule在時(shí)間調(diào)度方面雖然沒有quartz強(qiáng)大，但是它支持分片功能。和quartz不同的是，tbschedule使用ZooKeeper來實(shí)現(xiàn)任務(wù)調(diào)度的高可用和分片。

TBSchedule的分布式機(jī)制是通過靈活的Sharding方式實(shí)現(xiàn)的，分片的規(guī)則由客戶端決定，比如可以按所有數(shù)據(jù)的ID按10取模分片、按月份分片等等。TBSchedule的宿主服務(wù)器可以進(jìn)行動(dòng)態(tài)擴(kuò)容和資源回收，這個(gè)特點(diǎn)主要是因?yàn)樗蠖艘蕾嚨腪ooKeeper，這里的ZooKeeper對(duì)于TBSchedule來說是一個(gè)NoSQL，用于存儲(chǔ)策略、任務(wù)、心跳信息數(shù)據(jù)，它的數(shù)據(jù)結(jié)構(gòu)類似文件系統(tǒng)的目錄結(jié)構(gòu)，它的節(jié)點(diǎn)有臨時(shí)節(jié)點(diǎn)、持久節(jié)點(diǎn)之分。調(diào)度引擎啟動(dòng)后，隨著業(yè)務(wù)量數(shù)據(jù)量的增多，當(dāng)前Cluster可能不能滿足目前的處理需求，那么就需要增加服務(wù)器數(shù)量，一個(gè)新的服務(wù)器上線后會(huì)在ZooKeeper中創(chuàng)建一個(gè)代表當(dāng)前服務(wù)器的一個(gè)唯一性路徑（臨時(shí)節(jié)點(diǎn)），并且新上線的服務(wù)器會(huì)和ZooKeeper保持長(zhǎng)連接，當(dāng)通信斷開后，節(jié)點(diǎn)會(huì)自動(dòng)摘除。

TBSchedule會(huì)定時(shí)掃描當(dāng)前服務(wù)器的數(shù)量，重新進(jìn)行任務(wù)分配。TBSchedule不僅提供了服務(wù)端的高性能調(diào)度服務(wù)，還提供了一個(gè)scheduleConsole的war包，隨著宿主應(yīng)用的部署直接部署到服務(wù)器，可以通過web的方式對(duì)調(diào)度的任務(wù)、策略進(jìn)行監(jiān)控管理，以及實(shí)時(shí)更新調(diào)整。

Saturn

Saturn是唯品會(huì)在github開源的一款分布式任務(wù)調(diào)度產(chǎn)品。它是基于當(dāng)當(dāng)elastic-job 1.0版本來開發(fā)的，其上完善了一些功能和添加了一些新的feature。

亮點(diǎn)：

支持多語(yǔ)言開發(fā) python、Go、Shell、Java、Php。

管理控制臺(tái)和數(shù)據(jù)統(tǒng)計(jì)分析更加完善

缺點(diǎn)：

技術(shù)文檔較少 ， 該框架是2016年由唯品會(huì)的研發(fā)團(tuán)隊(duì)基于elastic-job開發(fā)而來

Opencron

比較小眾，不推薦

Antares

Antares 是一款基于 Quartz 機(jī)制的分布式任務(wù)調(diào)度管理平臺(tái)，內(nèi)部重寫執(zhí)行邏輯，一個(gè)任務(wù)僅會(huì)被服務(wù)器集群中的某個(gè)節(jié)點(diǎn)調(diào)度。用戶可通過對(duì)任務(wù)預(yù)分片，有效提升任務(wù)執(zhí)行效率；也可通過控制臺(tái) antares-tower 對(duì)任務(wù)進(jìn)行基本操作，如觸發(fā)，暫停，監(jiān)控等。

Antares 是基于 Quartz 的分布式調(diào)度，支持分片，支持樹形任務(wù)依賴，但是不是跨平臺(tái)的

sia-task

沒有仔細(xì)研究，依賴Zookeeper，感覺更偏向于解決編排和跨平臺(tái)

無(wú)論是互聯(lián)網(wǎng)應(yīng)用或者企業(yè)級(jí)應(yīng)用，都充斥著大量的批處理任務(wù)。我們常常需要一些任務(wù)調(diào)度系統(tǒng)幫助我們解決問題。隨著微服務(wù)化架構(gòu)的逐步演進(jìn)，單體架構(gòu)逐漸演變?yōu)榉植际?、微服?wù)架構(gòu)。在此的背景下，很多原先的任務(wù)調(diào)度平臺(tái)已經(jīng)不能滿足業(yè)務(wù)系統(tǒng)的需求。于是出現(xiàn)了一些基于分布式的任務(wù)調(diào)度平臺(tái)。這些平臺(tái)各有其特點(diǎn)，但各有不足之處，比如不支持任務(wù)編排、與業(yè)務(wù)高耦合、不支持跨平臺(tái)等問題。不是非常符合公司的需求，因此我們開發(fā)了微服務(wù)任務(wù)調(diào)度平臺(tái)（SIA-TASK）。

SIA是我們公司基礎(chǔ)開發(fā)平臺(tái)Simple is Awesome的簡(jiǎn)稱，SIA-TASK（微服務(wù)任務(wù)調(diào)度平臺(tái)）是其中的一項(xiàng)重要產(chǎn)品，SIA-TASK契合當(dāng)前微服務(wù)架構(gòu)模式，具有跨平臺(tái)，可編排，高可用，無(wú)侵入，一致性，異步并行，動(dòng)態(tài)擴(kuò)展，實(shí)時(shí)監(jiān)控等特點(diǎn)。

對(duì)比和結(jié)論

XXL-Job 側(cè)重的業(yè)務(wù)實(shí)現(xiàn)的簡(jiǎn)單和管理的方便，學(xué)習(xí)成本簡(jiǎn)單，失敗策略和路由策略豐富。推薦使用在“用戶基數(shù)相對(duì)少，服務(wù)器數(shù)量在一定范圍內(nèi)”的情景下使用
Elastic-Job 關(guān)注的是數(shù)據(jù)，增加了彈性擴(kuò)容和數(shù)據(jù)分片的思路，以便于更大限度的利用分布式服務(wù)器的資源。但是學(xué)習(xí)成本相對(duì)高些，推薦在“數(shù)據(jù)量龐大，且部署服務(wù)器數(shù)量較多”時(shí)使用

對(duì)于并發(fā)場(chǎng)景不是特別高的系統(tǒng)來說，xxl-job配置部署簡(jiǎn)單易用，不需要引入多余的組件，同時(shí)提供了可視化的控制臺(tái)，使用起來非常友好，是一個(gè)比較好的選擇。

Elastic-Job

這個(gè)框架大概在2年前很火，當(dāng)時(shí)使用的公司很多，想必很多人也聽過了，但是很可惜現(xiàn)在已經(jīng)不在維護(hù)了，代碼已經(jīng)有2年沒有更新了，這里違反了更新頻率的原則，如果出現(xiàn)問題可能都沒什么人幫助你，所以并不是很推薦使用。

更傾向于選擇XXL-JOB：

1. 輕量級(jí)，支持通過Web頁(yè)面對(duì)任務(wù)進(jìn)行動(dòng)態(tài)CRUD操作，操作簡(jiǎn)單

2. 只依賴數(shù)據(jù)庫(kù)作為集群注冊(cè)中心，接入開發(fā)簡(jiǎn)單，不需要ZK

3. 高可用、解耦、高性能、監(jiān)控報(bào)警、分片、重試、故障轉(zhuǎn)移

4. 團(tuán)隊(duì)持續(xù)開發(fā)，社區(qū)活躍

5. 支持后臺(tái)直接查看每個(gè)任務(wù)執(zhí)行實(shí)時(shí)日志，ELASTIC-JOB中應(yīng)該是沒有這個(gè)功能

ShedLock集成更簡(jiǎn)單，如果驗(yàn)證通過，也未必不是一個(gè)好選擇！

其他

中心化調(diào)度 vs 去中心化調(diào)度

	中心化	去中心化
實(shí)現(xiàn)難度	高	低
部署難度	高	低
觸發(fā)時(shí)間統(tǒng)一控制	可以	不可以
觸發(fā)延遲	有	無(wú)
異構(gòu)語(yǔ)言支持	容易	不容易

中心化調(diào)度

• XXL-Job：有調(diào)度中心；

去中心化調(diào)度

• Quartz

• Elastic-Job：實(shí)現(xiàn)時(shí)，就是基于Quartz的基于數(shù)據(jù)庫(kù)的分布式思想；

參考

XXL-JOB 和 Elastic-Job對(duì)比

分布式定時(shí)任務(wù)調(diào)度框架實(shí)踐

source:https://www.yuque.com/ssslinppp/blogs/bvlz5y

喜歡，在看