分布式任務(wù)調(diào)度在電力市場(chǎng)交易系統(tǒng)中的應(yīng)用設(shè)計(jì)

承 林 王海寧 高春成

(南瑞集團(tuán)有限公司 江蘇 南京 211000)(北京科東電力控制系統(tǒng)有限責(zé)任公司 北京 100192)

0 引 言

隨著電力改革的推進(jìn)，電力交易規(guī)模的不斷擴(kuò)大，參與電力市場(chǎng)的各類用戶快速增長(zhǎng)，電力市場(chǎng)也正在從中長(zhǎng)期市場(chǎng)向現(xiàn)貨市場(chǎng)逐步擴(kuò)展。這些都對(duì)系統(tǒng)架構(gòu)、并發(fā)響應(yīng)能力、系統(tǒng)資源分布式調(diào)度使用能力、大數(shù)據(jù)并行計(jì)算能力提出了更新更高的要求。因此借助云計(jì)算技術(shù)、服務(wù)化設(shè)計(jì)思想，對(duì)傳統(tǒng)單體架構(gòu)的電力交易系統(tǒng)進(jìn)行改造已成為一種必然趨勢(shì)[1-3]。

任務(wù)調(diào)度[4-5]作為信息系統(tǒng)中最重要的功能之一，是管理信息系統(tǒng)中各種任務(wù)優(yōu)先級(jí)安排以及任務(wù)執(zhí)行的中樞。任務(wù)調(diào)度算法一般分為事件驅(qū)動(dòng)調(diào)度算法、時(shí)鐘驅(qū)動(dòng)調(diào)度算法[6]。目前，時(shí)鐘驅(qū)動(dòng)調(diào)度算法在電力交易系統(tǒng)平臺(tái)[7-8]中有著廣泛的應(yīng)用。例如橫向數(shù)據(jù)同步、縱向數(shù)據(jù)同步、電力交易日清算、電力交易月結(jié)算、交易對(duì)賬、日志輪轉(zhuǎn)、定期數(shù)據(jù)統(tǒng)計(jì)分析、定期數(shù)據(jù)校驗(yàn)等功能，這些都屬于時(shí)鐘驅(qū)動(dòng)調(diào)度算法的任務(wù)調(diào)度處理方式。然而在分布式微服務(wù)化的信息系統(tǒng)架構(gòu)中，不僅存在著基于時(shí)鐘驅(qū)動(dòng)調(diào)度算法的業(yè)務(wù)處理需求，在各微服務(wù)之間的數(shù)據(jù)請(qǐng)求、數(shù)據(jù)處理的信息交互下，基于事件驅(qū)動(dòng)調(diào)度算法的任務(wù)調(diào)度也將普遍存在。從資源分布、調(diào)度算法、任務(wù)執(zhí)行控制、數(shù)據(jù)一致性等方面看，傳統(tǒng)的單體系統(tǒng)架構(gòu)中任務(wù)調(diào)度框架已無法適應(yīng)分布式系統(tǒng)架構(gòu)中對(duì)任務(wù)調(diào)度的要求。在這種情況下，一些互聯(lián)網(wǎng)企業(yè)基于自身的需求開發(fā)出了一系列分布式調(diào)度系統(tǒng)，如淘寶網(wǎng)的TBschedule和當(dāng)當(dāng)網(wǎng)的Elastic-Job等技術(shù)架構(gòu)，但是這些系統(tǒng)應(yīng)對(duì)業(yè)務(wù)規(guī)模和基礎(chǔ)設(shè)施與電力交易系統(tǒng)存在的差異較大，關(guān)注的問題也往往在負(fù)載均衡上。直接將這些系統(tǒng)架構(gòu)應(yīng)用于集群規(guī)模小，任務(wù)絕對(duì)量少，策略復(fù)雜電力交易系統(tǒng)中并不適合，因此急需一種針對(duì)電力交易業(yè)務(wù)應(yīng)用特點(diǎn)和分布式系統(tǒng)架構(gòu)的任務(wù)調(diào)度解決方案[9-10]。

