本發(fā)明涉及互聯(lián)網(wǎng)技術(shù)領(lǐng)域，具體涉及一種執(zhí)行任務(wù)的方法及系統(tǒng)。

背景技術(shù)：

中國的彩民數(shù)量逐年增長，隨著互聯(lián)網(wǎng)的發(fā)展，越來越多的彩民選擇在互聯(lián)網(wǎng)平臺進(jìn)行購彩。網(wǎng)絡(luò)出票中心是整個(gè)網(wǎng)絡(luò)彩票系統(tǒng)的核心，它負(fù)責(zé)整個(gè)網(wǎng)絡(luò)彩票系統(tǒng)的投注、出票流程。因?yàn)橘彶适且环N有時(shí)效性的活動(dòng)，所以網(wǎng)絡(luò)出票中心需要在截止時(shí)間前為用戶完成下單和出票。而在購彩高峰期，瞬間的下單量十分巨大。面對巨大的訪問量，如何保證系統(tǒng)的高可用性是一個(gè)關(guān)鍵問題。同時(shí)隨著數(shù)據(jù)量的增加，如何水平擴(kuò)展并降低維護(hù)成本也是另外一個(gè)關(guān)鍵問題。

現(xiàn)有的解決海量數(shù)據(jù)的方案為：通過分庫分表(Sharding)在數(shù)據(jù)存儲層實(shí)現(xiàn)伸縮，來降低數(shù)據(jù)庫的壓力。具體地，將原來單一數(shù)據(jù)庫按照一定的規(guī)則進(jìn)行切分，把數(shù)據(jù)分散到多臺物理機(jī)上存儲，從而突破單機(jī)限制。這種切分對上層應(yīng)用來說是透明的，多個(gè)物理上分布的數(shù)據(jù)庫在邏輯上依然是一個(gè)庫。但是，該方案具有如下的缺點(diǎn)：

a.數(shù)據(jù)庫壓力問題

所有的任務(wù)都存在數(shù)據(jù)庫中，會(huì)有幾十個(gè)任務(wù)調(diào)度定時(shí)的訪問數(shù)據(jù)庫，數(shù)據(jù)庫會(huì)頻繁的輸入輸出。隨著任務(wù)量的逐漸增加，數(shù)據(jù)庫壓力很大，穩(wěn)定性差。

b.單點(diǎn)問題

在高并發(fā)的環(huán)境下，會(huì)存在重復(fù)下單、重復(fù)投注的問題，造成不必要的經(jīng)濟(jì)損失。

技術(shù)實(shí)現(xiàn)要素：

有鑒于此，本發(fā)明提供一種處理任務(wù)的方法及系統(tǒng)，有助于解決數(shù)據(jù)庫壓力問題和單點(diǎn)問題。本發(fā)明的其他目的和有益效果可從具體實(shí)施方式中得出。

為實(shí)現(xiàn)上述目的，根據(jù)本發(fā)明的一個(gè)方面，提供了一種處理任務(wù)的方法，包括：業(yè)務(wù)中心創(chuàng)建多個(gè)任務(wù)，所述任務(wù)分為預(yù)設(shè)類型任務(wù)和其他類型任務(wù)；所述業(yè)務(wù)中心將所述預(yù)設(shè)類型任務(wù)發(fā)送到任務(wù)驅(qū)動(dòng)引擎中，所述任務(wù)驅(qū)動(dòng)引擎為多線程并發(fā)任務(wù)調(diào)度框架；多個(gè)工作節(jié)點(diǎn)各自執(zhí)行從所述任務(wù)驅(qū)動(dòng)引擎中獲取到的所述預(yù)設(shè)類型任務(wù)；所述業(yè)務(wù)中心將所述其他類型任務(wù)發(fā)送到數(shù)據(jù)庫的任務(wù)表中；所述多個(gè)工作節(jié)點(diǎn)各自執(zhí)行從所述數(shù)據(jù)庫的任務(wù)表中獲取到的所述其他類型任務(wù)。

