蘇寧大數(shù)據(jù)平臺任務(wù)調(diào)度模塊架構(gòu)設(shè)計

1、蘇寧大數(shù)據(jù)離線任務(wù)開發(fā)調(diào)度平臺實踐:任務(wù)調(diào)度模塊架構(gòu)設(shè)計2019-02-01 08:00:00 375 收藏 2作為國內(nèi)最大的電商平臺之一，蘇寧每天要處理數(shù)量巨大的數(shù)據(jù)。為了更快速高效地處理這 些數(shù)據(jù)，蘇寧調(diào)度平臺采取了哪些措施呢本文是蘇寧大數(shù)據(jù)離線任務(wù)開發(fā)調(diào)度平臺實踐系列文章之上篇，詳解蘇寧的任務(wù)調(diào)度模塊。目錄1.緒言tl2設(shè)計目標(biāo)與主要功能t23.專業(yè)術(shù)語t34調(diào)度架構(gòu)設(shè)計t55.服務(wù)重啟和任務(wù)狀態(tài)恢復(fù)t6Master Active 組合服務(wù)t7Master HA高可用設(shè)計t7Recover任務(wù)狀態(tài)恢復(fù)設(shè)計t7API接口服務(wù)t97.后續(xù)tl01.緒言在上一篇文章蘇寧大數(shù)據(jù)離線任務(wù)開發(fā)調(diào)度平

2、臺實踐中，從用戶交互功能、任務(wù)調(diào)度、 任務(wù)執(zhí)行、任務(wù)運維和對外服務(wù)等幾方面，宏觀層面進行了理論和實踐的概述。產(chǎn)品的用戶功能重點需要把握用戶實際的任務(wù)開發(fā)運維需求，合理的規(guī)劃設(shè)計產(chǎn)品功能，在 使用和運維上便于用戶操作，降低用戶的開發(fā)使用成本。簡單的說就是主要保證用戶任務(wù)、 任務(wù)流等關(guān)鍵元數(shù)據(jù)的配置信息的準(zhǔn)確性，以及任務(wù)狀態(tài)的查詢和干預(yù)能力，技術(shù)上實現(xiàn)不 存在難點，在此不再詳細說明。任務(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ù)配

3、置解析與轉(zhuǎn)換、自身健康狀態(tài)檢查與匯 報、worker進程與任務(wù)子進程通信、任務(wù)隔離、對外接口服務(wù)等，這塊將在后面一節(jié)再跟 大家詳細分享。任務(wù)運維模塊主要關(guān)注平臺的自身穩(wěn)定性、健壯性等各個指標(biāo)的監(jiān)控與預(yù)警、平臺任務(wù)執(zhí)行 異常的監(jiān)控、任務(wù)運行診斷分析、動態(tài)擴縮容和應(yīng)急降級等方面，涉及到的內(nèi)容也很多，后 續(xù)章節(jié)會陸續(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)整

4、任務(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)實時的分配機器執(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ù)運行狀態(tài)能否

5、準(zhǔn)確的恢復(fù)。比如，主節(jié)點 崩潰或維護期間，發(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ù)信息的同

6、 步接口服務(wù)，保證緩存信息與數(shù)據(jù)庫的一致性。緩存任務(wù)流實例、任務(wù)實例、事件實例等中間狀態(tài)信息，同時持久化到數(shù)據(jù)庫中。便于在任 務(wù)狀態(tài)切換、任務(wù)依賴執(zhí)行快速找到對應(yīng)的運行中的關(guān)鍵數(shù)據(jù)。并在任務(wù)實例數(shù)上升一定量 級以后可以快速的從內(nèi)存中緩存的中間狀態(tài)數(shù)據(jù)完成依賴檢查和觸發(fā)執(zhí)行邏輯，降低對數(shù)據(jù) 庫因為頻繁訪問造成的壓力。任務(wù)調(diào)度服務(wù)主要負責(zé)上線任務(wù)流的配置檢查、生成任務(wù)流執(zhí)行計劃、按照執(zhí)行計劃生成任務(wù)流與任務(wù)實 例，生成任務(wù)實例狀態(tài)機和節(jié)點之間的依賴觸發(fā)關(guān)系。除了這些系統(tǒng)調(diào)用主要功能外，還提 供人工干預(yù)任務(wù)執(zhí)行的服務(wù)功能，比如：任務(wù)流上下線、任務(wù)補數(shù)據(jù)、任務(wù)重跑、任務(wù)殺死、 失敗重試等任務(wù)狀態(tài)機管理

7、任務(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)機的管理機制來確保任務(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)不變，

8、可能會導(dǎo)致調(diào)度異常和用戶使用恐慌，為了準(zhǔn)確 及時的分析任務(wù)實例的狀態(tài)停滯原因，需要在任務(wù)狀態(tài)生成和切換的時候進行檢查校驗，把 不能切換的原因及時記錄，便于分析問題。任務(wù)狀態(tài)發(fā)布服務(wù)平臺上的任務(wù)處理的是數(shù)據(jù)，數(shù)據(jù)處理的及時性和準(zhǔn)確性對業(yè)務(wù)系統(tǒng)是有極大的影響。而平 臺的任務(wù)運行狀態(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)切

