https://www.infoq.cn/article/xTvBg1_9iUL0z5Pjf0Os

本文是蘇寧大數(shù)據(jù)離線任務(wù)開發(fā)調(diào)度平臺實踐系列文章之上篇，詳解蘇寧的任務(wù)調(diào)度模塊。

目 錄

1. 緒言 1

2. 設(shè)計目標(biāo)與主要功能 2

3. 專業(yè)術(shù)語 3

4. 調(diào)度架構(gòu)設(shè)計 5

5. 服務(wù)重啟和任務(wù)狀態(tài)恢復(fù) 6

5.1 Master Active 組合服務(wù) 7

5.2 Master HA 高可用設(shè)計 7

5.3 Recover 任務(wù)狀態(tài)恢復(fù)設(shè)計 7
6.Web?API 接口服務(wù) 9
7. 后續(xù) 10

1. 緒言

在上一篇文章《蘇寧大數(shù)據(jù)離線任務(wù)開發(fā)調(diào)度平臺實踐》中，從用戶交互功能、任務(wù)調(diào)度、任務(wù)執(zhí)行、任務(wù)運(yùn)維和對外服務(wù)等幾方面，宏觀層面進(jìn)行了理論和實踐的概述。

產(chǎn)品的用戶功能重點需要把握用戶實際的任務(wù)開發(fā)運(yùn)維需求，合理的規(guī)劃設(shè)計產(chǎn)品功能，在使用和運(yùn)維上便于用戶操作，降低用戶的開發(fā)使用成本。簡單的說就是主要保證用戶任務(wù)、任務(wù)流等關(guān)鍵元數(shù)據(jù)的配置信息的準(zhǔn)確性，以及任務(wù)狀態(tài)的查詢和干預(yù)能力，技術(shù)上實現(xiàn)不存在難點，在此不再詳細(xì)說明。

任務(wù)執(zhí)行模塊側(cè)重于任務(wù)被領(lǐng)取后，如何根據(jù)任務(wù)類型選擇不同的執(zhí)行器（Executer）提交任務(wù)執(zhí)行，并將任務(wù)的執(zhí)行狀態(tài)及時準(zhǔn)確的返回，由任務(wù)調(diào)度服務(wù)根據(jù)返回狀態(tài)做相應(yīng)的下一步處理，除此以外還涉及到任務(wù)資源加載、任務(wù)配置解析與轉(zhuǎn)換、自身健康狀態(tài)檢查與匯報、worker 進(jìn)程與任務(wù)子進(jìn)程通信、任務(wù)隔離、對外接口服務(wù)等，這塊將在后面一節(jié)再跟大家詳細(xì)分享。

任務(wù)運(yùn)維模塊主要關(guān)注平臺的自身穩(wěn)定性、健壯性等各個指標(biāo)的監(jiān)控與預(yù)警、平臺任務(wù)執(zhí)行異常的監(jiān)控、任務(wù)運(yùn)行診斷分析、動態(tài)擴(kuò)縮容和應(yīng)急降級等方面，涉及到的內(nèi)容也很多，后續(xù)章節(jié)會陸續(xù)跟大家分享。

今天我們重點詳細(xì)闡述蘇寧大數(shù)據(jù)離線任務(wù)調(diào)度開發(fā)平臺的核心模塊—任務(wù)調(diào)度模塊的架構(gòu)設(shè)計以及開發(fā)實踐過程中的關(guān)鍵功能點。

2. 設(shè)計目標(biāo)與主要功能