可選地，在所述工作節(jié)點(diǎn)執(zhí)行從所述任務(wù)驅(qū)動(dòng)引擎中獲取到的預(yù)設(shè)類型任務(wù)失敗的情況下，所述方法還包括：所述工作節(jié)點(diǎn)重新從所述任務(wù)驅(qū)動(dòng)引擎中獲取相應(yīng)的所述預(yù)設(shè)類型任務(wù)并執(zhí)行；所述任務(wù)驅(qū)動(dòng)引擎將累計(jì)失敗次數(shù)加1，然后判斷所述累計(jì)失敗次數(shù)是否超過閥值，若是，則將執(zhí)行失敗的預(yù)設(shè)類型任務(wù)從任務(wù)隊(duì)列中消費(fèi)，并且將一個(gè)與執(zhí)行失敗的預(yù)設(shè)類型任務(wù)相同的預(yù)設(shè)類型任務(wù)插入所述任務(wù)隊(duì)列的隊(duì)尾。

可選地，還包括：所述業(yè)務(wù)中心將所述預(yù)設(shè)類型任務(wù)發(fā)送到所述數(shù)據(jù)庫的任務(wù)表中；在所述任務(wù)驅(qū)動(dòng)引擎故障的情況下，所述多個(gè)工作節(jié)點(diǎn)各自執(zhí)行從所述數(shù)據(jù)庫的任務(wù)表中獲取到的預(yù)設(shè)類型任務(wù)。

為實(shí)現(xiàn)上述目的，根據(jù)本發(fā)明的另一方面，提供了一種處理任務(wù)的系統(tǒng)，其特征在于，包括：業(yè)務(wù)中心、任務(wù)驅(qū)動(dòng)引擎、數(shù)據(jù)庫以及多個(gè)工作節(jié)點(diǎn)，其中，所述業(yè)務(wù)中心用于創(chuàng)建多個(gè)任務(wù)，所述任務(wù)分為預(yù)設(shè)類型任務(wù)和其他類型任務(wù)，用于將所述預(yù)設(shè)類型任務(wù)發(fā)送到所 述任務(wù)驅(qū)動(dòng)引擎中，以及用于將所述其他類型任務(wù)發(fā)送到所述數(shù)據(jù)庫的任務(wù)表中；所述任務(wù)驅(qū)動(dòng)引擎為多線程并發(fā)任務(wù)調(diào)度框架；所述多個(gè)工作節(jié)點(diǎn)用于各自執(zhí)行從所述任務(wù)驅(qū)動(dòng)引擎中獲取到的所述預(yù)設(shè)類型任務(wù)，以及用于各自執(zhí)行從所述數(shù)據(jù)庫的任務(wù)表中獲取到的所述其他類型任務(wù)。

可選地，所述工作節(jié)點(diǎn)還用于在所述工作節(jié)點(diǎn)執(zhí)行從所述任務(wù)驅(qū)動(dòng)引擎中獲取到的預(yù)設(shè)類型任務(wù)失敗的情況下，重新從所述任務(wù)驅(qū)動(dòng)引擎中獲取相應(yīng)的所述預(yù)設(shè)類型任務(wù)并執(zhí)行；所述任務(wù)驅(qū)動(dòng)引擎還用于當(dāng)所述工作節(jié)點(diǎn)執(zhí)行從所述任務(wù)驅(qū)動(dòng)引擎中獲取到的相應(yīng)的所述預(yù)設(shè)類型任務(wù)失敗時(shí)，將累計(jì)失敗次數(shù)加1，然后判斷所述累計(jì)失敗次數(shù)是否超過閥值，若是，則將執(zhí)行失敗的預(yù)設(shè)類型任務(wù)從任務(wù)隊(duì)列中消費(fèi)，重新將一個(gè)與執(zhí)行失敗的預(yù)設(shè)類型任務(wù)相同的預(yù)設(shè)類型任務(wù)插入所述任務(wù)隊(duì)列的隊(duì)尾。

可選地，所述業(yè)務(wù)中心還用于將所述預(yù)設(shè)類型任務(wù)發(fā)送到所述數(shù)據(jù)庫的任務(wù)表中；所述多個(gè)工作節(jié)點(diǎn)還用于在所述任務(wù)驅(qū)動(dòng)引擎故障的情況下，各自執(zhí)行從所述數(shù)據(jù)庫的任務(wù)表中獲取到的預(yù)設(shè)類型任務(wù)。

