閱覽一篇「守時使命結(jié)構(gòu)選型」的文章時，一位網(wǎng)友的留言電到了我：

我看過那么多所謂的教程，大部分都是教“怎么運用東西”的，沒有多少是教“怎么制造東西”的，能教“怎么拷貝東西”的都現(xiàn)已是百里挑一，我國 軟件行業(yè)，缺的是真正能夠“制造東西”的程序員，而絕對不缺那些“運用東西”的程序員！ ...... ”這個業(yè)界最不需求的便是“會運用XX東西的工程師”，而是“有創(chuàng)造力的軟件工程師”！業(yè)界所有的飯碗，實質(zhì)便是“有創(chuàng)造力的軟件工程師”供給出來的??！

寫這篇文章，想和大家從頭到腳說說使命調(diào)度，期望大家讀完之后，能夠了解完成一個使命調(diào)度體系的中心邏輯。

1 Quartz

Quartz是一款Java開源使命調(diào)度結(jié)構(gòu)，也是許多Java工程師觸摸使命調(diào)度的起點。

下圖顯現(xiàn)了使命調(diào)度的全體流程：

Quartz的中心是三個組件。

• 使命：Job 用于表明被調(diào)度的使命；
• 觸發(fā)器：Trigger 界說調(diào)度時刻的元素，即依照什么時刻規(guī)矩去履行使命。一個Job能夠被多個Trigger相關(guān)，可是一個Trigger 只能相關(guān)一個Job；
• 調(diào)度器 ：工廠類創(chuàng)立Scheduler，依據(jù)觸發(fā)器界說的時刻規(guī)矩調(diào)度使命。

上圖代碼中Quartz 的JobStore是 RAMJobStore，Trigger 和 Job 存儲在內(nèi)存中。

履行使命調(diào)度的中心類是 QuartzSchedulerThread 。

1. 調(diào)度線程從JobStore中獲取需求履行的的觸發(fā)器列表，并修正觸發(fā)器的狀況；
2. Fire觸發(fā)器，修正觸發(fā)器信息(下次履行觸發(fā)器的時刻，以及觸發(fā)器狀況），并存儲起來。
3. 最終創(chuàng)立詳細(xì)的履行使命目標(biāo)，經(jīng)過worker線程池履行使命。

接下來再聊聊 Quartz 的集群布置計劃。

Quartz的集群布置計劃，需求針對不同的數(shù)據(jù)庫類型(MySQL , ORACLE) 在數(shù)據(jù)庫實例上創(chuàng)立Quartz表，JobStore是: JobStoreSupport 。

這種計劃是分布式的，沒有擔(dān)任會集辦理的節(jié)點，而是利用數(shù)據(jù)庫行級鎖的方式來完成集群環(huán)境下的并發(fā)操控。

scheduler實例在集群方式下首要獲取{0}LOCKS表中的行鎖，Mysql 獲取行鎖的句子：

{0}會替換為裝備文件默許裝備的QRTZ_。sched_name為運用集群的實例名，lock_name便是行級鎖名。Quartz主要有兩個行級鎖觸發(fā)器拜訪鎖 (TRIGGER_ACCESS) 和 狀況拜訪鎖（STATE_ACCESS）。

這個架構(gòu)處理了使命的分布式調(diào)度問題，同一個使命只能有一個節(jié)點運轉(zhuǎn)，其他節(jié)點將不履行使命，當(dāng)碰到許多短使命時，各個節(jié)點頻頻的競賽數(shù)據(jù)庫鎖，節(jié)點越多功用就會越差。

2 分布式鎖方式

Quartz的集群方式能夠水平擴展，也能夠分布式調(diào)度，但需求事務(wù)方在數(shù)據(jù)庫中增加對應(yīng)的表，有必定的強侵入性。

有不少研發(fā)同學(xué)為了防止這種侵入性，也探究出分布式鎖方式。

事務(wù)場景：電商項目，用戶下單后一段時刻沒有付款，體系就會在超時后封閉該訂單。

一般咱們會做一個守時使命每兩分鐘來檢查前半小時的訂單，將沒有付款的訂單列表查詢出來，然后對訂單中的商品進行庫存的恢復(fù)，然后將該訂單設(shè)置為無效。

咱們運用Spring Schedule的方式做一個守時使命。

@Scheduled(cron = "0 */2 * * * ? ") public void doTask() {
   log.info("守時使命發(fā)動"); //履行封閉訂單的操作 orderService.closeExpireUnpayOrders();
   log.info("守時使命完畢");
 }

在單服務(wù)器運轉(zhuǎn)正常，考慮到高可用，事務(wù)量激增，架構(gòu)會演進成集群方式，在同一時刻有多個服務(wù)履行一個守時使命，有可能會導(dǎo)致事務(wù)紊亂。

處理計劃是在使命履行的時分，運用Redis 分布式鎖來處理這類問題。

@Scheduled(cron = "0 */2 * * * ? ") public void doTask() {
    log.info("守時使命發(fā)動");
    String lockName = "closeExpireUnpayOrdersLock";
    RedisLock redisLock = redisClient.getLock(lockName); //嘗試加鎖，最多等候3秒，上鎖今后5分鐘主動解鎖 boolean locked = redisLock.tryLock(3, 300, TimeUnit.SECONDS); if(!locked){
        log.info("沒有獲得分布式鎖:{}" , lockName); return;
    } try{ //履行封閉訂單的操作 orderService.closeExpireUnpayOrders();
    } finally {
       redisLock.unlock();
    }
    log.info("守時使命完畢");
}

