4.4

任務(wù)分發(fā)

4.4.1、分片機(jī)制

分片策略是為了保證密集調(diào)度的高效性，以及解決任務(wù)重復(fù)分發(fā)執(zhí)行的問題。調(diào)度密集或者耗時(shí)任務(wù)可能會導(dǎo)致任務(wù)阻塞，在分布式集群場景下，調(diào)度組件會小概率重復(fù)分發(fā)，針對這種情況，通常結(jié)合 “單機(jī)路由策略（如：一致性哈希）” + “阻塞策略（如：丟棄后續(xù)調(diào)度）” 來規(guī)避，最終避免任務(wù)重復(fù)執(zhí)行；

無論是用戶手動觸發(fā)，還是定時(shí)調(diào)度器觸發(fā)的工作流任務(wù)，都會先封裝成命令并持久化至元數(shù)據(jù)DB中，隨后等待MasterServer分發(fā)調(diào)度，MasterServer中的MasterSchedulerBootstrap線程會每隔一段時(shí)間掃描Command表，取出命令、封裝后投放至任務(wù)隊(duì)列，等待線程消費(fèi)；

由于采用去中心化的設(shè)計(jì)思想，DolphinScheduler集群會有一定數(shù)量的MasterServer節(jié)點(diǎn)在同時(shí)工作，意味著同一時(shí)刻可能會有多個(gè)MasterServer節(jié)點(diǎn)在掃描Command表，如果多個(gè)MasterServer都取到同一條Command則會導(dǎo)致工作流任務(wù)被執(zhí)行若干次，這顯然是不合理的，為了保證單條命令只能由一個(gè)MasterServer接管，開發(fā)者設(shè)計(jì)了分片機(jī)制，原理比較簡單，MasterServer從Command表分頁獲取滿足 Id % MasterCount = MasterSlotId 的記錄行，其中：

• Id：Command表中的記錄ID；

• MasterCount：分片總數(shù)，成功注冊在ZooKeeper的MasterServer總數(shù)；

• MasterSlotId：分片序號，當(dāng)前MasterServer在ZooKeeper的位置索引。

例如集群有3個(gè)MasterServer，按照分片策略，Command表記錄會公平分配到每個(gè)MasterServer。值得說明的是，分片是以 MasterServer 為維度，動態(tài)擴(kuò)容 MasterServer 以增加分片數(shù)量，在進(jìn)行大數(shù)據(jù)量業(yè)務(wù)操作時(shí)可有效提升任務(wù)處理能力和速度：

下面思考一個(gè)問題，如何保證同一個(gè)命令只被一個(gè)MasterServer執(zhí)行？在任務(wù)分片路由的過程中，假如 MasterServer 正在做水平擴(kuò)縮，由于 MasterServer 的分片總數(shù)和分片索引發(fā)生變化，可能會導(dǎo)致同一個(gè)命令被分發(fā)至不同的 MasterServer 中，如下圖例子，擴(kuò)容了1臺 MasterServer，id=6的命令根據(jù)哈希計(jì)算又分配給了MasterServer 3，為了避免同一個(gè)命令被重復(fù)執(zhí)行，MasterServer 在領(lǐng)取到命令后，會通過數(shù)據(jù)庫事務(wù)完成命令和工作流實(shí)例的轉(zhuǎn)換、刪除命令等操作，如果刪除操作失敗便回滾事務(wù)，意味著命令已經(jīng)被其它MasterServer認(rèn)領(lǐng)，則丟棄調(diào)度，這樣即可保證同一個(gè)命令只能被一個(gè)MasterServer執(zhí)行。

4.4.2、負(fù)載均衡策略

MasterServer將DAG任務(wù)下發(fā)至WorkerServer前，會根據(jù)負(fù)載均衡策略選出合適的WorkerServer節(jié)點(diǎn)，而負(fù)載均衡策略有如下三種：

• 加權(quán)隨機(jī)（Random）：隨機(jī)選擇一個(gè)節(jié)點(diǎn)；算法缺點(diǎn)是所有節(jié)點(diǎn)被訪問到的概率是相同的，具有不可預(yù)測性，在一次完整的輪詢中，有可能負(fù)載低的完全沒被選中，而負(fù)載高的頻繁被選中；