1 應(yīng)用現(xiàn)狀

在傳統(tǒng)的單體結(jié)構(gòu)中，單機(jī)任務(wù)調(diào)度獲得廣泛應(yīng)用，操作系統(tǒng)和各種語(yǔ)言的調(diào)用庫(kù)，都提供了良好的實(shí)現(xiàn)機(jī)制。當(dāng)前基于F5負(fù)載均衡的多節(jié)點(diǎn)電力交易系統(tǒng)中，仍采用單體調(diào)度任務(wù)模式，其中：有的調(diào)度任務(wù)部署在一個(gè)節(jié)點(diǎn)；有的調(diào)度任務(wù)部署在多個(gè)節(jié)點(diǎn)同時(shí)重復(fù)執(zhí)行。前者容易出現(xiàn)單點(diǎn)故障，一旦配置調(diào)度任務(wù)的節(jié)點(diǎn)宕機(jī)，將會(huì)導(dǎo)致整個(gè)任務(wù)調(diào)度的失效；后者不僅增加無效的負(fù)載，而且容易出現(xiàn)數(shù)據(jù)一致性的問題。

通過將函數(shù)封外部接口、輪訓(xùn)方式調(diào)用或者利用虛擬IP實(shí)現(xiàn)主備機(jī)，實(shí)現(xiàn)一些簡(jiǎn)單分布式任務(wù)調(diào)度的能力，本質(zhì)上仍是將分布式任務(wù)調(diào)度轉(zhuǎn)化為單機(jī)任務(wù)調(diào)度問題。這不僅容易出現(xiàn)單點(diǎn)故障，而且對(duì)復(fù)雜業(yè)務(wù)的調(diào)度任務(wù)分配也難以應(yīng)對(duì)，調(diào)度任務(wù)需要手動(dòng)注冊(cè)在每一個(gè)節(jié)點(diǎn)上，配置和維護(hù)也十分繁瑣。

1.1 分布式任務(wù)調(diào)度場(chǎng)景分類

隨著電力交易系統(tǒng)業(yè)務(wù)的擴(kuò)展和系統(tǒng)架構(gòu)向云計(jì)算、微服務(wù)方向演進(jìn)，任務(wù)調(diào)度的場(chǎng)景也將日益復(fù)雜化。歸納起來，可以考慮如下三種場(chǎng)景：場(chǎng)景A：任務(wù)一執(zhí)行失敗，寫入部分?jǐn)?shù)據(jù)，任務(wù)二讀取到任務(wù)一產(chǎn)生的臟數(shù)據(jù)導(dǎo)致不一致。場(chǎng)景B：任務(wù)一先于任務(wù)二執(zhí)行，而任務(wù)二先于任務(wù)一完成，舊數(shù)據(jù)覆蓋新數(shù)據(jù)同樣導(dǎo)致數(shù)據(jù)不一致問題。場(chǎng)景C：執(zhí)行任務(wù)節(jié)點(diǎn)異常，系統(tǒng)未能成功喚起其他節(jié)點(diǎn)執(zhí)行。

在實(shí)踐中，無論是單機(jī)調(diào)度還是分布式調(diào)度，對(duì)于事物的控制通常由業(yè)務(wù)邏輯本身支持，不同業(yè)務(wù)調(diào)度之間通常是業(yè)務(wù)數(shù)據(jù)依賴。場(chǎng)景A和場(chǎng)景B中，數(shù)據(jù)一致性主要是同一調(diào)度任務(wù)不同批次之間的數(shù)據(jù)一致性。對(duì)于需用各臺(tái)機(jī)器執(zhí)行相同的任務(wù)，本質(zhì)上屬于單機(jī)調(diào)度的范疇。對(duì)于主控性任務(wù)，需要多臺(tái)機(jī)器中選出一臺(tái)執(zhí)行的任務(wù)。如果只在一臺(tái)機(jī)器上執(zhí)行，那么此時(shí)分布式調(diào)度也退化成單機(jī)調(diào)度。對(duì)于場(chǎng)景C在不考慮分布式事物情況下，可以視為主備問題。