調(diào)度模塊的核心目標(biāo)要保證任務(wù)能夠按照用戶配置的調(diào)度時間、依賴關(guān)系準(zhǔn)實時調(diào)度和執(zhí)行，同時也允許用戶根據(jù)實際需要隨時啟動和停止任務(wù)調(diào)度，調(diào)整任務(wù)執(zhí)行計劃。所謂準(zhǔn)時實調(diào)度，指的是調(diào)度模塊會按照各個上線的任務(wù)流的調(diào)度時間生成調(diào)度執(zhí)行計劃，當(dāng)觸發(fā)時間到了，平臺會按照調(diào)度執(zhí)行計劃精確的生成任務(wù)流實例和任務(wù)實例。但是在任務(wù)執(zhí)行上，并不保證準(zhǔn)實時的分配機(jī)器執(zhí)行。實際上平臺以整體資源使用情況為最高原則，并按照一定的限流策略控制任務(wù)的執(zhí)行，比如：任務(wù)優(yōu)先級、任務(wù)組并發(fā)度、平臺任務(wù)并發(fā)數(shù)、任務(wù)特定執(zhí)行時間等因素。在保證平臺資源允許的情況下，盡量按時執(zhí)行任務(wù)。為了保障任務(wù)的實時性，必須保障任務(wù)資源的可用性和計劃可控性。

調(diào)度模塊的主要核心服務(wù)功能包括以下幾點：

服務(wù)重啟和任務(wù)狀態(tài)恢復(fù)功能

在調(diào)度服務(wù)重啟、主備切換后，系統(tǒng)狀態(tài)以及任務(wù)運(yùn)行狀態(tài)能否準(zhǔn)確的恢復(fù)。比如，主節(jié)點崩潰或維護(hù)期間，發(fā)生狀態(tài)變更的任務(wù)在主節(jié)點恢復(fù)以后，能否正確更新狀態(tài)等等。

Web API 接口服務(wù)

用戶通過 Web 控制后臺管理作業(yè)，而 Web 控制后臺與 Master 服務(wù)器之間的交互透過 Rest 服務(wù)來執(zhí)行，Rest 服務(wù)也可以給 Web 控制后臺以外的其它系統(tǒng)提供服務(wù)（用于支持外部系統(tǒng)和調(diào)度系統(tǒng)的對接）。另外為了便于監(jiān)控和調(diào)查分析調(diào)度異常和問題，提供 Master 內(nèi)存關(guān)鍵信息的查詢和人工干預(yù)的接口能力。

數(shù)據(jù)信息緩存服務(wù)

緩存上線任務(wù)流、任務(wù)、事件、系統(tǒng)配置、服務(wù)器的關(guān)鍵元數(shù)據(jù)信息，這些信息一般在任務(wù)流上線后不會經(jīng)常發(fā)生變更，沒必要實時從數(shù)據(jù)庫中讀取。并對外提供這些元數(shù)據(jù)信息的同步接口服務(wù)，保證緩存信息與數(shù)據(jù)庫的一致性。

緩存任務(wù)流實例、任務(wù)實例、事件實例等中間狀態(tài)信息，同時持久化到數(shù)據(jù)庫中。便于在任務(wù)狀態(tài)切換、任務(wù)依賴執(zhí)行快速找到對應(yīng)的運(yùn)行中的關(guān)鍵數(shù)據(jù)。并在任務(wù)實例數(shù)上升一定量級以后可以快速的從內(nèi)存中緩存的中間狀態(tài)數(shù)據(jù)完成依賴檢查和觸發(fā)執(zhí)行邏輯，降低對數(shù)據(jù)庫因為頻繁訪問造成的壓力。

任務(wù)調(diào)度服務(wù)

主要負(fù)責(zé)上線任務(wù)流的配置檢查、生成任務(wù)流執(zhí)行計劃、按照執(zhí)行計劃生成任務(wù)流與任務(wù)實例，生成任務(wù)實例狀態(tài)機(jī)和節(jié)點之間的依賴觸發(fā)關(guān)系。除了這些系統(tǒng)調(diào)用主要功能外，還提供人工干預(yù)任務(wù)執(zhí)行的服務(wù)功能，比如：任務(wù)流上下線、任務(wù)補(bǔ)數(shù)據(jù)、任務(wù)重跑、任務(wù)殺死、失敗重試等

任務(wù)狀態(tài)機(jī)管理