• 加權(quán)輪詢（LowerWeight）：默認(rèn)策略。WorkerServer節(jié)點(diǎn)每隔一段時(shí)間向ZooKeeper上報(bào)心跳信息（包含cpuload、可用物理內(nèi)存、啟動時(shí)間、線程數(shù)量等信息），MasterServer分發(fā)任務(wù)時(shí)根據(jù)WorkerServer節(jié)點(diǎn)的CPU Load平均值、可用物理內(nèi)存、系統(tǒng)平均負(fù)載、服務(wù)啟動耗時(shí)計(jì)算節(jié)點(diǎn)權(quán)重值，值越大意味著節(jié)點(diǎn)負(fù)載越低，選中的優(yōu)先級越高；算法缺點(diǎn)是在某些特殊的權(quán)重下，會生成不均勻的序列，這種不平滑的負(fù)載可能會導(dǎo)致節(jié)點(diǎn)出現(xiàn)瞬間高負(fù)載的現(xiàn)象，導(dǎo)致節(jié)點(diǎn)存在宕機(jī)風(fēng)險(xiǎn)；

• 平滑加權(quán)輪詢（RoundRobin）：節(jié)點(diǎn)宕機(jī)時(shí)降低有效權(quán)重值，節(jié)點(diǎn)正常時(shí)提高有效權(quán)重值；降權(quán)起到緩慢剔除宕機(jī)節(jié)點(diǎn)的效果，提權(quán)起到緩沖恢復(fù)宕機(jī)節(jié)點(diǎn)的效果。

所有的負(fù)載均衡算法都是基于WorkerServer節(jié)點(diǎn)的權(quán)重進(jìn)行加權(quán)計(jì)算的，權(quán)重影響分發(fā)結(jié)果，考慮到JIT優(yōu)化，Worker在啟動后會低功率地運(yùn)行一段時(shí)間（默認(rèn)十分鐘），隨后逐漸達(dá)到最佳性能，此過程稱為“JVM 預(yù)熱”，預(yù)熱期間WorkerServer節(jié)點(diǎn)的權(quán)重會緩慢動態(tài)調(diào)整，實(shí)現(xiàn)代碼可參見 HostWeight 類。

private double calculateWeight(double cpu, double memory, double loadAverage, long startTime) {
    double calculatedWeight = cpu * CPU_FACTOR + memory * MEMORY_FACTOR + loadAverage * LOAD_AVERAGE_FACTOR;
    long uptime = System.currentTimeMillis() - startTime;
    if (uptime > 0 && uptime < Constants.WARM_UP_TIME) {
      // If the warm-up is not over, add the weight
      return calculatedWeight * Constants.WARM_UP_TIME / uptime;
    }
    return calculatedWeight;
}

4.4.3、召回策略

在 2.0.6 版本以前，當(dāng)集群有多個(gè) WorkerServer 節(jié)點(diǎn)時(shí)，比如3個(gè) WorkerServer 節(jié)點(diǎn)，所對應(yīng)的負(fù)載分別是 0.1, 0.2, 0.2，如果按照默認(rèn)的負(fù)載均衡策略 LowerWeight 來分配任務(wù)，若一次啟動100個(gè)任務(wù)，在啟動任務(wù)的心跳周期內(nèi)，可能導(dǎo)致任務(wù)會直接分配到負(fù)載為0.1的 WorkerServer 中，而其他兩個(gè) WorkerServer 分配不到任務(wù)，當(dāng) WorkerServer 的并發(fā)數(shù)是10個(gè)任務(wù)時(shí)，另外90個(gè)任務(wù)在同一個(gè)節(jié)點(diǎn)排隊(duì)，這就拉長了任務(wù)整體運(yùn)行的時(shí)間?；诖藛栴}，2.0.6+ 版本增加了 MasterServer 的召回策略：