1.2 分布式任務(wù)調(diào)度主要解決方式

解決分布式系統(tǒng)中任務(wù)調(diào)度問題，通常有調(diào)度集中式控制和分布式規(guī)劃控制式兩種。

(1) 集中式控制 是任務(wù)的集中觸發(fā)控制，由獨(dú)立的控制模塊控制，各個(gè)節(jié)點(diǎn)只提供任務(wù)觸發(fā)的接口。

(2) 分布式控制 有各個(gè)節(jié)點(diǎn)獨(dú)立的維護(hù)任務(wù)觸發(fā)邏輯，控制中心只起到協(xié)調(diào)的作用。

集中式控制是出現(xiàn)較早也容易實(shí)現(xiàn)的方式，但容易出現(xiàn)單點(diǎn)故障。比如基于虛擬IP進(jìn)行輪詢就是一種簡(jiǎn)單實(shí)現(xiàn)，但虛擬IP失效時(shí)會(huì)引起任務(wù)調(diào)度系統(tǒng)整體失效。在單機(jī)任務(wù)調(diào)度應(yīng)用廣泛的Quartz框架也基于數(shù)據(jù)庫(kù)行鎖機(jī)制提供了一套分布式解決方案，但是仍然無法避免單點(diǎn)故障問題。

分布式控制將任務(wù)調(diào)度控制權(quán)分擔(dān)到各個(gè)節(jié)點(diǎn)上，來避免單點(diǎn)故障問題。但是這種設(shè)計(jì)引入了復(fù)雜性，需要解決分布式系統(tǒng)中的協(xié)調(diào)問題。淘寶網(wǎng)的TBschedule和當(dāng)當(dāng)網(wǎng)的Elastic-Job也主要是通過引入Zookeeper技術(shù)來進(jìn)行解決。

2 解決方案

2.1 關(guān)鍵技術(shù)與設(shè)計(jì)思路

(1) Zookeeper與Leader選舉 Zookeeper[11-14]是一個(gè)分布式的協(xié)調(diào)工具，通過zab算法來解決分布式系統(tǒng)一致性問題。Zookeeper分布式系統(tǒng)中解決統(tǒng)一配置、分布式命名空間、分布式隊(duì)列、Leader選舉等功能。

在分布式系統(tǒng)中，Leader選舉是在一個(gè)跨越幾臺(tái)機(jī)器(節(jié)點(diǎn))的分布式任務(wù)中，指定一臺(tái)機(jī)器作為任務(wù)組織者，在選舉進(jìn)行之前各個(gè)節(jié)點(diǎn)并不知道哪臺(tái)機(jī)器將會(huì)成為L(zhǎng)eader。在Leader選舉之后各臺(tái)機(jī)器都將知道集群中唯一的Leader。因?yàn)閆ookeeper保證節(jié)點(diǎn)之間的數(shù)據(jù)一致性和順序性，使用Zookeeper可以滿足Leader選舉的要求。創(chuàng)建一個(gè)節(jié)點(diǎn)election通知相關(guān)機(jī)器參與選舉，各臺(tái)機(jī)器接到通知后在election節(jié)點(diǎn)下方建立順序臨時(shí)節(jié)點(diǎn)，然后選取序列號(hào)最小的節(jié)點(diǎn)作為L(zhǎng)eader。Leader選舉結(jié)束后，對(duì)Leader進(jìn)行監(jiān)聽，一旦發(fā)現(xiàn)Leader節(jié)點(diǎn)被刪除，重新發(fā)起Leader選舉。但當(dāng)Leader失去時(shí)，所有節(jié)點(diǎn)就會(huì)同時(shí)拉取election節(jié)點(diǎn)下的所有子節(jié)點(diǎn)，來重新進(jìn)行選舉。這就會(huì)對(duì)Zookeeper集群產(chǎn)生很大的壓力。一種改進(jìn)方法就是：任何節(jié)點(diǎn)只監(jiān)聽下一個(gè)兄弟節(jié)點(diǎn)，一旦出現(xiàn)Leader失效，監(jiān)聽Leader的節(jié)點(diǎn)必然成為L(zhǎng)eader，因?yàn)闆]有序號(hào)比它更小。