根據(jù)本發(fā)明的技術(shù)方案，通過引入任務(wù)驅(qū)動(dòng)引擎，一方面可以將分布式高并發(fā)的預(yù)設(shè)類型任務(wù)從數(shù)據(jù)庫的任務(wù)表中剝離出來，減輕了數(shù)據(jù)庫的壓力，另一方面任務(wù)驅(qū)動(dòng)引擎本身能夠?qū)⑷舾蓚€(gè)并發(fā)的任務(wù)變?yōu)槿蝿?wù)隊(duì)列，解決了單點(diǎn)問題。

附圖說明

附圖用于更好地理解本發(fā)明，不構(gòu)成對本發(fā)明的不當(dāng)限定。其中：

圖1是根據(jù)本發(fā)明實(shí)施例的執(zhí)行任務(wù)的方法的主要步驟的示意圖。

圖2是根據(jù)本發(fā)明實(shí)施例的執(zhí)行任務(wù)的系統(tǒng)的主要部件的示意圖。

具體實(shí)施方式

以下結(jié)合附圖對本發(fā)明的示范性實(shí)施例做出說明，其中包括本發(fā)明實(shí)施例的各種細(xì)節(jié)以助于理解，應(yīng)當(dāng)將它們認(rèn)為僅僅是示范性的。因此，本領(lǐng)域普通技術(shù)人員應(yīng)當(dāng)認(rèn)識到，可以對這里描述的實(shí)施例做出各種改變和修改，而不會(huì)背離本發(fā)明的范圍和精神。同樣，為了清楚和簡明，以下的描述中省略了對公知功能和結(jié)構(gòu)的描述。

圖1是根據(jù)本發(fā)明實(shí)施例的執(zhí)行任務(wù)的方法的主要步驟的示意圖。如圖1所示，該方法主要包括如下的步驟S11至步驟S15。

步驟S11：業(yè)務(wù)中心創(chuàng)建多個(gè)任務(wù)。其中，任務(wù)分為預(yù)設(shè)類型任務(wù)和其他類型任務(wù)兩類。

為使本發(fā)明被更好地理解，下面結(jié)合網(wǎng)絡(luò)購彩情景來舉例說明。業(yè)務(wù)中心通常是指網(wǎng)銷彩票服務(wù)商系統(tǒng)后臺，相當(dāng)于服務(wù)端。預(yù)設(shè)類型任務(wù)通常是指具有分布式、高并發(fā)的特點(diǎn)的任務(wù)，這些任務(wù)如果按照傳統(tǒng)方式交給數(shù)據(jù)庫來處理，會(huì)給數(shù)據(jù)庫帶來很大壓力。預(yù)設(shè)類型任務(wù)具體包括哪些任務(wù)這是由人工預(yù)先確定的。在網(wǎng)絡(luò)購彩情景中預(yù)設(shè)類型任務(wù)可以包括彩票投注任務(wù)、彩票出票任務(wù)等等任務(wù)。在其他情景中預(yù)設(shè)類型任務(wù)可以是話費(fèi)充值任務(wù)、秒殺下單任務(wù)等等任務(wù)。所有任務(wù)中去除預(yù)設(shè)類型任務(wù)，剩下的就是其他類型任務(wù)，具體地可以是用戶登錄認(rèn)證任務(wù)、支付任務(wù)等等任務(wù)。

步驟S12：業(yè)務(wù)中心將預(yù)設(shè)類型任務(wù)發(fā)送到任務(wù)驅(qū)動(dòng)引擎中，其中，任務(wù)驅(qū)動(dòng)引擎為多線程并發(fā)任務(wù)調(diào)度框架。

例如，任務(wù)驅(qū)動(dòng)引擎可以為基于Redis和MongoDB實(shí)現(xiàn)的多線程并發(fā)任務(wù)調(diào)度框架，該設(shè)置的任務(wù)驅(qū)動(dòng)引擎具有技術(shù)成熟，簡單易行，通用性強(qiáng)等優(yōu)點(diǎn)。任務(wù)驅(qū)動(dòng)引擎可以理解為數(shù)據(jù)庫的緩存層。任務(wù)驅(qū)動(dòng)引擎能夠?qū)θ蝿?wù)進(jìn)行時(shí)序上的安排調(diào)整，將并發(fā)的多個(gè)任務(wù)變成順序執(zhí)行的任務(wù)隊(duì)列。需要說明的是，BasePopTasksHandler和 BasePushTaskManager是任務(wù)驅(qū)動(dòng)引擎處理任務(wù)的抽象類，需要集成它們來實(shí)現(xiàn)任務(wù)的插入(push)和取出(pop)，可以通過模板模式來實(shí)現(xiàn)。為了方便后續(xù)業(yè)務(wù)擴(kuò)展，定義TaskTypeExecutor接口，從任務(wù)驅(qū)動(dòng)引擎pop消息實(shí)現(xiàn)該接口即可。

