分散式任務排程系統設計小結

前言

分散式任務排程系統應用範圍很廣，或者說有很多偏後臺的分散式系統設計往往可以借鑑分散式排程系統的設計，目前也有很多分散式任務排程系統的開源，比如dkron，XXL-JOB等。這裡簡單的做一個任務排程系統設計小結，後續可以找時間實現。

業務場景

支援一次性任務

支援廣播任務

支援任務編排

支援靈活的時間排程

分散式任務排程系統核心需求

支援水平擴充套件(系統可以透過水平擴充套件提高整體系統的處理能力)

運維自動化(擴縮容自動化負載均衡)

高可用(不能有單點風險)

高效能(排程延遲儘量低)

高可靠(支援自動容錯，重試)

分散式任務排程系統架構設計

分散式任務排程系統的架構設計圍繞上面的核心需求和業務場景進行設計，目前我給出的解決方案。

支援水平擴充套件(master slave架構，master負責全域性的負載均衡，提供租約機制，slave負責具體的排程執行)

運維自動化(當出現自動擴縮容，master負責負載均衡，避免熱點問題)

高可用(master 透過etcd進行選主，避免單點，slave不存在單點)

高效能(slave上報延遲等資訊給master，由master進行均衡轉移，儘量平衡每個slave的負載)

高可靠(租約機制，後設資料存後設資料儲存，減少節點之間的依賴)

master 設計

master的核心是負責全域性資訊和負載均衡，下發租約，交換心跳資訊。master的啟動流程：

搶佔master鎖，保證高可用

等待server 透過心跳聯絡，交換資訊，下發租約

假如出現擴縮容或者負載不均衡，發起負載均衡操作(通知相關server停止部分遷移任務的排程，遷移任務通知新處理的server節點)

server 設計

server 是系統的核心設計，負責具體處理任務排程和執行，3個元件組成：

api(負責對外的api請求接入，支援webui和client接入)

scheduler(排程器負責任務的排程，workflow負責任務之間的編排，corn負責定時任務的排程，scheduler負責優先順序的排程)

executor(負責具體的任務執行，支援任務依賴，服務發現，服務通訊)

server api 的整體啟動流程：

接受任務的api請求，假如不存在任務依賴直接寫入到當前server的meta storage，存在依賴並不在當前server節點，寫入特殊的一個meta storage目錄，其他server可以watch並分別處理。

接受任務後傳送到排程器元件開始進行排程

server scheduler的整體設計：

收到api的任務放入cron元件，cron元件需要提供擴充套件介面，方便新的定時解析

cron元件任務排程時間到後，透過workflow組成任務編排。

任務編排後scheduler根據排程策略進行任務排程，併傳送給executor元件

server executor設計：

executor接受task後，需要先進行服務發現，發現上游執行節點(可上游透過client主動上報，也可直接配置，單播可RR執行，廣播則需要收集所有節點)

transport 實現和上游的通訊協議(可標準協議 http，也可透過client接入用rpc協議接入 預設標準http協議)

executor 負責具體的執行，需要支援任務依賴，不同的任務可並行執行，存在任務依賴的需要根據依賴執行，同時需要支援重試等策略，執行結果存入storage，方便後續查詢

容錯設計

分散式系統最大的難點就是容錯設計，這裡可能出現的錯誤：

server與meta 出現網路問題

server 可能出現fail，stop，recover

server 可能與master 出現網路問題

master出現fail，stop，recover

我們系統設計的解決方案

server與meta 出現網路問題(兩種解決方案 master直接回收租約，併發起任務遷移， 2 正常執行，發出告警，master負載均衡處理跳過這個節點)

server 可能出現fail，stop，recover(stop 發起任務遷移，recover 不需要處理，server自己恢復 master發現server下線後可等待一小段時間，假如一直不恢復進行遷移)

server 可能與master 出現網路問題(master發起遷移，server收到遷移資訊後，告警並停止任務排程執行)

master出現fail，stop，recover(master重新選主，server收到新的master通知主動聯絡)