(2) 任務(wù)分配策略考慮 傳統(tǒng)任務(wù)分配策略類似操作系統(tǒng)的作業(yè)調(diào)度，主要解決同構(gòu)任務(wù)在不同節(jié)點(diǎn)的分配，關(guān)心任務(wù)執(zhí)行的效率和負(fù)載均衡問題。比如在分布式計(jì)算中，子計(jì)算任務(wù)的分配策略側(cè)重考慮的是各個(gè)節(jié)點(diǎn)的CPU、內(nèi)存等資源如何得到充分的利用以及如何在任務(wù)失敗后重新分配。

對(duì)電力交易系統(tǒng)來說，分配策略的復(fù)雜性在于分配策略的多樣性。一種任務(wù)分配策略是各個(gè)節(jié)點(diǎn)都需要同時(shí)執(zhí)行的，如定時(shí)拉取緩存，訪問數(shù)據(jù)庫(kù)；另一種是互斥執(zhí)行的，如定時(shí)結(jié)算等，這種需要在數(shù)個(gè)節(jié)點(diǎn)中選出一個(gè)執(zhí)行，屬于一種互斥性任務(wù)。

對(duì)于涉及的節(jié)點(diǎn)數(shù)目較少，不需過分考慮各個(gè)節(jié)點(diǎn)之間的均衡問題，只保證不出現(xiàn)單點(diǎn)故障的情況，本文采用Leader選舉方式解決互斥問題。當(dāng)Leader失去服務(wù)能力時(shí)候，進(jìn)行Leader切換，互斥任務(wù)也遷移到新的Leader上，形成主從備份。

對(duì)于任務(wù)失敗的處理策略，各種任務(wù)也不同，有些任務(wù)需要重復(fù)執(zhí)行，有些需要任務(wù)放棄執(zhí)行。各種任務(wù)失敗策略以配置形式進(jìn)行注冊(cè)，以滿足各種任務(wù)的需要。

(3) 腦裂問題的預(yù)防和解決思路 在實(shí)際的生產(chǎn)環(huán)境中，網(wǎng)絡(luò)震蕩是隨時(shí)可能出現(xiàn)的，如果Leader所在機(jī)器出現(xiàn)短暫網(wǎng)絡(luò)中斷，集群則會(huì)認(rèn)為L(zhǎng)eader已經(jīng)宕機(jī)，從而重新發(fā)起Leader選舉。舊的Leader本身并不知道集群已經(jīng)產(chǎn)生了新Leader，這種情況常被稱為腦裂。雖然Zookeeper本身保證了腦裂問題不會(huì)長(zhǎng)期出現(xiàn)，但是需要舊Leader等待集群的一個(gè)通知。在(2)中介紹的互斥任務(wù)是在Leader上進(jìn)行執(zhí)行的，即使短暫腦裂，也可能引起任務(wù)重復(fù)執(zhí)行，對(duì)于計(jì)費(fèi)、清算這種業(yè)務(wù)來說這是不可接受。所以Leader需要對(duì)網(wǎng)絡(luò)事件進(jìn)行監(jiān)聽，一旦產(chǎn)生網(wǎng)絡(luò)中斷，立即釋放Leader，同時(shí)重新進(jìn)行選舉時(shí)候，等待一定的時(shí)間間隔，保證失去網(wǎng)絡(luò)的Leader完成釋放。

(4) 任務(wù)的觸發(fā)控制 分布式調(diào)度任務(wù)觸發(fā)控制可以分為時(shí)鐘控制和任務(wù)觸發(fā)兩部分。

