一種分布式任務系統及應用該系統的數據處理方法
2023-11-11 11:17:52 1
專利名稱：：一種分布式任務系統及應用該系統的數據處理方法
技術領域：
：本發明涉及分布式任務
技術領域：
，特別涉及一種分布式任務系統及應用該系統的數據處理方法。
背景技術：
：在小型的伺服器系統中，一般抓取數據和數據處理都由一臺伺服器來實現，但隨著數據量的增大，一臺伺服器的效能已經不能滿足系統的要求。於是業界通常將多臺伺服器布置為分布式任務系統來進行相關數據處理，並且，為了避免多臺伺服器處理時會存在重複性的問題，通常採用時間片段鎖。務，被多個伺服器並發處理的情況；為了避免被多個伺服器並發處理，根據任務的處理間隔時長決定時間片段的長度，從而以時間片段的方式來保證只有多臺伺服器中一臺執行操作。例如，設定的時間片段範圍為l分鐘(具體根據任務的處理間隔時長決定)，在這1分鐘內，通過資料庫鎖的方式來保證只能有1臺伺服器來執行定時任務；具體處理方式可以為以一張資料庫表控制並發，這個表很小(數據列少、數據量只有一條記錄)，只需要記錄上1分鐘執行的機器名、機器IP或者MAC地址即可；在進入下l分鐘後，所有的伺服器都來嘗試鎖該筆記錄，由於資料庫鎖的排他性，只會有l臺伺服器取得對該筆記錄的排他鎖，之後更新鎖時間和機器IP或MAC地址；那麼別的伺服器一旦鎖不住則自動退出嘗試並暫停任務；等待下1分鐘再次嘗試取得排他鎖，以此類推。基於上述原理，現有的分布式任務系統及數據處理方案如下將伺服器群即多臺伺服器從邏輯上分為兩層，第一層為數據抓取層，第二層為數據處理層；物理結構上所有的伺服器都可以作為上述邏輯兩層中的口一貝；當定時任務開始時，通過時間片段鎖方式，確保一定時間段內如i分鐘內，只能有一臺伺服器充當數據抓取的角色，由其與資料庫聯繫進行數據抓3取，根據優化的配置將所抓取的數據進行分發，由數據處理層的伺服器執行具體的數據處理。比如某個海量數據處理任務，硬體方面投入了20臺伺服器，組成對該任務的執行伺服器群；以當前時間10:OO整為例，在10:00-10:01之間，只能有一臺伺服器鎖住該任務(可通過資料庫表加鎖的方式實現)，由該伺服器一次性讀取10000條數據；按照10000/20分成500個批次分發給數據處理層的多臺伺服器共同執行，以達到並發處理的目的。現有的分布式任務系統及其數據處理方式至少存在如下的缺點1、在同一時間點只能有一臺伺服器與資料庫進行交互進行業務數據抓取，那麼這臺伺服器就會成為系統的瓶頸所在；即使增加更多的硬體資源如繼續投入伺服器，也無法解決在同一時間點的最大並發處理量，不能夠實現水平擴容；2、對於現有的分布式任務系統，在程序編寫中勢必會根據當前的業務數據量及所有的硬體資源綜合考慮，推導出當前最優的業務數據分配策略；而一旦增加了一臺或多臺伺服器，程序分配算法勢必要從整體業務邏輯上重新設計，以達到理論上的最優，即在增加伺服器時需要修改程序代碼。
發明內容本申請實施例在於提供一種分布式任務系統及應用該系統的數據處理方法，在保證分布式任務系統不會重複處理相同數據的同時，還能夠避免系統瓶頸最大限度的實現多伺服器並發處理，實現水平擴容，並且，在增加伺服器後無需修改程序代碼。本申請實施例提供的一種分布式任務系統，包括子任務拆分層，用於採取時間片段鎖的方式，將待處理的業務數據對應的查詢過濾條件進行拆分，下發所述拆分後的查詢過濾條件；數據裝載層，用於接收所述查詢過濾條件，從資料庫中獲取與所述查詢過濾條件對應的待處理數據，根據數據分配策略下發所述待處理數據；數據處理層，用於對接收到的待處理數據進行業務處理。其中，所述查詢過濾條件根據業務規則確定。其中，所述分布式任務系統中包括若干臺伺服器；所述若干臺伺服器中的一臺或多臺作為所述子任務拆分層、數據裝載層和^t據處理層中的一層或多層。本申請實施例還提供了一種數據處理方法，包括將分布式任務系統中的伺服器從邏輯上分為子任務拆分層、數據裝載層和數據處理層三層；所述方法還包括所述子任務拆分層採取時間片段鎖的方式，將待處理的業務數據對應的查詢過濾條件進行拆分，下發所述拆分後的查詢過濾條件；所述數據裝載層接收所述查詢過濾條件，從資料庫中獲取與所述查詢過濾條件對應的待處理數據，根據數據分配策略下發所述待處理數據；所述數據處理層對接收到的待處理數據進行業務處理。其中，所述查詢過濾條件根據業務規則確定。其中，所述業務規則包括數據創建時間，或者，數據的處理優先級，或者，數據創建時間和數據的處理優先級。其中，所述若干臺伺服器中的一臺或多臺作為所述子任務拆分層、數據裝載層和悽t據處理層中的一層或多層。應用本申請實施例所提供的分布式任務系統及應用該系統的數據處理方法，在保證分布式任務系統不會重複處理相同數據的同時，還能夠避免系統瓶頸最大限度的實現多伺服器並發處理，達到了業務需求與系統性能的最優設計。再有，應用本申請實施例，由於子任務拆分層不與資料庫進行交互，避免了瓶頸問題，可以對伺服器硬體資源的無限水平擴容，無需修改代碼；適用各種大、中型分布式系統。再有，本申請實施例提供的三層邏輯結構中，每層的處理方式由具體業務決定，如不同的任務、不同的數據量級，其查詢過濾條件拆分方式、數據裝載方式以及處理方式都會有不同，開發人員只需針對特定任務，編寫每層的具體業務處理邏輯，經過筒單的配置即可將該任務無縫集成至本申請的分布式任務處理體系中；同時由於本申請不侵入每個任務的具體業務邏輯，具有很好的可擴展性。再有，本申請實施例不僅提高了處理數據的效能，而且具有;f艮強的通用性，所有的分布式任務系統都可以使用此方案進行處理。為了更清楚地說明本申請實施例或現有技術中的技術方案，下面將對實施例或現有技術描述中所需要使用的附圖作筒單地介紹，顯而易見地，下面描述中的附圖僅僅是本申請的一些實施例，對於本領域普通技術人員來講，在不付出創造性勞動性的前提下，還可以才艮據這些附圖獲得其他的附圖。圖1是根據本申請實施例的一種分布式任務系統結構示意圖；圖2是根據本申請實施例的數據處理方法流程圖。具體實施例方式下面將結合本申請實施例中的附圖，對本申請實施例中的技術方案進行清楚、完整地描述，顯然，所描述的實施例僅僅是本申請一部分實施例，而不是全部的實施例。基於本申請中的實施例，本領域普通技術人員在沒有作出創造性勞動前提下所獲得的所有其他實施例，都屬於本申請保護的範圍。參見圖l,其是^f艮據本申請實施例的一種分布式任務系統結構示意圖。本例中，假設分布式任務系統包括10臺伺服器，以下為描述方便對其進行編號，分別為SERVER-1-1、SERVER-1隱2、SERVER-1-3、SERVER-1陽4、SERVER-1匿5、SERVER-2-1、SERVER-2-2、SERVER-2-3、SERVER畫2-4、SERVER-2-5。首先，將分布式任務系統中的若干臺伺服器從邏輯上分為三層子任務拆分層、數據裝載層和數據處理層，以上編號後的伺服器任何一臺都可以為其中一層或多層，也即所述若干臺伺服器中的一臺或多臺可以作為所述子任務拆分層、數據裝載層和數據處理層中的一層或多層。這樣，本申請實施例所提供的分布式任務系統包括子任務拆分層101、數據裝載層102和數據處理層103,其中，子任務拆分層101,為分布式任務的啟動入口，用於採取時間片段鎖的方式，將待處理的業務數據對應的查詢過濾條件進行拆分，下發所述拆分後的查詢過濾條件。該查詢過濾條件根據業務規則確定，其中的業務規則包括但不限於數據創建時間，或者，數據的處理優先級，或者，凝:據創建時間和數據的處理優先級。可以理解，任何待處理的數據，都可以根據一定的業務規則對其進行拆分，也就是分割、細化數據隊列的查詢過濾條件。子任務拆分層101所拆分出的每個查詢過濾條件，是由各個系統的具體業務決定的，本文並不對具體的業務規則做限定。根據數據的創建時間進行拆分是指每個查詢過濾條件只包含一定時間內的數據，比如只包含10:00:00~10:01:00的數據集。根據數據的處理優先級進行拆分是指每個過濾條件中包含了指定處理優先級的數據集。這裡的優先級在銀行系統中可以反映為需要對諸如大客戶的數據優先處理，系統在產生數據時就指定了數據的處理優先級。當然，子任務拆分層101還可以根據數據的創建時間和處理優先級的複合方式拆分出查詢過濾條件。下面以最常見的根據數據的創建時間確定查詢過濾條件為例進行說明。比如某大型系統今日處理了會計帳1000萬筆，需要日終與銀行的流水進行勾兌；以系統當前時間為起點，至前10分鐘內；每隔1分鐘建立一個查詢過濾條件；這裡的時間間隔可以根據需要任意設定，如以IO秒鐘、30秒鐘為時間分割點等等；這樣會產生若干個數據過濾查詢條件。需要說明的是，子任務拆分層101不進行數據裝載和處理工作，只是按照業務規則拆分查詢過濾條件，並將拆分後的查詢過濾條件分發至服務群內。至於如何具體拆分查詢過濾條件是根據業務需要所決定的，本文對此並不做限定。正因為子任務拆分層101僅^t查詢過濾條件的拆分操作，因而其不與悽t據庫聯繫。需要說明的是，子任務拆分層101與現有的數據抓取層同樣釆取基於時間片段鎖的方式防止同一時間內對相同數據的重複處理；不同之處在於子任務拆分層不進行數據的裝載，不與資料庫交互；而是將數據裝載的查詢過濾條件分發至數據裝載層，由數據裝載層進行後續處理。數據裝載層102，用於接收所述查詢過濾條件，從資料庫中獲取與所述查詢過濾條件對應的待處理數據，4艮據數據分配策略下發所述待處理數據。7數據裝載層102接收來自子任務拆分層101下發查詢過濾條件，由於每個查詢過濾條件是相互獨立的，比如10:00:00-10:00:59的查詢過濾條件和10:01:00-10:01:59的查詢過濾條件是相互獨立的，因而其所對應的數據是不重疊的，所以不存在多臺伺服器重複處理相同數據的風險，這樣，處於數據裝載層的各伺服器可以自行進行數據裝載，不存在處理瓶頸。數據裝載層102所採用的分配策略是根據實際需要設定或計算得出的，本實施例對具體的分配策略不做限定。數據處理層103，用於對接收到的待處理數據進行業務處理。數據處理層103是分布式任務系統的真正業務處理部分，不同的業務有其相應的業務處理方式；由於前兩層的防重複處理與並發處理機制的保證，此層可專心處理業務悽t據，本實施例對具體的業務處理方式不^L限定。可見，應用本申請實施例所提供的分布式任務系統，在保證分布式任務系統不會重複處理相同數據的同時，還能夠避免系統瓶頸最大限度的實現多伺服器並發處理，達到了業務需求與系統性能的最優設計。再有，應用本申請實施例所提供的分布式任務系統，由於子任務拆分層不與資料庫進行交互，避免了瓶頸問題，可以對伺服器硬體資源無限水平擴容，無需修改代碼；適用各種大、中型分布式系統。再有，本申請實施例提供的三層邏輯結構中，每層的處理方式由具體業務決定，如不同的任務、不同的數據量級，其查詢過濾條件拆分方式、彩:據裝載方式以及處理方式都會有不同，開發人員只需針對特定任務，編寫每層的具體業務處理邏輯，經過簡單的配置即可將該任務無縫集成至本申請的分布式任務處理體系中；同時由於本申請不侵入每個任務的具體業務邏輯，具有很好的可擴展性。再有，本申請實施例不僅提高了處理數據的效能，而且具有很強的通用性，所有的分布式任務系統都可以使用此方案進行處理。參見圖2，其是才艮據本申請實施例的數據處理方法流程圖。本例中，已將分布式任務系統中的若干臺伺服器從邏輯上分為三層即，子任務拆分層、數據裝載層和數據處理層，上述若干臺伺服器中的一臺或多臺可以作為所述子任務拆分層、數據裝載層和數據處理層中的一層或多層，也就是說，對於一臺物理存在的伺服器，其在邏輯上既可能處於子任務拆分層，也可能處於數據裝載層，還可能處於數據處理層，還可能處於上述三層的多層中。本實施例具體包括以下步驟步驟201，子任務拆分層採取時間片段鎖的方式，將待處理的業務數據對應的查詢過濾條件進行拆分，下發所述拆分後的查詢過濾條件，該查詢過濾條件可以是一個對象。子任務拆分層為分布式任務的啟動入口，其中的查詢過濾條件根據業務規則確定，該業務規則包括但不限於數據創建時間，或者，數據的處理優先級，或者，數據創建時間和數據的處理優先級。可以理解，任何待處理的數據，都可以根據一定的業務規則對其進行拆分，也就是分割、細化數據隊列的查詢過濾條件。子任務拆分層所拆分出的每個查詢過濾條件，是由各個系統的具體業務決定的，本文並不對具體的業務規則做限定。需要說明的是，子任務拆分層不進行數據裝載和處理工作，只是按照業務規則拆分查詢過濾條件，並將拆分後的查詢過濾條件分發至服務群內。至於如何具體拆分查詢過濾條件是根據業務需要所決定的，本文對此並不做限定。正因為子任務拆分層僅做查詢過濾條件的拆分操作，因而其不與資料庫聯繫。需要說明的是，子任務拆分層與現有的數據抓取層同樣採取基於時間片段鎖的方式防止同一時間內對相同數據的重複處理；不同之處在於子任務拆分層不進行數據的裝載，不與資料庫交互；而是將數據裝載的查詢過濾條件分發至數據裝載層，由數據裝載層進行後續處理。步驟202,數據裝載層接收所述查詢過濾條件，從資料庫中獲取與所述查詢過濾條件對應的待處理數據，根據數據分配策略下發所述待處理數據。可以理解，子任務拆分層和數據裝載層之間的交互是通過一個個具體的查詢過濾條件的，簡而言之，當需要使用分布式任務時，開發人員會事先根據業務特徵來設計數據查詢過濾條件，子任務拆分層產生多個所設計的數據查詢過濾條件項，當數據裝載層接收到這樣的條件項時，就能夠形成本次需要查詢的具體結構4匕查詢i吾言(SQL,StructureQueryLanguage)。例如現有一個交易超時提醒用戶的分布式任務，每日零點執行，取得上一日零點至當前時間內的所有超時數據，並進行業務處理；數據量大約有1000萬筆；經過評估，得知數據的分布比較均勻，每分鐘內產生的業務數據在1000筆左右，由此設定的數據查詢過濾條件為每個子任務只裝載l分鐘內的業務數據；此時的數據查詢過濾條件可以是一個java^象，其含有創建時間起點、創建時間終點兩個屬性；自定義兩個屬性的名稱，如minGmtCreate、maxGmtCreate;定義數據裝載層的查詢SQL:select*fromtable—awheregmt—create>andgmt—create'10:00:00，andgmt—create<='10:01:00，;select*fromtable—awheregmt—create〉'10:01:00，andgmt—create，10:02:00，andgmt—create<='10:03:00，;由於每個查詢過濾條件是相互獨立的，比如10:00:00-10:00:59的查詢過濾條件和10:01:00-10:01:59的查詢過濾條件是相互獨立的，因而其所對應的數據是不重疊的，所以不存在多臺伺服器重複處理相同數據的風險，這樣，處於數據裝載層的各伺服器可以自行進行數據裝載，不存在處理瓶頸。上述分配策略是根據實際需要設定或計算得出的，本實施例對具體的分配策略不做限定。步驟203,數據處理層對接收到的待處理數據進行業務處理。10數據處理層103是分布式任務系統的真正業務處理部分，不同的業務有其相應的業務處理方式；由於前兩層的防重複處理與並發處理^L制的保證，此層可專心處理業務數據，本實施例對具體的業務處理方式不做限定。至此，完成了數據的處理。應用本申請實施例所提供的數據處理方法，在保證分布式任務系統不會重複處理相同數據的同時，還能夠避免系統瓶頸最大限度的實現多伺服器並發處理，達到了業務需求與系統性能的最優設計。再有，應用本申請實施例所提供的數據處理方法，由於子任務拆分層不與資料庫進行交互，避免了瓶頸問題，可以對伺服器硬體資源的無限水平擴容，無需修改代碼；適用各種大、中型分布式系統。再有，本申請實施例提供的三層邏輯結構中，每層的處理方式由具體業務決定，如不同的任務、不同的數據量級，其查詢過濾條件拆分方式、數據裝載方式以及處理方式都會有不同，開發人員只需針對特定任務，編寫每層的具體業務處理邏輯，經過簡單的配置即可將該任務無縫集成至本申請的分布式任務處理體系中；同時由於本申請不侵入每個任務的具體業務邏輯，具有很好的可擴展性。再有，本申請實施例不〗義提高了處理tt據的效能，而且具有^f艮強的通用性，所有的分布式任務系統都可以使用此方案進行處理。本領域普通技術人員可以理解實現上述方法實施方式中的全部或部分步驟是可以通過程序來指令相關的硬體來完成，所述的程序可以存儲於計算機可讀取存儲介質中，這裡所稱得的存儲介質，如ROM/RAM、磁碟、光碟等。以上所述僅為本申請的較佳實施例而已，並非用於限定本申請的保護範圍。凡在本申請的精神和原則之內所作的任何修改、等同替換、改進等，均包含在本申請的保護範圍內。權利要求1、一種分布式任務系統，其特徵在於，包括子任務拆分層，用於採取時間片段鎖的方式，將待處理的業務數據對應的查詢過濾條件進行拆分，下發所述拆分後的查詢過濾條件；數據裝載層，用於接收所述查詢過濾條件，從資料庫中獲取與所述查詢過濾條件對應的待處理數據，根據數據分配策略下發所述待處理數據；數據處理層，用於對接收到的待處理數據進行業務處理。2、根據權利要求1所述的分布式任務系統，其特徵在於，所述查詢過濾條件根據業務規則確定。3、根據權利要求1所述的分布式任務系統，其特徵在於，所述分布式任務系統中包括若干臺伺服器；所述若干臺伺服器中的一臺或多臺作為所述子任務拆分層、數據裝載層和數據處理層中的一層或多層。4、一種數據處理方法，其特徵在於，包括將分布式任務系統中的若干臺伺服器從邏輯上分為子任務拆分層、數據裝載層和數據處理層三層；所述方法還包括所述子任務拆分層採取時間片段鎖的方式，將待處理的業務數據對應的查詢過濾條件進行拆分，下發所述拆分後的查詢過濾條件；所述數據裝載層接收所述查詢過濾條件，從資料庫中獲取與所述查詢過濾條件對應的待處理數據，根據數據分配策略下發所述待處理數據；所述數據處理層對接收到的待處理數據進行業務處理。5、根據權利要求4所述方法，其特徵在於，所述查詢過濾條件根據業務步見則確定。6、根據權利要求5所述方法，其特徵在於，所述業務規則包括數據創建時間，或者，數據的處理優先級，或者，數據創建時間和數據的處理優先級。7、根據權利要求4所述方法，其特徵在於，所述若干臺伺服器中的一臺或多臺作為所述子任務拆分層、凝:據裝載層和邀:據處理層中的一層或多層。全文摘要本申請公開了一種分布式任務系統及應用該系統的數據處理方法，所述系統包括子任務拆分層，用於採取時間片段鎖的方式，將待處理的業務數據對應的查詢過濾條件進行拆分，下發所述拆分後的查詢過濾條件；數據裝載層，用於接收所述查詢過濾條件，從資料庫中獲取與所述查詢過濾條件對應的待處理數據，根據數據分配策略下發所述待處理數據；數據處理層，用於對接收到的待處理數據進行業務處理。應用本申請，在保證分布式任務系統不會重複處理相同數據的同時，還能夠避免系統瓶頸最大限度的實現多伺服器並發處理，達到了業務需求與系統性能的最優設計，可以實現硬體資源水平無限擴展。文檔編號G06F17/30GK101464884SQ20081018659公開日2009年6月24日申請日期2008年12月31日優先權日2008年12月31日發明者寄許申請人:阿里巴巴集團控股有限公司