9、換的時候，將任務(wù)實例狀態(tài)按照用戶的配置要求，及時的發(fā)布出去，業(yè)務(wù)系統(tǒng)根 據(jù)需要進行訂閱，確保任務(wù)狀態(tài)更新的及時性，又降低對平臺的侵入和壓力。任務(wù)分配與流控服務(wù)主要負責(zé)滿足執(zhí)行條件的任務(wù)實例的分配，以及在任務(wù)執(zhí)行高峰、資源緊張的情況下如何智 能有效的進行相應(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í)行問題。比如

10、：平臺內(nèi) 部多個系統(tǒng)多個任務(wù)流之間的依賴調(diào)度，以及外部業(yè)務(wù)系統(tǒng)在某種條件下需要通知調(diào)度平臺 執(zhí)行自己的任務(wù)。另外需要解決各種頻率之間的依賴關(guān)系，比如：天依賴天、天依賴小時、 周月依賴天等.主機健康監(jiān)控服務(wù)負責(zé)管理可以執(zhí)行任務(wù)的機器資源，并根據(jù)各機器的健康度合理的分配任務(wù)。主要包括： worker機器的發(fā)現(xiàn)與管理、worker機器的健康度評估、worker檢活、主機黑白名單（加入 黑名單的機器不能領(lǐng)取和執(zhí)行任務(wù)）等異步更新服務(wù)平臺中存在大量的持久化操作，比如：任務(wù)實例的生成與狀態(tài)更新、事件的觸發(fā)實例生成、 任務(wù)流的啟停狀態(tài)、任齊運行狀態(tài)原因分析等。有些持久化操作需要伴隨業(yè)務(wù)邏輯同步更新, 確保操

11、作的事務(wù)完整性，比如：任務(wù)流上下線、任務(wù)實例的狀態(tài)切換，必須保證內(nèi)存和數(shù)據(jù) 庫一致性。有些操作則不要求高度一致性和實時性，甚至有些數(shù)據(jù)的更新錯誤或者丟失也可 以忽略不計。同步更新在確保事務(wù)、數(shù)據(jù)的完整和一致性外，帶來了平臺性能的一定下降。 而異步更新服務(wù)可以提高平臺的運行性能和并發(fā)能力，這些低有求的操作和數(shù)據(jù)同步服務(wù)就 可以采用異步更新服務(wù)來完成。比如：任務(wù)運行狀態(tài)停滯原因分析、任務(wù)狀態(tài)的對外發(fā)布等3.專業(yè)術(shù)語蘇寧大數(shù)據(jù)離線任務(wù)開發(fā)調(diào)度平臺具有和業(yè)內(nèi)同款平臺產(chǎn)品的共性，也具備自己的特殊性和 專業(yè)性。在理解和使用我們的平臺之前，需要了解平臺常見的專業(yè)術(shù)語，以免造成理解和使 用上的分歧。任務(wù)流實例

12、的中間運行狀態(tài)，主要包括：待調(diào)度、執(zhí)行中、執(zhí)行失敗、執(zhí)行成功。任務(wù)實例的中間運行狀態(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)定性的改進。所以各個功能模塊拆不拆，怎么拆往往 是需要權(quán)衡考慮的。平臺釆用常見的主從式架構(gòu)，按照功能模塊劃分清晰，職責(zé)單一而不緊耦合，避免繁重復(fù)雜 的業(yè)務(wù)耦合設(shè)計。調(diào)度模塊在

13、系統(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)機管理、任務(wù) 分配服務(wù)、主機健康監(jiān)控服務(wù)以及任務(wù)實例狀態(tài)監(jiān)聽服務(wù)等十幾個主要服務(wù)功能。每個服務(wù) 模塊負責(zé)的功能清晰，互相耦合度低，具有良好的擴展性、穩(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)難，同時平臺的運行效率也

14、會變得無法忍受。統(tǒng)一的、設(shè)計良好的、通用的和共用的 調(diào)度器，對于調(diào)度模塊不同組件的開發(fā)者來說是一種解脫，大大降低了平臺在事件調(diào)度、狀 態(tài)轉(zhuǎn)換的底層出錯的可能性，提高了代碼穩(wě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ū) 動的編程模型進行設(shè)計。開發(fā)實踐過程中，血doop的核心調(diào)度器AsyncDispatcher的設(shè)計 和實現(xiàn)同

15、Hadoop狀態(tài)機一樣，這個通用調(diào)度器設(shè)計得十分通用，完美可擴展可重用，我們 在自己的項目中完全可以使用Hadoop的調(diào)度器實現(xiàn)我們自己的事件調(diào)度邏輯。5.服務(wù)重啟和任箏狀態(tài)恢復(fù)該服務(wù)主要是將調(diào)度模塊的所有服務(wù)組件進行統(tǒng)一的注冊和管理，并按照平臺的業(yè)務(wù)邏輯順 序進行順序初始化和啟動。并通過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)進行任務(wù)狀態(tài)機的創(chuàng)建和后續(xù)狀態(tài)的持續(xù)觸發(fā)