時(shí)鐘觸發(fā)：通過時(shí)間滿足時(shí)鐘條件時(shí)，激活相關(guān)動(dòng)作。激活條件可以使用類似Crotnab的時(shí)間表達(dá)式注冊(cè)于任務(wù)調(diào)度中心，表達(dá)式采用字符形式表達(dá)時(shí)間條件，每個(gè)字符分別表達(dá)秒、分鐘、小時(shí)、日、月、星期、年等。這種表達(dá)式可以清晰表達(dá)時(shí)間條件。

任務(wù)控制：任務(wù)的方法、類、執(zhí)行對(duì)象通過字符串的形式進(jìn)行注冊(cè)，滿足時(shí)鐘條件的時(shí)候，通過反射技術(shù)進(jìn)行調(diào)用。在Java語(yǔ)言中提供了原生的反射功能支持。另外，SpingTask[15]和Quartz[16]也提供完整時(shí)鐘機(jī)制和反射調(diào)用框架[17]，并且容易同基于Spring架構(gòu)的電力交易系統(tǒng)進(jìn)行集成，降低了實(shí)用和開發(fā)的難度。

2.2 系統(tǒng)設(shè)計(jì)

電力市場(chǎng)交易邏輯復(fù)雜，調(diào)度任務(wù)場(chǎng)景類型多，特別是分布式服務(wù)化架構(gòu)的引入，使得電力交易系統(tǒng)對(duì)分布式任務(wù)調(diào)度存在較迫切的應(yīng)用需求。

本文依據(jù)電力交易系統(tǒng)的應(yīng)用場(chǎng)景特點(diǎn)、現(xiàn)有技術(shù)架構(gòu)特點(diǎn)以及分布式架構(gòu)的技術(shù)要求，并參考互聯(lián)網(wǎng)行業(yè)的成熟解決方案，提出一個(gè)基于分布式控制的任務(wù)調(diào)度解決方案。其架構(gòu)如圖1所示。

圖1 分布式調(diào)度方案架構(gòu)圖

該方案主要由管理界面、任務(wù)調(diào)度中心、任務(wù)調(diào)度客戶端三個(gè)部分組成。用戶界面提供給用戶注冊(cè)、編輯任務(wù)功能；任務(wù)調(diào)度中心對(duì)任務(wù)分配進(jìn)行管理；任務(wù)調(diào)度客戶端負(fù)責(zé)任務(wù)觸發(fā)和執(zhí)行。

(1) 管理界面 管理界面提供一個(gè)可視化的交互平臺(tái)，提供調(diào)度任務(wù)注冊(cè)、暫停、取消等功能，監(jiān)控任務(wù)的執(zhí)行的結(jié)果。

任務(wù)注冊(cè)：任務(wù)執(zhí)行是將所在機(jī)器(節(jié)點(diǎn))具體指定的類和方法，以及任務(wù)執(zhí)行的Crontab時(shí)間表達(dá)式注冊(cè)于系統(tǒng)。對(duì)于注冊(cè)于多臺(tái)機(jī)器(節(jié)點(diǎn))的任務(wù)，還需指定是互斥任務(wù)還是并發(fā)任務(wù)?；コ馊蝿?wù)為在滿足任務(wù)條件時(shí)選出一臺(tái)機(jī)器(節(jié)點(diǎn))執(zhí)行任務(wù)，其他機(jī)器作為備份；并發(fā)任務(wù)為這些機(jī)器(節(jié)點(diǎn))同時(shí)執(zhí)行的任務(wù)。

任務(wù)修改：管理界面提供功能啟動(dòng)和暫停任務(wù)，可以在任務(wù)執(zhí)行時(shí)刻前暫停任務(wù)。

任務(wù)監(jiān)控：通過管理界面查看任務(wù)的狀態(tài)、歷史執(zhí)行時(shí)間、執(zhí)行結(jié)果、互斥任務(wù)顯示、執(zhí)行的實(shí)際機(jī)器等信息。