步驟S13：多個(gè)工作節(jié)點(diǎn)各自執(zhí)行從任務(wù)驅(qū)動(dòng)引擎中獲取到的預(yù)設(shè)類型任務(wù)。

多個(gè)節(jié)點(diǎn)是指分布在地理上不同位置的多個(gè)客戶端，它們是執(zhí)行各種任務(wù)的主體。例如多個(gè)彩民購彩應(yīng)用APP，它們可以執(zhí)行彩票投注任務(wù)；又例如多個(gè)彩票代理商出票應(yīng)用APP，它們可以執(zhí)行彩票出票任務(wù)。

步驟S14：業(yè)務(wù)中心將其他類型任務(wù)發(fā)送到數(shù)據(jù)庫的任務(wù)表中。

需要說明的是，步驟S14不一定要在步驟S12和步驟S13之后執(zhí)行，只需要在步驟S11之后執(zhí)行即可。

步驟S15：多個(gè)工作節(jié)點(diǎn)各自執(zhí)行從數(shù)據(jù)庫的任務(wù)表中獲取到的其他類型任務(wù)。

需要說明的是，步驟S15不一定要在步驟S12和步驟S13之后執(zhí)行，只需要在步驟S14之后執(zhí)行即可。

由上可知，本發(fā)明實(shí)施例的處理任務(wù)方法通過集成任務(wù)驅(qū)動(dòng)引擎實(shí)現(xiàn)隊(duì)列任務(wù)，第一方面，將分布式高并發(fā)的預(yù)設(shè)類型任務(wù)從數(shù)據(jù)庫中剝離出來，緩解數(shù)據(jù)庫壓力的同時(shí)也提高了系統(tǒng)性能；第二方面，通過引入任務(wù)驅(qū)動(dòng)引擎任務(wù)可以使預(yù)設(shè)類型任務(wù)嚴(yán)格按照隊(duì)列執(zhí)行，避免并發(fā)任務(wù)帶來的故障，解決了單點(diǎn)問題。因此，本發(fā)明實(shí)施例的處理任務(wù)方法具有處理效率高，簡便易行，穩(wěn)定健壯等優(yōu)點(diǎn)。

實(shí)際應(yīng)用中由于各種原因，工作節(jié)點(diǎn)執(zhí)行從任務(wù)驅(qū)動(dòng)引擎中獲取到的相應(yīng)的預(yù)設(shè)類型任務(wù)時(shí)有可能會(huì)失敗。傳統(tǒng)技術(shù)中任務(wù)驅(qū)動(dòng)引擎通常對于執(zhí)行失敗的任務(wù)有失敗次數(shù)限制，超過一定閾值(例如50次)將被放入失敗隊(duì)列，等待預(yù)設(shè)時(shí)長(例如20分鐘)之后才會(huì)被執(zhí)行。這對一些有時(shí)限要求的任務(wù)來說，這樣的流程是不符合要求的。以網(wǎng)絡(luò)購彩情景為例，如果彩票投注任務(wù)或彩票出票任務(wù)被放入失敗隊(duì)列，當(dāng)下次被執(zhí)行時(shí)，可能已經(jīng)超過了投注、出票截止時(shí)間，造成下單失敗。針對于此，在本發(fā)明的實(shí)施方式中，當(dāng)工作節(jié)點(diǎn)執(zhí)行從任務(wù)驅(qū)動(dòng)引擎中獲取到的相應(yīng)的預(yù)設(shè)類型任務(wù)失敗時(shí)，還可以包括如下步驟S16和步驟S17(圖1中未示出)：

步驟S16：工作節(jié)點(diǎn)重新從任務(wù)驅(qū)動(dòng)引擎中獲取相應(yīng)的預(yù)設(shè)類型任務(wù)并執(zhí)行。