• WorkerServer 的隊(duì)列有：

  • 等待分配隊(duì)列：org.apache.dolphinscheduler.server.worker.runner.WorkerManagerThread#waitSubmitQueue，無邊界的阻塞隊(duì)列，負(fù)責(zé)接收來自MasterServer的DAG任務(wù)，此隊(duì)列會延遲執(zhí)行隊(duì)列；

  • 執(zhí)行隊(duì)列：org.apache.dolphinscheduler.server.worker.runner.WorkerExecService，線程池（大小默認(rèn)100），可通過worker.exec-threads參數(shù)調(diào)整；

  • 等待執(zhí)行隊(duì)列：同執(zhí)行隊(duì)列，其中未分配到空閑線程而阻塞的任務(wù)數(shù)，即為等待執(zhí)行的任務(wù)數(shù)；

• WorkerServer 會周期性更新 ZooKeeper 中的心跳信息，其中包括等待執(zhí)行隊(duì)列的大小，假如在一次心跳周期內(nèi)啟動了大量的任務(wù)（本次心跳周期內(nèi)等待隊(duì)列還未更新），WorkerServer 獲取到任務(wù)時(shí)先放到等待分配隊(duì)列，等待分配隊(duì)列會將任務(wù)給執(zhí)行隊(duì)列，執(zhí)行隊(duì)列滿時(shí)，會放到等待執(zhí)行隊(duì)列，當(dāng)執(zhí)行隊(duì)列、等待執(zhí)行隊(duì)列都滿時(shí)，等待分配隊(duì)列則無法分配任務(wù)，就會觸發(fā) MasterServer 召回策略，WorkerServer 把任務(wù)返回給 MasterServer，MasterServer 會重新分配。

4.5

容錯(cuò)機(jī)制

4.5.1、腦裂問題

腦裂是指一個(gè)集群由于網(wǎng)絡(luò)故障，被分為至少兩個(gè)彼此無法通信的單獨(dú)集群，此時(shí)如果兩個(gè)集群各自工作，則可能會產(chǎn)生嚴(yán)重的數(shù)據(jù)沖突和錯(cuò)誤。由于網(wǎng)絡(luò)抖動，可能會使得MasterServer節(jié)點(diǎn)短時(shí)間內(nèi)失去和ZooKeeper的心跳，從而發(fā)生znode臨時(shí)節(jié)點(diǎn)的移除事件，觸發(fā)腦裂問題（節(jié)點(diǎn)假死，但仍在分發(fā)工作流），對于這種場景，開發(fā)者通過監(jiān)聽器監(jiān)聽節(jié)點(diǎn)和ZooKeeper的連接情況，一旦斷連則直接觸發(fā)自殺邏輯：

public class MasterConnectionStateListener implements ConnectionListener {
    ...
    @Override
    public void onUpdate(ConnectionState state) {
        switch (state) {
            ...
            case DISCONNECTED:
                logger.warn("registry connection state is {}, ready to stop myself", state);
                registryClient.getStoppable().stop("registry connection state is DISCONNECTED, stop myself");
                break;
            default:
        }
    }
}

4.5.2、宕機(jī)容錯(cuò)

依賴ZooKeeper的監(jiān)聽機(jī)制，MasterServer/WorkerServer各自在啟動時(shí)會向ZooKeeper注冊臨時(shí)節(jié)點(diǎn)，并監(jiān)聽臨時(shí)節(jié)點(diǎn)的remove事件，一旦節(jié)點(diǎn)被移除，則持久化告警信息，等待發(fā)送；

關(guān)鍵實(shí)現(xiàn)類方法：

• MasterDataListener：監(jiān)聽ZK路徑 /dolphinscheduler/nodes/master，若發(fā)生臨時(shí)節(jié)點(diǎn)移除事件，則發(fā)送告警；

• WorkerDataListener：監(jiān)聽ZK路徑 /dolphinscheduler/nodes/worker/${WorkerGroup}，若發(fā)生臨時(shí)節(jié)點(diǎn)移除事件，則發(fā)送告警。

ZooKeeper注冊路徑：

4.5.3、故障轉(zhuǎn)移