任務(wù)流按照調(diào)度服務(wù)的執(zhí)行計劃會在每個調(diào)度周期內(nèi)生成需要執(zhí)行的任務(wù)流實例和任務(wù)實例信息，這些實例在調(diào)度過程中存在多種臨時狀態(tài)，并具備一定的生命周期。狀態(tài)切換的時候觸發(fā)一定的業(yè)務(wù)邏輯，比如：任務(wù)實例由新建狀態(tài)切換到待分配狀態(tài)，由待分配狀態(tài)切換到已分配狀態(tài)，由執(zhí)行中狀態(tài)切換到執(zhí)行結(jié)束狀態(tài)都可能需要完成一定的處理。這里我們采用了狀態(tài)機(jī)的管理機(jī)制來確保任務(wù)執(zhí)行狀態(tài)的持續(xù)性和完整性。

任務(wù)狀態(tài)分析服務(wù)

任務(wù)實例在調(diào)度過程中存在多種臨時狀態(tài)的切換，每次狀態(tài)切換必須成功才能保證狀態(tài)變化的持續(xù)性和完整性，從而保證任務(wù)實例從生成到結(jié)束的完整生命周期。如果狀態(tài)切換過程中發(fā)生意外或者長時間停滯在某個狀態(tài)不變，可能會導(dǎo)致調(diào)度異常和用戶使用恐慌，為了準(zhǔn)確及時的分析任務(wù)實例的狀態(tài)停滯原因，需要在任務(wù)狀態(tài)生成和切換的時候進(jìn)行檢查校驗，把不能切換的原因及時記錄，便于分析問題。

任務(wù)狀態(tài)發(fā)布服務(wù)

平臺上的任務(wù)處理的是數(shù)據(jù)，數(shù)據(jù)處理的及時性和準(zhǔn)確性對業(yè)務(wù)系統(tǒng)是有極大的影響。而平臺的任務(wù)運(yùn)行狀態(tài)往往只會記錄在本平臺數(shù)據(jù)庫中，外部系統(tǒng)無法感知。在很多場景下，業(yè)務(wù)系統(tǒng)需要根據(jù)任務(wù)的執(zhí)行狀態(tài)來執(zhí)行自己的特定業(yè)務(wù)邏輯，通過傳統(tǒng)的任務(wù)狀態(tài)查詢接口又存在延遲性和性能問題，比如：任務(wù)狀態(tài)的變更，執(zhí)行時間長短會因為多種因素而變得不確定；多個外部系統(tǒng)調(diào)用平臺接口可能會導(dǎo)致平臺自身壓力的不確定性。可以在任務(wù)實例生成和狀態(tài)切換的時候，將任務(wù)實例狀態(tài)按照用戶的配置要求，及時的發(fā)布出去，業(yè)務(wù)系統(tǒng)根據(jù)需要進(jìn)行訂閱，確保任務(wù)狀態(tài)更新的及時性，又降低對平臺的侵入和壓力。

任務(wù)分配與流控服務(wù)

主要負(fù)責(zé)滿足執(zhí)行條件的任務(wù)實例的分配，以及在任務(wù)執(zhí)行高峰、資源緊張的情況下如何智能有效的進(jìn)行相應(yīng)的流控。在以整體資源使用情況為最高原則，并按照一定的限流策略控制任務(wù)的執(zhí)行，比如：任務(wù)優(yōu)先級、任務(wù)組并發(fā)度、平臺任務(wù)并發(fā)數(shù)、任務(wù)特定執(zhí)行時間等因素。在保證平臺資源允許的情況下，盡量按時執(zhí)行任務(wù)。為了保障任務(wù)的實時性，必須保障任務(wù)資源的可用性和計劃可控性。

事件觸發(fā)服務(wù)