(2) 任務(wù)調(diào)度中心 如圖2所示，任務(wù)調(diào)度中心為調(diào)度系統(tǒng)核心，控制各個(gè)節(jié)點(diǎn)任務(wù)的實(shí)際執(zhí)行行為。本文提出的調(diào)度中心使用基于Zookeeper的方案，用戶通過管理界面注冊(cè)任務(wù)時(shí)，是注冊(cè)在各個(gè)機(jī)器對(duì)應(yīng)的節(jié)點(diǎn)下面，并在該節(jié)點(diǎn)下面建立子節(jié)點(diǎn)?？蛻粜薷娜蝿?wù)時(shí)，調(diào)度中心就更新對(duì)應(yīng)節(jié)點(diǎn)下面的內(nèi)容。管理端刪除任務(wù)時(shí)候，將對(duì)應(yīng)任務(wù)節(jié)點(diǎn)刪除。

圖2 任務(wù)調(diào)度中心

(3) 任務(wù)調(diào)度客戶端 任務(wù)調(diào)度客戶端部署執(zhí)行的應(yīng)用，客戶端部分負(fù)責(zé)調(diào)度的具體執(zhí)行，客戶端的主要結(jié)構(gòu)有監(jiān)聽器、任務(wù)容器、任務(wù)調(diào)度器，如圖3所示。

圖3 任務(wù)客戶端示意圖

監(jiān)聽器在客戶端所在應(yīng)用進(jìn)程初始化開始時(shí)對(duì)調(diào)度中心對(duì)應(yīng)的IP節(jié)點(diǎn)開始監(jiān)聽，并從該節(jié)點(diǎn)拉取任務(wù)數(shù)據(jù)保存到任務(wù)容器中。如果子節(jié)點(diǎn)發(fā)生增加、刪除、修改就要對(duì)任務(wù)容器中對(duì)應(yīng)的任務(wù)信息進(jìn)行增加、刪除、修改，并且通知任務(wù)控制器進(jìn)行相應(yīng)的處理。

任務(wù)容器：用來存儲(chǔ)本地任務(wù)的具體信息，如任務(wù)名稱、任務(wù)類型、任務(wù)調(diào)度方法、調(diào)度表達(dá)式、任務(wù)狀態(tài)等信息。

任務(wù)調(diào)度器：初始化時(shí)任務(wù)調(diào)度從任務(wù)容器獲取任務(wù)，依據(jù)任務(wù)的時(shí)間表達(dá)式來啟動(dòng)任務(wù)，并將執(zhí)行狀態(tài)寫到任務(wù)容器中。當(dāng)監(jiān)聽器監(jiān)測(cè)到新增或者啟動(dòng)事件時(shí)，調(diào)度器將會(huì)從任務(wù)容器中取出任務(wù)，檢查任務(wù)狀態(tài)，如果任務(wù)尚未啟動(dòng)就啟動(dòng)它，并更新狀態(tài)到任務(wù)容器；如果任務(wù)執(zhí)行失敗，則根據(jù)配置判斷是否需要重復(fù)執(zhí)行。

如果監(jiān)聽到暫?；蛘邉h除事件，將首先修改狀態(tài)，再將其從任務(wù)容器中刪除。

如果任務(wù)的類型是互斥任務(wù)，客戶端初始化時(shí)，就會(huì)發(fā)起Leader選舉，從多臺(tái)備用機(jī)中選出一臺(tái)，作為實(shí)際執(zhí)行調(diào)度的機(jī)器。調(diào)度器在加載任務(wù)時(shí)，如果檢查到自身是Leader就正常啟動(dòng)，如果不是Leader就放棄啟動(dòng)。任務(wù)啟動(dòng)后Leader選舉的狀態(tài)保持監(jiān)聽，如果監(jiān)聽到喪失Leader權(quán)限，就暫停任務(wù)，如果監(jiān)聽到獲得Leader身份，則重啟動(dòng)調(diào)度任務(wù)。