步驟S17：任務(wù)驅(qū)動(dòng)引擎將累計(jì)失敗次數(shù)加1，然后判斷累計(jì)失敗次數(shù)是否超過閥值，若累計(jì)失敗次數(shù)超過閾值，則執(zhí)行以下步驟：任務(wù)驅(qū)動(dòng)引擎將累計(jì)失敗次數(shù)清零；任務(wù)驅(qū)動(dòng)引擎將執(zhí)行失敗的預(yù)設(shè)類型任務(wù)從任務(wù)隊(duì)列中消費(fèi)，并重新將一個(gè)相同的預(yù)設(shè)類型任務(wù)請求插入任務(wù)隊(duì)列的隊(duì)尾。

該實(shí)施方式中，當(dāng)一個(gè)任務(wù)執(zhí)行失敗次數(shù)超過閾值時(shí)，通過立即取消當(dāng)前任務(wù)并且重新向任務(wù)驅(qū)動(dòng)引擎推送一個(gè)相同任務(wù)，這樣就能夠保證工作節(jié)點(diǎn)幾乎不間斷地嘗試執(zhí)行任務(wù)，直到任務(wù)成功執(zhí)行為止，維護(hù)了流程的正常運(yùn)行。

傳統(tǒng)的執(zhí)行分布式任務(wù)技術(shù)方案中，還會(huì)遇到水平擴(kuò)展問題以及分布式管理一致性問題。具體地：在系統(tǒng)運(yùn)行一段時(shí)間后，數(shù)據(jù)就會(huì)積累到超過承載上限，此時(shí)就需要對數(shù)據(jù)庫進(jìn)行擴(kuò)容，也就是增加新的物理節(jié)點(diǎn)來分?jǐn)倲?shù)據(jù)。如果是根據(jù)ID進(jìn)行路由，那么就需要重新計(jì)算數(shù)據(jù)進(jìn)行遷移。如果是按照增量區(qū)進(jìn)行路由，也就是近期系統(tǒng)的讀 寫都集中在新節(jié)點(diǎn)上，就會(huì)有“熱點(diǎn)”問題，從而影響性能。面對這種兩難的處境，Sharding擴(kuò)容顯得異常困難。另外，如果要修改分布式節(jié)點(diǎn)中的相關(guān)配置，如果分布式節(jié)點(diǎn)數(shù)目眾多時(shí)，維護(hù)起來人力成本巨大且容易出錯(cuò)。針對于此，在本發(fā)明的實(shí)施方式中，工作節(jié)點(diǎn)可以基于zookeeper實(shí)現(xiàn)，集成curator框架，這樣可以實(shí)現(xiàn)統(tǒng)一的分布式節(jié)點(diǎn)配置管理。

ZooKeeper是一個(gè)為分布式應(yīng)用提供一致性服務(wù)的軟件，提供的功能包括：配置維護(hù)、名字服務(wù)、分布式同步、組服務(wù)等。根據(jù)Zookeeper的結(jié)構(gòu)特性，分布式配置以組的形式體現(xiàn)，分組也使得水平擴(kuò)展更加容易，我們可以根據(jù)實(shí)際需求隨時(shí)增減組，也可以增減組內(nèi)服務(wù)器數(shù)量。組對象可以由HostGroup類實(shí)現(xiàn)，通過Spring注入分組信息。每個(gè)組是獨(dú)立的，每個(gè)組的配置信息存儲目錄為：/zookeeper根路徑/組名，在系統(tǒng)中通過CacheConfigureImpl來實(shí)現(xiàn)。Curator框架提供了監(jiān)聽接口PathChildrenCacheListener，該接口可以監(jiān)聽節(jié)點(diǎn)的變化，可以根據(jù)需求實(shí)現(xiàn)該接口，例如修改線程池隊(duì)列大小，修改任務(wù)執(zhí)行頻率等。只要一個(gè)節(jié)點(diǎn)變化，其它節(jié)點(diǎn)都會(huì)同步更新。

當(dāng)系統(tǒng)啟動(dòng)時(shí)，會(huì)將Zookeeper的配置緩存到本地，當(dāng)工作節(jié)點(diǎn)與Zookeeper連接不通時(shí)，讀取本地緩存，為了保證本地緩存能與Zookeeper服務(wù)端配置一致，可以啟動(dòng)一個(gè)線程定時(shí)檢查Zookeeper是否有變化，如果有變化就同步本地緩存，該功能實(shí)現(xiàn)類為LocalConfigureManagerImpl。