主要解決復(fù)雜業(yè)務(wù)場景里，跨任務(wù)流依賴、跨系統(tǒng)平臺依賴的調(diào)度執(zhí)行問題。比如：平臺內(nèi)部多個系統(tǒng)多個任務(wù)流之間的依賴調(diào)度，以及外部業(yè)務(wù)系統(tǒng)在某種條件下需要通知調(diào)度平臺執(zhí)行自己的任務(wù)。另外需要解決各種頻率之間的依賴關(guān)系，比如：天依賴天、天依賴小時、周月依賴天等.

主機(jī)健康監(jiān)控服務(wù)

負(fù)責(zé)管理可以執(zhí)行任務(wù)的機(jī)器資源, 并根據(jù)各機(jī)器的健康度合理的分配任務(wù)。主要包括：worker 機(jī)器的發(fā)現(xiàn)與管理、worker 機(jī)器的健康度評估、worker 檢活、主機(jī)黑白名單（加入黑名單的機(jī)器不能領(lǐng)取和執(zhí)行任務(wù)）等

異步更新服務(wù)

平臺中存在大量的持久化操作，比如：任務(wù)實例的生成與狀態(tài)更新、事件的觸發(fā)實例生成、任務(wù)流的啟停狀態(tài)、任務(wù)運(yùn)行狀態(tài)原因分析等。有些持久化操作需要伴隨業(yè)務(wù)邏輯同步更新，確保操作的事務(wù)完整性，比如：任務(wù)流上下線、任務(wù)實例的狀態(tài)切換，必須保證內(nèi)存和數(shù)據(jù)庫一致性。有些操作則不要求高度一致性和實時性，甚至有些數(shù)據(jù)的更新錯誤或者丟失也可以忽略不計。同步更新在確保事務(wù)、數(shù)據(jù)的完整和一致性外，帶來了平臺性能的一定下降。而異步更新服務(wù)可以提高平臺的運(yùn)行性能和并發(fā)能力，這些低有求的操作和數(shù)據(jù)同步服務(wù)就可以采用異步更新服務(wù)來完成。比如：任務(wù)運(yùn)行狀態(tài)停滯原因分析、任務(wù)狀態(tài)的對外發(fā)布等

3. 專業(yè)術(shù)語

蘇寧大數(shù)據(jù)離線任務(wù)開發(fā)調(diào)度平臺具有和業(yè)內(nèi)同款平臺產(chǎn)品的共性，也具備自己的特殊性和專業(yè)性。在理解和使用我們的平臺之前，需要了解平臺常見的專業(yè)術(shù)語，以免造成理解和使用上的分歧。

任務(wù)流實例的中間運(yùn)行狀態(tài)，主要包括：待調(diào)度、執(zhí)行中、執(zhí)行失敗、執(zhí)行成功。

任務(wù)實例的中間運(yùn)行狀態(tài)，主要包括：待調(diào)度、待分配、已分配、已領(lǐng)取、參數(shù)檢查錯誤、資源準(zhǔn)備失敗、執(zhí)行中、殺死、執(zhí)行失敗、失敗重試、執(zhí)行成功、忽略失敗。

4. 調(diào)度架構(gòu)設(shè)計

從系統(tǒng)架構(gòu)的角度出發(fā)，模塊化的設(shè)計有利于功能隔離，降低組件耦合度和單個組件的復(fù)雜度，提升系統(tǒng)的可拓展性，一定程度上有利于提升系統(tǒng)穩(wěn)定性，但帶來的問題是開發(fā)調(diào)試會更加困難，從這個角度來說又不利于穩(wěn)定性的改進(jìn)。所以各個功能模塊拆不拆，怎么拆往往是需要權(quán)衡考慮的。