(4) 效果監(jiān)控功能 為了調(diào)度任務(wù)進(jìn)行管理和監(jiān)控，任務(wù)的注冊(cè)、執(zhí)行、完成或者異常等數(shù)據(jù)將實(shí)時(shí)寫入消息總線，并通過消息總線同步到數(shù)據(jù)庫(kù)中。管理界面通過發(fā)布訂閱機(jī)制與數(shù)據(jù)總線保持監(jiān)聽，并將接收到的消息實(shí)時(shí)同步到管理界面。

監(jiān)控模塊對(duì)寫入消息總線的數(shù)據(jù)進(jìn)行過濾，當(dāng)監(jiān)控到任務(wù)異常消息時(shí)觸發(fā)報(bào)警通知管理員處理。由于本文闡釋系統(tǒng)不考慮對(duì)分布式事物的控制，即使在單機(jī)系統(tǒng)的調(diào)度中，調(diào)度系統(tǒng)本身也不牽涉到回滾等事物操作的，所以在實(shí)踐中采用報(bào)警觸發(fā)的機(jī)制是能滿足實(shí)際業(yè)務(wù)需要的。

3 方案驗(yàn)證

基于本文提出的方案構(gòu)建的系統(tǒng)，在實(shí)踐中運(yùn)行了三個(gè)月，其中普通節(jié)點(diǎn)4臺(tái)，執(zhí)行主控性任務(wù)機(jī)器2臺(tái)，任務(wù)執(zhí)行的成功率為99.98%，未發(fā)生因Leader切換失敗或任務(wù)失效等情況，也未發(fā)生因短期腦裂產(chǎn)生任務(wù)重復(fù)執(zhí)行的情況。

對(duì)于電力交易系統(tǒng)而言，負(fù)載性能并不是業(yè)務(wù)痛點(diǎn)所在。為應(yīng)對(duì)更大規(guī)模的集群介入，對(duì)該系統(tǒng)進(jìn)行了壓力測(cè)試，結(jié)果如表1所示。

表1 壓力測(cè)試結(jié)果

本系統(tǒng)采用分布式的技術(shù)架構(gòu)，對(duì)于任務(wù)調(diào)用中心的Zookeeper，可以通過擴(kuò)充集群來提高負(fù)載性能，對(duì)于管理端界面，也可以通過負(fù)載均衡的手段，實(shí)現(xiàn)水平擴(kuò)展提高吞吐量。

在系統(tǒng)運(yùn)行的幾個(gè)月中，除了系統(tǒng)上線引起Leader切換外，因網(wǎng)絡(luò)問題出現(xiàn)幾次意外的切換，但都通過本文的Leader選舉改進(jìn)機(jī)制和任務(wù)注冊(cè)管理功能，防止了分布式系統(tǒng)中Leader選舉的腦裂問題，從而保護(hù)了任務(wù)不會(huì)因?yàn)榫W(wǎng)絡(luò)震蕩被重復(fù)調(diào)度執(zhí)行。

4 結(jié) 語(yǔ)

本文提出了一種基于改進(jìn)式Leader選舉的分布式任務(wù)調(diào)度系統(tǒng)，解決了電力交易系統(tǒng)從單體架構(gòu)演進(jìn)到分布式架構(gòu)中的復(fù)雜任務(wù)調(diào)度問題。在分析了電力交易業(yè)務(wù)和電力交易系統(tǒng)的基礎(chǔ)上，利用改進(jìn)式Leader選舉方式解決了互斥任務(wù)的調(diào)度問題，提供了可配置的失敗任務(wù)處理方式。為多樣性的電力交易系統(tǒng)提供了靈活的支持，并通過方案驗(yàn)證和壓力測(cè)試，證明該方案不僅能夠滿足當(dāng)前系統(tǒng)的需要，而且在面對(duì)更大規(guī)模業(yè)務(wù)需要時(shí)，依然能夠良好運(yùn)行。