由上可知，基于Zookeeper的監(jiān)聽機(jī)制可以很容易的擴(kuò)展業(yè)務(wù)，只需實(shí)現(xiàn)監(jiān)聽接口，當(dāng)一個(gè)節(jié)點(diǎn)變化時(shí)，就能保證其它節(jié)點(diǎn)同步變化。分布式配置可以保證分布式節(jié)點(diǎn)的同步變化，分組的實(shí)現(xiàn)使得系統(tǒng)的水平擴(kuò)展更加容易，不僅降低了部署成本和維護(hù)成本，而且也降低了出錯(cuò)率。

在本發(fā)明的實(shí)施方式中，還可以包括以下的步驟S18和步驟S19(圖1中未示出)。

步驟S18：業(yè)務(wù)中心將所有預(yù)設(shè)類型任務(wù)發(fā)送到數(shù)據(jù)庫的任務(wù)表中。

需要說明的是，步驟S18位于步驟S11之后。將步驟S18聯(lián)合上文中的步驟S14來理解，業(yè)務(wù)中心將所有的任務(wù)都發(fā)送到了數(shù)據(jù)庫的任務(wù)表中。

步驟S19：當(dāng)任務(wù)驅(qū)動(dòng)引擎故障時(shí)，多個(gè)工作節(jié)點(diǎn)各自執(zhí)行從數(shù)據(jù)庫的任務(wù)表中獲取到的相應(yīng)的所述預(yù)設(shè)類型任務(wù)。

具體地，當(dāng)任務(wù)驅(qū)動(dòng)引擎故障時(shí)，工作節(jié)點(diǎn)中的zookeeper開關(guān)開啟降級模式，工作節(jié)點(diǎn)跳過任務(wù)驅(qū)動(dòng)引擎直接訪問所述數(shù)據(jù)庫的任務(wù)表執(zhí)行預(yù)設(shè)類型任務(wù)。

上述實(shí)施方式中，引入降級模式為流程的穩(wěn)定運(yùn)行提供了雙重保證，也增加了方法的可靠性和健壯性。

圖2是根據(jù)本發(fā)明實(shí)施例的執(zhí)行任務(wù)的系統(tǒng)的主要部件的示意圖。如圖2所示，該執(zhí)行任務(wù)的系統(tǒng)20包括：業(yè)務(wù)中心21、任務(wù)驅(qū)動(dòng)引擎22、數(shù)據(jù)庫23以及多個(gè)工作節(jié)點(diǎn)24。

業(yè)務(wù)中心21用于創(chuàng)建多個(gè)任務(wù)，任務(wù)分為預(yù)設(shè)類型任務(wù)和其他類型任務(wù)。業(yè)務(wù)中心21還用于將所有預(yù)設(shè)類型任務(wù)發(fā)送到任務(wù)驅(qū)動(dòng)引擎22中，以及用于將所有其他類型任務(wù)發(fā)送到數(shù)據(jù)庫23的任務(wù)表中。

任務(wù)驅(qū)動(dòng)引擎22為多線程并發(fā)任務(wù)調(diào)度框架。例如：任務(wù)驅(qū)動(dòng)引擎為基于Redis和MongoDB實(shí)現(xiàn)的多線程并發(fā)任務(wù)調(diào)度框架。該設(shè)置的任務(wù)驅(qū)動(dòng)引擎具有技術(shù)成熟，簡單易行，通用性強(qiáng)等優(yōu)點(diǎn)。

多個(gè)工作節(jié)點(diǎn)24用于各自執(zhí)行從任務(wù)驅(qū)動(dòng)引擎中獲取到的預(yù)設(shè)類型任務(wù)，以及用于各自執(zhí)行從數(shù)據(jù)庫的任務(wù)表中獲取到的其他類型任務(wù)。

由上可知，本發(fā)明實(shí)施例的處理任務(wù)系統(tǒng)通過集成任務(wù)驅(qū)動(dòng)引擎實(shí)現(xiàn)隊(duì)列任務(wù)，第一方面，將分布式高并發(fā)的預(yù)設(shè)類型任務(wù)從數(shù)據(jù)庫中剝離出來，緩解數(shù)據(jù)庫壓力的同時(shí)也提高了系統(tǒng)性能；第二方面，通過引入任務(wù)驅(qū)動(dòng)引擎任務(wù)可以使預(yù)設(shè)類型任務(wù)嚴(yán)格按照隊(duì)列執(zhí)行，避免并發(fā)任務(wù)帶來的故障，解決了單點(diǎn)問題。因此，本發(fā)明實(shí)施例的處理任務(wù)系統(tǒng)具有處理效率高，簡便易行，穩(wěn)定健壯等優(yōu)點(diǎn)。