平臺采用常見的主從式架構(gòu)，按照功能模塊劃分清晰，職責(zé)單一而不緊耦合，避免繁重復(fù)雜的業(yè)務(wù)耦合設(shè)計。調(diào)度模塊在系統(tǒng)架構(gòu)上分為 web 接口服務(wù)、重啟恢復(fù)服務(wù)、數(shù)據(jù)緩存服務(wù)、任務(wù)狀態(tài)發(fā)布服務(wù)、事件觸發(fā)服務(wù)、異步更新服務(wù)、任務(wù)調(diào)度服務(wù)、任務(wù)狀態(tài)機(jī)管理、任務(wù)分配服務(wù)、主機(jī)健康監(jiān)控服務(wù)以及任務(wù)實例狀態(tài)監(jiān)聽服務(wù)等十幾個主要服務(wù)功能。每個服務(wù)模塊負(fù)責(zé)的功能清晰，互相耦合度低，具有良好的擴(kuò)展性、穩(wěn)定性和容錯性。調(diào)度的整體架構(gòu)設(shè)計如下圖所示。

調(diào)度模塊涉及到多種功能服務(wù)，這些功能服務(wù)內(nèi)部涉及到大量復(fù)雜的、交互的事件處理、狀態(tài)轉(zhuǎn)換，同時，這些事件調(diào)度和狀態(tài)轉(zhuǎn)換又對實時性和效率提出了極高的要求。可以想見，沒有一個規(guī)整的、通用型良好的調(diào)度器，平臺代碼無論是對讀者，還是對開發(fā)者，都將變成一場災(zāi)難，同時平臺的運(yùn)行效率也會變得無法忍受。統(tǒng)一的、設(shè)計良好的、通用的和共用的調(diào)度器，對于調(diào)度模塊不同組件的開發(fā)者來說是一種解脫，大大降低了平臺在事件調(diào)度、狀態(tài)轉(zhuǎn)換的底層出錯的可能性，提高了代碼穩(wěn)定性和可讀性。

如何組裝、如何進(jìn)行有效的接口調(diào)用來支撐平臺百萬級的任務(wù)高效穩(wěn)定的執(zhí)行。在組裝設(shè)計上需要慎重選型。一般多服務(wù)調(diào)用分為函數(shù)調(diào)用和事件驅(qū)動兩種模式。

相比于基于函數(shù)調(diào)用的編程模型，這種編程方式具有異步、并發(fā)等特點，更加高效，因此更加適合大型分布式系統(tǒng)。調(diào)度模塊的十幾個服務(wù)之間的大部分服務(wù)調(diào)用也基本是基于事件驅(qū)動的編程模型進(jìn)行設(shè)計。開發(fā)實踐過程中，Hadoop 的核心調(diào)度器 AsyncDispatcher 的設(shè)計和實現(xiàn)同 Hadoop 狀態(tài)機(jī)一樣，這個通用調(diào)度器設(shè)計得十分通用，完美可擴(kuò)展可重用，我們在自己的項目中完全可以使用 Hadoop 的調(diào)度器實現(xiàn)我們自己的事件調(diào)度邏輯。

5. 服務(wù)重啟和任務(wù)狀態(tài)恢復(fù)

該服務(wù)主要是將調(diào)度模塊的所有服務(wù)組件進(jìn)行統(tǒng)一的注冊和管理，并按照平臺的業(yè)務(wù)邏輯順序進(jìn)行順序初始化和啟動。并通過 HAService 服務(wù)往 ZK 搶注 Master 的服務(wù)器節(jié)點目錄，來完成主備 Master 的狀態(tài)切換。通過 RecoverService 服務(wù)完成 從數(shù)據(jù)庫中同步任務(wù)流、任務(wù)、事件等元數(shù)據(jù)信息和任務(wù)實例、事件實例等實例信息的內(nèi)存恢復(fù)操作。根據(jù)任務(wù)實例的數(shù)據(jù)庫和 zk 中保存的狀態(tài)進(jìn)行任務(wù)狀態(tài)機(jī)的創(chuàng)建和后續(xù)狀態(tài)的持續(xù)觸發(fā)操作。

5.1 Master Active 組合服務(wù)