Redis的讀寫功用極好，分布式鎖也比Quartz數(shù)據(jù)庫行級鎖更輕量級。當(dāng)然Redis鎖也能夠替換成Zookeeper鎖，也是同樣的機制。

在小型項目中，運用：守時使命結(jié)構(gòu)（Quartz/Spring Schedule）和 分布式鎖（redis/zookeeper）有不錯的效果。

可是呢？咱們能夠發(fā)現(xiàn)這種組合有兩個問題：

1. 守時使命在分布式場景下有空跑的狀況，并且使命也無法做到分片；
2. 要想手藝觸發(fā)使命，必須增加額外的代碼才能完結(jié)。

3 ElasticJob-Lite 結(jié)構(gòu)

ElasticJob-Lite 定位為輕量級無中心化處理計劃，運用 jar 的方式供給分布式使命的和諧服務(wù)。

運用內(nèi)部界說使命類，完成SimpleJob接口，編寫自己使命的實際事務(wù)流程即可。

public class MyElasticJob implements SimpleJob {
    @Override public void execute(ShardingContext context) { switch (context.getShardingItem()) { case 0: // do something by sharding item 0 break; case 1: // do something by sharding item 1 break; case 2: // do something by sharding item 2 break; // case n: ... }
    }
}

舉例：運用A有五個使命需求履行，分別是A，B，C，D，E。使命E需求分紅四個子使命，運用布置在兩臺機器上。

運用A在發(fā)動后， 5個使命經(jīng)過 Zookeeper 和諧后被分配到兩臺機器上，經(jīng)過Quartz Scheduler 分開履行不同的使命。

ElasticJob 從實質(zhì)上來講 ，底層使命調(diào)度仍是經(jīng)過 Quartz ，比較Redis分布式鎖 或者 Quartz 分布式布置 ，它的優(yōu)勢在于能夠依靠 Zookeeper 這個大殺器 ，將使命經(jīng)過負(fù)載均衡算法分配給運用內(nèi)的 Quartz Scheduler容器。

從運用者的角度來講，是十分簡略易用的。但從架構(gòu)來看，調(diào)度器和履行器仍然在同一個運用方JVM內(nèi)，并且容器在發(fā)動后，仍然需求做負(fù)載均衡。運用假設(shè)頻頻的重啟，不斷的去選主，對分片做負(fù)載均衡，這些都是相對比較重的操作。

另外，ElasticJob 的操控臺是比較粗糙的，經(jīng)過讀取注冊中心數(shù)據(jù)展現(xiàn)作業(yè)狀況，更新注冊中心數(shù)據(jù)修正全局使命裝備。

4 中心化流派

中心化的原理是：把調(diào)度和使命履行，隔離成兩個部分：調(diào)度中心和履行器。調(diào)度中心模塊只需求擔(dān)任使命調(diào)度屬性，觸發(fā)調(diào)度指令。履行器接收調(diào)度指令，去履行詳細(xì)的事務(wù)邏輯，并且兩者都能夠進行分布式擴容。

4.1 MQ方式

先談?wù)勎以谒圐埓黉N團隊觸摸的第一種中心化架構(gòu)。