16、操作。Master Active組合服務(wù)如前文所述，調(diào)度模塊包括了十幾個核心功能服務(wù)，如何有效的管理和協(xié)同這些服務(wù)的起停 順序、服務(wù)之間的調(diào)度關(guān)系，我們在Java設(shè)計模式上采用了組合模式（Composite）,將這十 幾個服務(wù)按照調(diào)度的業(yè)務(wù)關(guān)系進行了組合包裝。Hadoop Yarn的CompositeService提供了 一個比較好的組合封裝服務(wù)，包括服務(wù)的注冊（添 加和移出）、服務(wù)的初始化和啟停操作，這些服務(wù)被順序的保存在一個List對象中，各個服 務(wù)會按照順序進行逐個初始化和啟停。調(diào)度模塊的這十幾個關(guān)鍵服務(wù)統(tǒng)一打包在 MasterActiveService 中。Master HA高可用設(shè)計

17、高可用性.（HighAvailability）指的是通過盡量縮短因日常維護操作（計劃）和突發(fā)的系 統(tǒng)崩潰（非計劃）所導(dǎo)致的停機時間，以提高系統(tǒng)和應(yīng)用的可用性。HA系統(tǒng)是目前企業(yè)防 止核心計算機系統(tǒng)因故障停機的最有效手段。在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é)點崩潰或維護期間，發(fā)生狀態(tài)變更的任務(wù)在主節(jié)點恢復(fù)以后，能否正確更新狀態(tài)等等。 而雙機熱備份無縫切換，目前來看實現(xiàn)難度較大(太多流程需要

18、考慮原子操作，數(shù)據(jù)同步和 避免競爭沖突)，實際需求也不強烈，通過監(jiān)控，自動重啟和雙機冷備的方式來加快系統(tǒng)重 建速度，基本也就足夠了。本平臺在設(shè)計的時候采用了 "主從方式”實現(xiàn)HA,主要設(shè)計要點：(1) 一個狀態(tài)管理功能模塊實現(xiàn)一個zkFailover,常駐在每一個Master服務(wù)節(jié)點內(nèi)，每一個failover負責(zé)監(jiān)聽自己 所在節(jié)點，利用zk進行狀態(tài)標(biāo)識。當(dāng)需要進行狀態(tài)切換時，由zkFailover實現(xiàn)狀態(tài)切換, 切換時需要注意防止brain split現(xiàn)象發(fā)生。(2)對外服務(wù)方式除了 HAService服務(wù)外，只能有一個Master節(jié)點可以托管和執(zhí)行其他所有服務(wù)。另外一個 節(jié)點只能啟

19、動HAService監(jiān)聽主節(jié)點的狀態(tài)。只有主節(jié)點停止服務(wù)后，才能啟動其他服務(wù)進 行工作。Recover任務(wù)狀態(tài)恢復(fù)設(shè)計在調(diào)度服務(wù)重啟、主備切換后，系統(tǒng)狀態(tài)以及任務(wù)運行狀態(tài)能否準(zhǔn)確的恢復(fù)。比如，主節(jié)點 崩潰或維護期間，發(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ù)實例 進行補償。第一步完成任務(wù)配置相關(guān)的元

20、數(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ā)生變更。如果有部分變動，可以通過辰ster 的web接口同步內(nèi)存和數(shù)據(jù)庫的配置信息。為了保證狀態(tài)的一致統(tǒng)一，和任務(wù)相關(guān)的信息變 更，無論是用戶發(fā)起的

21、作業(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í)行計劃不斷生成的運行個體。當(dāng)重啟掃描數(shù)據(jù)中"未執(zhí)行結(jié)束” 的任務(wù)流實例時，可能會存在大量的實例個體，執(zhí)行恢復(fù)的時候，智能根據(jù)“未執(zhí)行結(jié)束” 的任務(wù)流實例個數(shù)啟動一定數(shù)量的線程，按照任務(wù)流實

22、例進行切分，進行批量恢復(fù)。第三步補償丟失的任務(wù)實例批次Master調(diào)度重啟或者服務(wù)器宕機等因素造成任務(wù)調(diào)度計劃被打斷，再次恢復(fù)后需要對服務(wù) 終止期間的丟失的任務(wù)實例進行補償，否則會造成某些任務(wù)執(zhí)行計劃被錯過而沒有得到調(diào)度 執(zhí)行，引發(fā)數(shù)據(jù)故障。）根據(jù)故障恢復(fù)的時間長短，結(jié)合每個頻率的任務(wù)做出不同的補償措施。下表是根據(jù)不同頻率 類型按照對應(yīng)策略進行補償。對于一些復(fù)雜的業(yè)務(wù)場景的任務(wù)，也不是必須要把所有遺漏的批次都補償完畢，可以適當(dāng)補 償一些遺漏批次，其他遺漏批次在服務(wù)重啟后人工補償。如果把歷史遺漏批次都補償，可能 會因為補償?shù)膶嵗龜?shù)過多而導(dǎo)致當(dāng)前批次被延后執(zhí)行。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 等其他Ser