如前文所述，調(diào)度模塊包括了十幾個核心功能服務(wù)，如何有效的管理和協(xié)同這些服務(wù)的起停順序、服務(wù)之間的調(diào)度關(guān)系，我們在 Java 設(shè)計模式上采用了組合模式 (Composite)，將這十幾個服務(wù)按照調(diào)度的業(yè)務(wù)關(guān)系進(jìn)行了組合包裝。

Hadoop Yarn 的 CompositeService 提供了一個比較好的組合封裝服務(wù)，包括服務(wù)的注冊（添加和移出）、服務(wù)的初始化和啟停操作，這些服務(wù)被順序的保存在一個 List 對象中，各個服務(wù)會按照順序進(jìn)行逐個初始化和啟停。調(diào)度模塊的這十幾個關(guān)鍵服務(wù)統(tǒng)一打包在 MasterActiveService 中。

5.2 Master HA 高可用設(shè)計

高可用性 H.A.（High Availability）指的是通過盡量縮短因日常維護(hù)操作（計劃）和突發(fā)的系統(tǒng)崩潰（非計劃）所導(dǎo)致的停機(jī)時間，以提高系統(tǒng)和應(yīng)用的可用性。HA 系統(tǒng)是目前企業(yè)防止核心計算機(jī)系統(tǒng)因故障停機(jī)的最有效手段。

在 HA 方面，按照準(zhǔn)實時的設(shè)計目標(biāo)，平臺并沒有打算做到秒級別的崩潰恢復(fù)速度，系統(tǒng)崩潰時，只要能在分鐘級別范圍內(nèi)，重建系統(tǒng)狀態(tài)，就基本能滿足系統(tǒng)的設(shè)計目標(biāo)需求。

所以其實高可用性設(shè)計的重點，關(guān)鍵在于重建的過程中，系統(tǒng)的狀態(tài)能否準(zhǔn)確的恢復(fù)。比如，主節(jié)點崩潰或維護(hù)期間，發(fā)生狀態(tài)變更的任務(wù)在主節(jié)點恢復(fù)以后，能否正確更新狀態(tài)等等。而雙機(jī)熱備份無縫切換，目前來看實現(xiàn)難度較大（太多流程需要考慮原子操作，數(shù)據(jù)同步和避免競爭沖突），實際需求也不強(qiáng)烈，通過監(jiān)控，自動重啟和雙機(jī)冷備的方式來加快系統(tǒng)重建速度，基本也就足夠了。

本平臺在設(shè)計的時候采用了“主從方式”實現(xiàn) HA，主要設(shè)計要點：

(1) 一個狀態(tài)管理功能模塊

實現(xiàn)一個 zkFailover，常駐在每一個 Master 服務(wù)節(jié)點內(nèi)，每一個 failover 負(fù)責(zé)監(jiān)聽自己所在節(jié)點，利用 zk 進(jìn)行狀態(tài)標(biāo)識。當(dāng)需要進(jìn)行狀態(tài)切換時，由 zkFailover 實現(xiàn)狀態(tài)切換，切換時需要注意防止 brain split 現(xiàn)象發(fā)生。

(2) 對外服務(wù)方式

除了 HAService 服務(wù)外，只能有一個 Master 節(jié)點可以托管和執(zhí)行其他所有服務(wù)。另外一個節(jié)點只能啟動 HAService 監(jiān)聽主節(jié)點的狀態(tài)。只有主節(jié)點停止服務(wù)后，才能啟動其他服務(wù)進(jìn)行工作。

5.3 Recover 任務(wù)狀態(tài)恢復(fù)設(shè)計

在調(diào)度服務(wù)重啟、主備切換后，系統(tǒng)狀態(tài)以及任務(wù)運(yùn)行狀態(tài)能否準(zhǔn)確的恢復(fù)。比如，主節(jié)點崩潰或維護(hù)期間，發(fā)生狀態(tài)變更的任務(wù)在主節(jié)點恢復(fù)以后，能否正確更新狀態(tài)等等是一個任務(wù)調(diào)度平臺的重要功能和考核指標(biāo)。