在本發(fā)明的實(shí)施方式中，工作節(jié)點(diǎn)24還可用于：當(dāng)工作節(jié)點(diǎn)24執(zhí)行從任務(wù)驅(qū)動(dòng)引擎22中獲取到的相應(yīng)的預(yù)設(shè)類型任務(wù)失敗時(shí)，重新從任務(wù)驅(qū)動(dòng)引擎22中獲取相應(yīng)的預(yù)設(shè)類型任務(wù)并執(zhí)行。任務(wù)驅(qū)動(dòng)引擎22還可用于：當(dāng)工作節(jié)點(diǎn)執(zhí)行從任務(wù)驅(qū)動(dòng)引擎22中獲取到的相應(yīng)的預(yù)設(shè)類型任務(wù)失敗時(shí)，將累計(jì)失敗次數(shù)加1，然后判斷累計(jì)失敗次數(shù)是否超過閥值，若累計(jì)失敗次數(shù)超過閾值，則將累計(jì)失敗次數(shù)清零，將執(zhí)行失敗的預(yù)設(shè)類型任務(wù)從任務(wù)隊(duì)列中消費(fèi)，重新將一個(gè)相同的預(yù)設(shè)類型任務(wù)請求插入任務(wù)隊(duì)列的隊(duì)尾。該實(shí)施方式中，當(dāng)一個(gè)任務(wù)執(zhí)行失敗次數(shù)超過閾值時(shí)，通過立即取消當(dāng)前任務(wù)并且重新向任務(wù)驅(qū)動(dòng)引擎推送一個(gè)相同任務(wù)，這樣就能夠保證工作節(jié)點(diǎn)幾乎不間斷地嘗試執(zhí)行任務(wù)，直到任務(wù)成功執(zhí)行為止，維護(hù)了流程的正常運(yùn)行。

在本發(fā)明的實(shí)施方式中，工作節(jié)點(diǎn)可以基于zookeeper實(shí)現(xiàn)，集成curator框架，這樣可以實(shí)現(xiàn)統(tǒng)一的分布式節(jié)點(diǎn)配置管理?；赯ookeeper的監(jiān)聽機(jī)制可以很容易的擴(kuò)展業(yè)務(wù)，只需實(shí)現(xiàn)監(jiān)聽接口，當(dāng)一個(gè)節(jié)點(diǎn)變化時(shí)，就能保證其它節(jié)點(diǎn)同步變化。分布式配置可以保證分布式節(jié)點(diǎn)的同步變化，分組的實(shí)現(xiàn)使得系統(tǒng)的水平擴(kuò)展更加容易，不僅降低了部署成本和維護(hù)成本，而且也降低了出錯(cuò)率。

在本發(fā)明的實(shí)施方式中，業(yè)務(wù)中心21還可用于將所有預(yù)設(shè)類型任務(wù)發(fā)送到數(shù)據(jù)庫23的任務(wù)表中；以及多個(gè)工作節(jié)點(diǎn)24還可用于當(dāng)任務(wù)驅(qū)動(dòng)引擎22故障時(shí)，各自執(zhí)行從數(shù)據(jù)庫23的任務(wù)表中獲取到的相應(yīng)的預(yù)設(shè)類型任務(wù)。該實(shí)施方式中，引入降級模式為流程的穩(wěn)定運(yùn)行提供了雙重保證，也增加了方法的可靠性和健壯性。

上述具體實(shí)施方式，并不構(gòu)成對本發(fā)明保護(hù)范圍的限制。本領(lǐng)域技術(shù)人員應(yīng)該明白的是，取決于設(shè)計(jì)要求和其他因素，可以發(fā)生各種各樣的修改、組合、子組合和替代。任何在本發(fā)明的精神和原則之內(nèi)所作的修改、等同替換和改進(jìn)等，均應(yīng)包含在本發(fā)明保護(hù)范圍之內(nèi)。