調(diào)度中心依靠Quartz集群方式，當(dāng)使命調(diào)度時分，發(fā)送音訊到RabbitMQ 。事務(wù)運用收到使命音訊后，消費使命信息。

這種模型充分利用了MQ解耦的特性，調(diào)度中心發(fā)送使命，運用方作為履行器的人物，接收使命并履行。

但這種規(guī)劃強依靠音訊隊列，可擴展性和功用，體系負(fù)載都和音訊隊列有極大的相關(guān)。這種架構(gòu)規(guī)劃需求架構(gòu)師對音訊隊列十分熟悉。

4.2 XXL-JOB

XXL-JOB 是一個分布式使命調(diào)度平臺，其中心規(guī)劃目標(biāo)是開發(fā)敏捷、學(xué)習(xí)簡略、輕量級、易擴展。現(xiàn)已開放源代碼并接入多家公司線上產(chǎn)品線，開箱即用。

咱們重點剖析下架構(gòu)圖 ：

▍ 網(wǎng)絡(luò)通訊 server-worker 模型

調(diào)度中心和履行器 兩個模塊之間通訊是 server-worker 方式。調(diào)度中心本身便是一個SpringBoot 工程，發(fā)動會監(jiān)聽8080端口。

履行器發(fā)動后，會發(fā)動內(nèi)置服務(wù)（ EmbedServer ）監(jiān)聽9994端口。這樣兩邊都能夠給對方發(fā)送指令。

那調(diào)度中心怎么知道履行器的地址信息呢 ？上圖中，履行器會守時發(fā)送注冊指令 ，這樣調(diào)度中心就能夠獲取在線的履行器列表。

經(jīng)過履行器列表，就能夠依據(jù)使命裝備的路由策略挑選節(jié)點履行使命。常見的路由策略有如下三種：

• 隨機節(jié)點履行：挑選集群中一個可用的履行節(jié)點履行調(diào)度使命。適用場景：離線訂單結(jié)算。

• 廣播履行：在集群中所有的履行節(jié)點分發(fā)調(diào)度使命并履行。適用場景：批量更新運用本地緩存。

  

• 分片履行：依照用戶自界說分片邏輯進行拆分，分發(fā)到集群中不同節(jié)點并行履行，提升資源利用效率。適用場景：海量日志統(tǒng)計。

▍ 調(diào)度器

調(diào)度器是使命調(diào)度體系里邊十分中心的組件。XXL-JOB 的早期版別是依靠Quartz。

但在v2.1.0版別中徹底去掉了Quartz的依靠，原來需求創(chuàng)立的 Quartz表也替換成了自研的表。

中心的調(diào)度類是：JobTriggerPoolHelper 。調(diào)用start辦法后，會發(fā)動兩個線程：scheduleThread 和 ringThread 。

首要 scheduleThread 會守時從數(shù)據(jù)庫加載需求調(diào)度的使命，這里從實質(zhì)上仍是根據(jù)數(shù)據(jù)庫行鎖確保一同只有一個調(diào)度中心節(jié)點觸發(fā)使命調(diào)度。

Connection conn = XxlJobAdminConfig.getAdminConfig()
                  .getDataSource().getConnection();
connAutoCommit = conn.getAutoCommit();
conn.setAutoCommit(false);
preparedStatement = conn.prepareStatement( "select * from xxl_job_lock where lock_name = 'schedule_lock' for update");
preparedStatement.execute();
# 觸發(fā)使命調(diào)度 (偽代碼) for (XxlJobInfo jobInfo: scheduleList) { // 省掉代碼 }
# 事務(wù)提交
conn.commit();

調(diào)度線程會依據(jù)使命的「下次觸發(fā)時刻」，采取不同的動作：

已過期的使命需求馬上履行的，直接放入線程池中觸發(fā)履行 ，五秒內(nèi)需求履行的使命放到 ringData 目標(biāo)里。

ringThread 發(fā)動后，守時從 ringData 目標(biāo)里獲取需求履行的使命列表 ，放入到線程池中觸發(fā)履行。

5 自研在巨人的肩膀上

2018年，我有一段自研使命調(diào)度體系的經(jīng)歷。