Recover 不僅需要恢復(fù)各種實例信息的元數(shù)據(jù)信息和狀態(tài)信息，確保每個任務(wù)實例狀態(tài)切換的連續(xù)性、完整性和正確性，還要保證每個任務(wù)流內(nèi)部各個節(jié)點之間按照依賴關(guān)系及時的觸發(fā)和正確執(zhí)行。在某些場景下， 還需要對因為調(diào)度服務(wù)停止期間遺漏的任務(wù)流和任務(wù)實例進(jìn)行補(bǔ)償。

第一步完成任務(wù)配置相關(guān)的元數(shù)據(jù)信息的恢復(fù)。

即從數(shù)據(jù)庫中同步必要的元數(shù)據(jù)信息到調(diào)度內(nèi)存中。元數(shù)據(jù)信息在數(shù)據(jù)庫中不是存放了一份，為什么還要從數(shù)據(jù)庫中同步一份到調(diào)度的內(nèi)存中呢？在任務(wù)量很少的情況下每次讀寫數(shù)據(jù)庫不會對數(shù)據(jù)庫造成壓力。但是在任務(wù)量上升，任務(wù)實例的生成量和狀態(tài)切換的量成幾何級上升，隨著對數(shù)據(jù)庫的讀寫 TPS 也會上升。這樣一方面可能會造成數(shù)據(jù)庫的壓力偏大，另一方面如果數(shù)據(jù)庫服務(wù)不穩(wěn)定、網(wǎng)絡(luò)抖動等外部因素而導(dǎo)致調(diào)度服務(wù)卡住。

在大多數(shù)情況下，任務(wù)流一旦上線后不會輕易發(fā)生變更。如果有部分變動，可以通過 Master 的 web 接口同步內(nèi)存和數(shù)據(jù)庫的配置信息。為了保證狀態(tài)的一致統(tǒng)一，和任務(wù)相關(guān)的信息變更，無論是用戶發(fā)起的作業(yè)配置修改，還是執(zhí)行器反饋的作業(yè)狀態(tài)變更，都會提交給 Master 節(jié)點同步寫入到數(shù)據(jù)庫。具體參考下圖。

第二步完成實例信息和任務(wù)狀態(tài)的恢復(fù)。

實例信息的恢復(fù)主要包括：任務(wù)流實例、任務(wù)實例、事件實例的狀態(tài)恢復(fù)，已經(jīng)結(jié)束的任務(wù)流實例信息不作為恢復(fù)的對象。這一步不僅僅的單純同步實例的信息到調(diào)度內(nèi)存里，更重要的是要恢復(fù)任務(wù)實例的狀態(tài)，確保任務(wù)執(zhí)行按照計劃和依賴關(guān)系正確的執(zhí)行下去。
任務(wù)流實例是按照任務(wù)流的執(zhí)行計劃不斷生成的運(yùn)行個體。當(dāng)重啟掃描數(shù)據(jù)中“未執(zhí)行結(jié)束”的任務(wù)流實例時，可能會存在大量的實例個體，執(zhí)行恢復(fù)的時候，智能根據(jù)“未執(zhí)行結(jié)束”的任務(wù)流實例個數(shù)啟動一定數(shù)量的線程，按照任務(wù)流實例進(jìn)行切分，進(jìn)行批量恢復(fù)。

第三步補(bǔ)償丟失的任務(wù)實例批次

Master 調(diào)度重啟或者服務(wù)器宕機(jī)等因素造成任務(wù)調(diào)度計劃被打斷，再次恢復(fù)后需要對服務(wù)終止期間的丟失的任務(wù)實例進(jìn)行補(bǔ)償，否則會造成某些任務(wù)執(zhí)行計劃被錯過而沒有得到調(diào)度執(zhí)行，引發(fā)數(shù)據(jù)故障。
根據(jù)故障恢復(fù)的時間長短，結(jié)合每個頻率的任務(wù)做出不同的補(bǔ)償措施。下表是根據(jù)不同頻率類型按照對應(yīng)策略進(jìn)行補(bǔ)償。