故障轉(zhuǎn)移發(fā)生在調(diào)度階段，假如某個(gè) MasterServer 節(jié)點(diǎn)在執(zhí)行中途宕機(jī)或者假死，導(dǎo)致ZooKeeper上的znode被移除，則需要將原本由此節(jié)點(diǎn)代理的工作流任務(wù)，重新轉(zhuǎn)移至其它存活狀態(tài)的 MasterServer 節(jié)點(diǎn)上，否則會導(dǎo)致任務(wù)無法下發(fā)，或者 WorkerServer 執(zhí)行完任務(wù)后無法向任務(wù)關(guān)聯(lián)的 MasterServer 發(fā)送RPC請求。

org.apache.dolphinscheduler.server.master.runner.FailoverExecuteThread 線程隨著 MasterServer 一起啟動，負(fù)責(zé)周期性巡檢元數(shù)據(jù)，篩選出分配到故障節(jié)點(diǎn)的工作流實(shí)例，向WorkerServer發(fā)送TaskKillRequestCommand請求殺死運(yùn)行中的任務(wù)；向Command表寫入RECOVER_TOLERANCE_FAULT_PROCESS記錄，等待MasterServer消費(fèi)；

感謝閱讀！筆者水平有限，若有不當(dāng)之處，請不吝指正！

原文鏈接：https://blog.csdn.net/yeweiouyang/article/details/127212062

參與貢獻(xiàn)

隨著國內(nèi)開源的迅猛崛起，Apache DolphinScheduler 社區(qū)迎來蓬勃發(fā)展，為了做更好用、易用的調(diào)度，真誠歡迎熱愛開源的伙伴加入到開源社區(qū)中來，為中國開源崛起獻(xiàn)上一份自己的力量，讓本土開源走向全球。

參與 DolphinScheduler 社區(qū)有非常多的參與貢獻(xiàn)的方式，包括：

貢獻(xiàn)第一個(gè)PR(文檔、代碼)?我們也希望是簡單的，第一個(gè)PR用于熟悉提交的流程和社區(qū)協(xié)作以及感受社區(qū)的友好度。

社區(qū)匯總了以下適合新手的問題列表：https://github.com/apache/dolphinscheduler/issues/5689

非新手問題列表：https://github.com/apache/dolphinscheduler/issues?q=is%3Aopen+is%3Aissue+label%3A%22volunteer+wanted%22

如何參與貢獻(xiàn)鏈接：https://dolphinscheduler.apache.org/zh-cn/community/development/contribute.html

來吧，DolphinScheduler開源社區(qū)需要您的參與，為中國開源崛起添磚加瓦吧，哪怕只是小小的一塊瓦，匯聚起來的力量也是巨大的。

參與開源可以近距離與各路高手切磋，迅速提升自己的技能，如果您想?yún)⑴c貢獻(xiàn)，我們有個(gè)貢獻(xiàn)者種子孵化群，可以添加社區(qū)小助手微信(Leonard-ds) ，手把手教會您( 貢獻(xiàn)者不分水平高低，有問必答，關(guān)鍵是有一顆愿意貢獻(xiàn)的心 )。

添加社區(qū)小助手微信(Leonard-ds)?

添加小助手微信時(shí)請說明想?yún)⑴c貢獻(xiàn)。

來吧，開源社區(qū)非常期待您的參與。

< ?????>

更多精彩推薦

?在 AWS 上部署無服務(wù)器 Apache DolphinScheduler 任務(wù)調(diào)度系統(tǒng)

?Apache Dolphinscheduler 任務(wù)插件版圖再添 Linkis，大幅提高計(jì)算治理能力

?DolphinScheduler 快速構(gòu)建 Hugging Face 文本分類工作流，基于工作流的機(jī)器學(xué)習(xí)訓(xùn)練部署太強(qiáng)了！

?Apache DolphinScheduler 任務(wù)調(diào)度3.1.0版本源碼剖析

?名額已排到10月 | Apache DolphinScheduler Meetup分享嘉賓繼續(xù)火熱招募中

?【Meetup講師】您有一張社區(qū)認(rèn)證講師證書未領(lǐng)取，點(diǎn)擊領(lǐng)?。?/p>

?非代碼的貢獻(xiàn)也能成為Committer，我與DolphinScheduler社區(qū)的故事

我知道你在看喲文章來源地址http://www.zghlxwxcb.cn/news/detail-620605.html