背景是：兼容技能團隊自研的RPC結(jié)構(gòu)，技能團隊不需求修正代碼，RPC注解辦法能夠托管在使命調(diào)度體系中，直接當(dāng)做一個使命來履行。

自研過程中，研讀了XXL-JOB 源碼，一同從阿里云分布式使命調(diào)度 SchedulerX 吸取了許多養(yǎng)分。

• Schedulerx-console 是使命調(diào)度的操控臺，用于創(chuàng)立、辦理守時使命。擔(dān)任數(shù)據(jù)的創(chuàng)立、修正和查詢。在產(chǎn)品內(nèi)部與 schedulerx-server 交互。
• Schedulerx-server 是使命調(diào)度的服務(wù)端，是 Scheduler的中心組件。擔(dān)任客戶端使命的調(diào)度觸發(fā)以及使命履行狀況的監(jiān)測。
• Schedulerx-client 是使命調(diào)度的客戶端。每個接入客戶端的運用進程便是一個的 Worker。 Worker 擔(dān)任與 schedulerx-server 建立通信，讓 schedulerx-server發(fā)現(xiàn)客戶端的機器。 并向schedulerx-server注冊當(dāng)前運用地點的分組，這樣 schedulerx-server 才能向客戶端守時觸發(fā)使命。

咱們模仿了SchedulerX的模塊，架構(gòu)規(guī)劃如下圖：

我挑選了 RocketMQ 源碼的通訊模塊 remoting 作為自研調(diào)度體系的通訊結(jié)構(gòu)。根據(jù)如下兩點：

1. 我對業(yè)界大名鼎鼎的 Dubbo不熟悉，而remoting我現(xiàn)已做了多個輪子，我信任自己能夠搞定；
2. 在閱覽 SchedulerX 1.0 client 源碼中，發(fā)現(xiàn) SchedulerX 的通訊結(jié)構(gòu)和RocketMQ Remoting許多地方都很類似。它的源碼里有現(xiàn)成的工程完成，徹底便是一個瑰寶。

我將 RocketMQ remoting 模塊去掉名字服務(wù)代碼，做了必定程度的定制。

在RocketMQ的remoting里，服務(wù)端選用 Processor 方式。

調(diào)度中心需求注冊兩個處理器：回調(diào)效果處理器CallBackProcessor和心跳處理器HeartBeatProcessor 。履行器需求注冊觸發(fā)使命處理器TriggerTaskProcessor 。

public void registerProcessor( int requestCode,
             NettyRequestProcessor processor,
             ExecutorService executor);

處理器的接口：

public interface NettyRequestProcessor { RemotingCommand processRequest(
                 ChannelHandlerContext ctx,
                 RemotingCommand request) throws Exception; boolean rejectRequest();
}

關(guān)于通訊結(jié)構(gòu)來講，我并不需求關(guān)注通訊細(xì)節(jié)，只需求完成處理器接口即可。

以觸發(fā)使命處理器TriggerTaskProcessor舉例：

搞定網(wǎng)絡(luò)通訊后，調(diào)度器怎么規(guī)劃 ？終究我仍是挑選了Quartz 集群方式。主要是根據(jù)以下幾點原因：

1. 調(diào)衡量不大的狀況下 ，Quartz 集群方式滿足安穩(wěn)，并且能夠兼容原來的XXL-JOB使命；
2. 運用時刻輪的話，本身沒有滿足的實踐經(jīng)驗，憂慮出問題。 另外，怎么讓使命經(jīng)過不同的調(diào)度服務(wù)（schedule-server）觸發(fā)， 需求有一個和諧器。于是想到Zookeeper。但這樣的話，又引進了新的組件。
3. 研發(fā)周期不能太長，想快點出效果。

自研版的調(diào)度服務(wù)花費一個半月上線了。體系運轉(zhuǎn)十分安穩(wěn)，研發(fā)團隊接入也很順利。 調(diào)衡量也不大 ，四個月一共挨近4000萬到5000萬之間的調(diào)衡量。

坦率的講，自研版的瓶頸，我的腦海里經(jīng)常能看到。 數(shù)據(jù)量大，我能夠搞定分庫分表，但 Quartz 集群根據(jù)行級鎖的方式 ，注定上限不會太高。

為了免除心中的困惑，我寫一個輪子DEMO看看可否work：