對于一些復(fù)雜的業(yè)務(wù)場景的任務(wù)，也不是必須要把所有遺漏的批次都補(bǔ)償完畢，可以適當(dāng)補(bǔ)償一些遺漏批次，其他遺漏批次在服務(wù)重啟后人工補(bǔ)償。如果把歷史遺漏批次都補(bǔ)償，可能會因為補(bǔ)償?shù)膶嵗龜?shù)過多而導(dǎo)致當(dāng)前批次被延后執(zhí)行。

6.Web?API 接口服務(wù)

用戶通過 Web 控制后臺管理作業(yè)，而 Web 控制后臺與 Master 服務(wù)器之間的交互透過 Rest 服務(wù)來執(zhí)行，Rest 服務(wù)也可以給 Web 控制后臺以外的其它系統(tǒng)提供服務(wù)（用于支持外部系統(tǒng)和調(diào)度系統(tǒng)的對接）。另外為了便于監(jiān)控和調(diào)查分析調(diào)度異常和問題，提供 Master 內(nèi)存關(guān)鍵信息的查詢和人工干預(yù)的接口能力。

考慮到調(diào)度模塊的代碼部署不依賴外部容器，比如：Tomcat、JBoss 等，又要對外提供 Web 接口服務(wù)，因此在技術(shù)選型上需要注意這一點。目前市場上流行的 SpringBoot、內(nèi)嵌 Jettty 等其他 Servlet 容器方案都可以解決這個問題。我們的平臺使用的架構(gòu)是 Jersey+Guice+Jetty+ Mybatis，jersey 作為 Rest 服務(wù)框架，Guice 作為 DI 框架，使用內(nèi)嵌 Jetty 作為應(yīng)用容器，Mybatis 負(fù)責(zé)數(shù)據(jù)庫的持久化操作，并舍棄 web.xml 配置，這樣使得開發(fā)和部署十分輕量和簡單。

下圖是調(diào)度模塊里各個服務(wù)、容器、上下文之間的訪問交互圖。

Master 上下文承載了配置文件、注冊服務(wù)的查找與發(fā)現(xiàn)、元數(shù)據(jù)和實例數(shù)據(jù)信息以及各個服務(wù)的調(diào)用轉(zhuǎn)發(fā)器（Dispatcher）。其他服務(wù)組件通過 Master 上下文可以很方便的獲取系統(tǒng)配置信息，調(diào)用其他組件接口。Guice 框架目前主要托管了數(shù)據(jù)庫相關(guān)操作類以及 web 服務(wù)接口類，被托管的服務(wù)類以單例的形式保存。整個調(diào)度模塊內(nèi)嵌了 Jetty 容器，部署和啟動了 WebServer 服務(wù)，提供外部與 Master 內(nèi)部服務(wù)的交互入口。

7. 后續(xù)

上述文章講述了調(diào)度模塊的架構(gòu)設(shè)計、恢復(fù)和 web 服務(wù)，后續(xù)文章會接著講述調(diào)度服務(wù)的設(shè)計細(xì)節(jié)。調(diào)度服務(wù)是整個調(diào)度模塊非常核心的服務(wù)組件，涉及到任務(wù)流上下線、任務(wù)狀態(tài)機(jī)管理、任務(wù)重跑補(bǔ)數(shù)據(jù)等運(yùn)維操作，限于篇幅和時間問題，本次的調(diào)度模塊的分享先寫這么多，后續(xù)會陸續(xù)對其他服務(wù)組件進(jìn)行詳細(xì)闡述，敬請期待。

轉(zhuǎn)載于:https://www.cnblogs.com/davidwang456/articles/10346079.html

總結(jié)

以上是生活随笔為你收集整理的苏宁大数据离线任务开发调度平台实践：任务调度模块架构设计的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。