1. 去掉外置的注冊中心，調(diào)度服務(wù)（schedule-server）辦理會話；
2. 引進zookeeper，經(jīng)過zk和諧調(diào)度服務(wù)?？墒荋A機制很粗糙，相當(dāng)于一個使命調(diào)度服務(wù)運轉(zhuǎn)，另一個服務(wù)standby；
3. Quartz 替換成時刻輪 （參閱Dubbo里的時刻輪源碼）。

這個Demo版別在開發(fā)環(huán)境能夠運轉(zhuǎn)，但有許多細(xì)節(jié)需求優(yōu)化，僅僅是個玩具，并沒有時機運轉(zhuǎn)到出產(chǎn)環(huán)境。

最近讀阿里云的一篇文章《怎么經(jīng)過使命調(diào)度完成百萬規(guī)矩報警》，SchedulerX2.0 高可用架構(gòu)見下圖：

文章說到：

每個運用都會做三備份，經(jīng)過 zk 搶鎖，一主兩備，如果某臺 Server 掛了，會進行 failover，由其他 Server 接收調(diào)度使命。

這次自研使命調(diào)度體系從架構(gòu)來講，并不雜亂，完成了XXL-JOB的中心功用，也兼容了技能團隊的RPC結(jié)構(gòu)，但并沒有完成工作流以及mapreduce分片。

SchedulerX 在升級到2.0之后根據(jù)全新的Akka 架構(gòu)，這種架構(gòu)聲稱完成高功用工作流引擎，完成進程間通信，減少網(wǎng)絡(luò)通訊代碼。

在我調(diào)研的開源使命調(diào)度體系中，PowerJob也是根據(jù)Akka 架構(gòu)，一同也完成了工作流和MapReduce履行方式。

我對PowerJob十分感興趣，也會在學(xué)習(xí)實踐后輸出相關(guān)文章，敬請期待。

6 技能選型

首要咱們將使命調(diào)度開源產(chǎn)品和商業(yè)產(chǎn)品 SchedulerX 放在一同，生成一張對照表：

Quartz 和 ElasticJob從實質(zhì)上仍是歸于結(jié)構(gòu)的層面。

中心化產(chǎn)品從架構(gòu)上來講愈加清晰，調(diào)度層面更靈活，能夠支撐更雜亂的調(diào)度（mapreduce動態(tài)分片，工作流）。

XXL-JOB 從產(chǎn)品層面現(xiàn)已做到極簡，開箱即用，調(diào)度方式能夠滿足大部分研發(fā)團隊的需求。簡略易用 + 能打，所以十分受大家歡迎。

其實每個技能團隊的技能儲備不盡相同，面對的場景也不一樣，所以技能選型并不能一概而論。

不管是運用哪種技能，在編寫使命事務(wù)代碼時，仍是需求注意兩點：

• 冪等。當(dāng)使命被重復(fù)履行的時分，或者分布式鎖失效的時分，程序仍然能夠輸出正確的效果；
• 使命不跑了，千萬別驚慌。檢查調(diào)度日志，JVM層面運用Jstack指令檢查倉庫，網(wǎng)絡(luò)通訊要增加超時時刻 ，一般能處理大部分問題。

7 寫到最終

2015年其實是十分有趣的一年。ElasticJob 和 XXL-JOB 這兩種不同流派的使命調(diào)度項目都開源了。

在 XXL-JOB 源碼里，至今還保留著許雪里教師在開源我國的一條動態(tài)截圖：

剛寫的使命調(diào)度結(jié)構(gòu) ，Web動態(tài)辦理使命，實時收效，熱乎的。沒有意外的話，明天正午推送到git.osc上去。哈哈，下樓炒個面加個荷包蛋慶祝下。

看到這個截圖，內(nèi)心深處居然會有一種共情，嘴角不自禁的上揚。

我又想起：2016年，ElasticJob的作者張亮教師開源了sharding-jdbc 。我在github上創(chuàng)立了一個私有項目，參閱sharding-jdbc的源碼，自己完成分庫分表的功用。第一個類名叫：ShardingDataSource，時刻定格在 2016/3/29。

我不知道怎么界說“有創(chuàng)造力的軟件工程師”，但我信任：一個有好奇心，努力學(xué)習(xí)，樂于分享，樂意去協(xié)助他人的工程師，運氣肯定不會太差。

---

覺得對您有協(xié)助的話，請給作者一個「點贊」和「保藏」，咱們下期見。