本發(fā)明涉及計算機技術(shù)領域，尤其涉及數(shù)據(jù)同步領域，具體涉及一種數(shù)據(jù)同步方法以及裝置。

背景技術(shù)：

隨著信息化水平的提高以及人們對于風險認識的提高，現(xiàn)代金融企業(yè)逐步加強了利用信息化手段對風險進行計量的應用，特別隨著巴塞爾協(xié)議III的推廣，有條件的金融企業(yè)逐步替換為使用高級法對金融業(yè)務活動的風險進行計量，而由于高級法計量的復雜性，需要大量的基礎性數(shù)據(jù)作為計量的基礎，而大量的基礎性數(shù)據(jù)又分散在各種不同的專業(yè)系統(tǒng)內(nèi)，需要通過技術(shù)手段將分散在各個系統(tǒng)的數(shù)據(jù)進行集中。傳統(tǒng)的數(shù)據(jù)同步手段主要通過聯(lián)機接口同步以及晚間批量同步方式，前者通常由源端在交易完成后通過HTTP協(xié)議將數(shù)據(jù)實時傳輸?shù)侥繕硕?，后者通常由源端在晚間通過觸發(fā)器或時間戳方式批量篩選生成增量數(shù)據(jù)文本，點對點方式傳輸至目標端，目標端在計劃時點導入增量文本。但這兩種同步又各存在一些缺陷：

1、聯(lián)機同步：數(shù)據(jù)同步時效性強，但適宜小數(shù)據(jù)量的同步，當同步數(shù)據(jù)量大且分散時，一方面，資源可復用度不高，同時造成系統(tǒng)復雜度大幅上升而且對系統(tǒng)的性能帶來較大的壓力，影響系統(tǒng)正常提供服務。

2、批量同步：數(shù)據(jù)同步時效性較差，需要利用晚間空閑時間傳遞數(shù)據(jù)，但對大數(shù)據(jù)量的同步支持較好，且可以降低同一業(yè)務分散存儲在不同關聯(lián)表時數(shù)據(jù)同步的耦合性。同時當源端傳輸時點較晚時，可能錯過目標端加載時點，影響目標端數(shù)據(jù)準確性、完整性。

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

為了解決在將分散在各個系統(tǒng)的數(shù)據(jù)進行集中的過程中，現(xiàn)有技術(shù)的數(shù)據(jù)同步時效性較差或同步數(shù)據(jù)量不足的問題，本發(fā)明提出了一種數(shù)據(jù)同步方法及裝置。

為了達到上述目的，本發(fā)明實施例提出一種數(shù)據(jù)同步方法，用于實時同步源端和目標端的數(shù)據(jù)，包括：接收用戶輸入的業(yè)務基礎信息；根據(jù)所述業(yè)務基礎信息，獲取所述源端的業(yè)務基礎數(shù)據(jù)；存儲獲取的所述源端的業(yè)務基礎數(shù)據(jù)，并在存儲的業(yè)務基礎數(shù)據(jù)發(fā)生變動后，記錄數(shù)據(jù)庫REDO LOG；解析所述數(shù)據(jù)庫REDO LOG，并根據(jù)解析后的數(shù)據(jù)庫REDO LOG的信息實時更新所述目標端的數(shù)據(jù)。

進一步地，在一實施例中，還包括：接受用戶輸入的查詢請求，并根據(jù)所述查詢請求獲取并展示所述目標端的業(yè)務基礎數(shù)據(jù)。

進一步地，在一實施例中，在其記錄、傳輸以及解析數(shù)據(jù)庫REDO LOG的步驟中，還包括：監(jiān)測所述數(shù)據(jù)庫REDO LOG的生成情況、傳輸數(shù)量及執(zhí)行情況。

進一步地，在一實施例中，在其數(shù)據(jù)庫REDO LOG進行傳輸?shù)牟襟E中，還包括：控制所述數(shù)據(jù)庫REDO LOG的傳輸?shù)拈_啟與關閉。

進一步地，在一實施例中，所述數(shù)據(jù)庫REDO LOG通過TCP/IP協(xié)議傳輸至所述目標端。

為了達到上述目的，相應的提出了一種數(shù)據(jù)同步裝置，用于實時同步源端和目標端的數(shù)據(jù)，包括：業(yè)務基礎信息輸入模塊，用于接收用戶輸入的業(yè)務基礎信息；業(yè)務基礎數(shù)據(jù)獲取模塊，用于根據(jù)所述業(yè)務基礎信息，獲取所述目標端的業(yè)務基礎數(shù)據(jù)；REDO LOG記錄模塊，用于存儲獲取的所述源端的業(yè)務基礎數(shù)據(jù)，并在存儲的業(yè)務基礎數(shù)據(jù)發(fā)生變動后，記錄數(shù)據(jù)庫REDO LOG；REDO LOG解析更新模塊，用于解析所述數(shù)據(jù)庫REDO LOG，并根據(jù)解析后的數(shù)據(jù)庫REDO LOG的信息實時更新所述目標端的數(shù)據(jù)。

進一步地，在一實施例中，還包括：基礎信息查詢模塊，用于接受用戶輸入的查詢請求，并根據(jù)所述查詢請求獲取并展示所述目標端的業(yè)務基礎數(shù)據(jù)。

進一步地，在一實施例中，還包括：REDO LOG監(jiān)測模塊，用于監(jiān)測所述數(shù)據(jù)庫REDO LOG的生成情況、傳輸數(shù)量及執(zhí)行情況。

進一步地，在一實施例中，還包括：REDO LOG傳輸控制模塊，用于控制所述數(shù)據(jù)庫REDO LOG的傳輸?shù)拈_啟與關閉。

本發(fā)明的有益效果在于，本發(fā)明通過利用數(shù)據(jù)庫軟件的系統(tǒng)級日志REDO LOG以及基于TCP/IP傳輸協(xié)議，實現(xiàn)多系統(tǒng)間大量數(shù)據(jù)的精確快速同步，克服了現(xiàn)有同步大量數(shù)據(jù)時效率偏低或資源消耗較大等缺點。首先，本發(fā)明數(shù)據(jù)同步方法對業(yè)務服務器的資源消耗情況依賴較低；其次，當業(yè)務相關數(shù)據(jù)發(fā)生變動后，即可及時進行同步，大幅提高數(shù)據(jù)同步時效性。原先批量同步通過需要T+1日，聯(lián)機同步通常1秒左右，而本發(fā)明的數(shù)據(jù)同步裝置的同步時間約為幾秒，雖然較聯(lián)機同步略差，但遠遠好于批量同步時間，且該同步時效性已可滿足絕大部分業(yè)務場景使用需求；并且，較傳統(tǒng)的聯(lián)機接口模式或批量接口模式，該數(shù)據(jù)同步裝置不僅傳輸時效性高，而且傳輸數(shù)據(jù)量大，應用開發(fā)成本較小。傳統(tǒng)的聯(lián)機接口通常適用于同步以K為單位的數(shù)據(jù)量，而本裝置則基本不受傳輸量大小限制。

附圖說明

為了更清楚地說明本發(fā)明實施例或現(xiàn)有技術(shù)中的技術(shù)方案，下面將對實施例或現(xiàn)有技術(shù)描述中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本發(fā)明的一些實施例，對于本領域技術(shù)人員來講，在不付出創(chuàng)造性勞動性的前提下，還可以根據(jù)這些附圖獲得其他的附圖。

圖1為本發(fā)明實施例的數(shù)據(jù)同步方法的流程圖。

圖2為本發(fā)明實施例的數(shù)據(jù)同步裝置的結(jié)構(gòu)示意圖。

圖3為本發(fā)明另一實施例的數(shù)據(jù)同步裝置的結(jié)構(gòu)示意圖。

圖4為本發(fā)明又一實施例的數(shù)據(jù)同步裝置的結(jié)構(gòu)示意圖。

圖5為本發(fā)明再一實施例的數(shù)據(jù)同步裝置的結(jié)構(gòu)示意圖。

附圖標號：

業(yè)務基礎信息輸入模塊 100

業(yè)務基礎數(shù)據(jù)獲取模塊 200

REDO LOG記錄模塊 300

REDO LOG解析更新模塊 400

源端 500

目標端 600

基礎信息查詢模塊 700

查詢框展示單元 710

結(jié)果展示單元 720

結(jié)果集信息查詢單元 730

REDO LOG監(jiān)測模塊 800

生成監(jiān)測單元 810

發(fā)送監(jiān)測單元 820

接受監(jiān)測單元 830

REDO LOG傳輸控制模塊 900

具體實施方式

下面將結(jié)合本發(fā)明實施例中的附圖，對本發(fā)明實施例中的技術(shù)方案進行清楚、完整地描述，顯然，所描述的實施例僅僅是本發(fā)明一部分實施例，而不是全部的實施例。基于本發(fā)明中的實施例，本領域普通技術(shù)人員在沒有做出創(chuàng)造性勞動前提下所獲得的所有其他實施例，都屬于本發(fā)明保護的范圍。

圖1為本發(fā)明實施例的數(shù)據(jù)同步方法的流程圖。如圖1所示，本發(fā)明實施例的數(shù)據(jù)同步方法，用于實時同步源端和目標端的數(shù)據(jù)，包括：

S100，接收用戶輸入的業(yè)務基礎信息；

S200，根據(jù)所述業(yè)務基礎信息，獲取所述源端的業(yè)務基礎數(shù)據(jù)；

S300，存儲獲取的所述源端的業(yè)務基礎數(shù)據(jù)，并在存儲的業(yè)務基礎數(shù)據(jù)發(fā)生變動后，記錄數(shù)據(jù)庫REDO LOG；

S400，解析所述數(shù)據(jù)庫REDO LOG，并根據(jù)解析后的數(shù)據(jù)庫REDO LOG的信息實時更新所述目標端的數(shù)據(jù)。

在本實施例的S100中，接收用戶輸入的業(yè)務基礎信息，具體實施中，可以通過人機接口實現(xiàn)接收將用戶所需要的業(yè)務基礎信息通過點擊、拖動或鍵入等操作實現(xiàn)輸入，當取得用戶輸入的業(yè)務基礎信息后進入步驟S200。

在本實施例的S200中，根據(jù)所述業(yè)務基礎信息，獲取所述源端的業(yè)務基礎數(shù)據(jù)。在獲取用戶輸入的業(yè)務基礎信息后，根據(jù)業(yè)務基礎信息內(nèi)用戶欲調(diào)取的內(nèi)容，獲取源端的業(yè)務基礎數(shù)據(jù)。在此需要強調(diào)的是，源端的種類與數(shù)量可以是多個，本發(fā)明對此不作限制。獲取用戶所需的源端的業(yè)務基礎數(shù)據(jù)后，進入步驟S300。

在本實施例的S300中，存儲獲取的所述源端的業(yè)務基礎數(shù)據(jù)，并在存儲的業(yè)務基礎數(shù)據(jù)發(fā)生變動后，記錄數(shù)據(jù)庫REDO LOG。獲取源端的業(yè)務基礎數(shù)據(jù)后進行儲存，此時若沒有新的源端業(yè)務基礎數(shù)據(jù)輸入的情況下，該源端業(yè)務基礎數(shù)據(jù)當然未做變化，當出現(xiàn)有新的源端業(yè)務基礎數(shù)據(jù)獲取后，通過比較在先與在后的源端業(yè)務基礎數(shù)據(jù)的差異，并搜集其變動后記錄生成數(shù)據(jù)庫REDO LOG。在此需要說明的是，在后的源端業(yè)務基礎數(shù)據(jù)更新的方式可以為全部覆蓋在先的源端業(yè)務數(shù)據(jù)，也可以是在其基礎上進行更新，本發(fā)明對此不作限定。在生成數(shù)據(jù)庫REDO LOG后，通過TCP/IP協(xié)議將其發(fā)送，并進入下一步。

在本實施例的S400中，解析所述數(shù)據(jù)庫REDO LOG，并根據(jù)解析后的數(shù)據(jù)庫REDO LOG的信息實時更新所述目標端的數(shù)據(jù)。收到所述數(shù)據(jù)庫REDO LOG后，進行解析操作，將其翻譯為數(shù)據(jù)操控語言，然后將該數(shù)據(jù)操控語言在目標端的數(shù)據(jù)存儲裝置中執(zhí)行操作。因為數(shù)據(jù)庫REDO LOG中已經(jīng)所包含的S300中源端業(yè)務基礎數(shù)據(jù)的變動，并且目標端的數(shù)據(jù)在接收到數(shù)據(jù)庫REDO LOG所翻譯后的操作語言后，可以直接對其進行操作，將數(shù)據(jù)的變化進行更新，從而實現(xiàn)數(shù)據(jù)的同步。又因為數(shù)據(jù)庫REDO LOG本身的性質(zhì)，所以其占用的數(shù)據(jù)量不大，但是能反映出源端業(yè)務數(shù)據(jù)的數(shù)據(jù)變化，不僅如此，由于占用數(shù)據(jù)量小的數(shù)據(jù)庫REDO LOG通過TCP/IP協(xié)議發(fā)送與接收，所以可以輕松實現(xiàn)實時傳輸。

在一實施例中，在進行數(shù)據(jù)同步的時候，還可以接收用戶輸入的查詢請求，并根據(jù)所述查詢請求獲取并展示所述目標端的業(yè)務基礎數(shù)據(jù)。通過該步驟，可以為用戶提供查詢服務，將查詢后的結(jié)果集展示給用戶。

在一實施例中，在記錄、傳輸以及解析所述數(shù)據(jù)庫REDO LOG的同時，還可以對所述數(shù)據(jù)庫REDO LOG的生成情況、傳輸數(shù)量及執(zhí)行情況進行監(jiān)控，當出現(xiàn)生成、傳輸或執(zhí)行的過程中，數(shù)據(jù)庫REDO LOG數(shù)量出現(xiàn)丟失或錯誤的時候，或者執(zhí)行的數(shù)據(jù)庫REDO LOG有缺失的時候，對丟失的數(shù)據(jù)庫REDO LOG進行重新發(fā)送或執(zhí)行，并將該問題反映給用戶，以便用戶對其采取相應措施。

在一實施例中，在數(shù)據(jù)庫REDO LOG進行傳輸?shù)牟襟E中，還包括：控制所述數(shù)據(jù)庫REDO LOG的傳輸?shù)拈_啟與關閉。當需要傳輸?shù)臅r候開啟以執(zhí)行后續(xù)步驟，出現(xiàn)意外情況時，可以及時停止后續(xù)的步驟以節(jié)省資源。

在介紹了本發(fā)明實施例的數(shù)據(jù)同步方法之后，接下來，參考圖2對本發(fā)明實施例的數(shù)據(jù)同步裝置進行介紹。該裝置的實施可以參見上述方法的實施，重復之處不再贅述。以下所使用的術(shù)語“模塊”、“單元”，可以是實現(xiàn)預定功能的軟件和/或硬件。

圖2為本發(fā)明實施例的數(shù)據(jù)同步裝置的結(jié)構(gòu)示意圖，如圖2所示，本發(fā)明實施例的數(shù)據(jù)同步裝置，用于實時同步源端500和目標端600的數(shù)據(jù)，包括：業(yè)務基礎信息輸入模塊100，用于接收用戶輸入的業(yè)務基礎信息；業(yè)務基礎數(shù)據(jù)獲取模塊200，用于根據(jù)所述業(yè)務基礎信息，獲取所述源端500的業(yè)務基礎數(shù)據(jù)；REDO LOG記錄模塊300，用于存儲獲取的所述源端500的業(yè)務基礎數(shù)據(jù)，并在存儲的業(yè)務基礎數(shù)據(jù)發(fā)生變動后，記錄數(shù)據(jù)庫REDO LOG；REDO LOG解析更新模塊400，用于解析所述數(shù)據(jù)庫REDO LOG，并根據(jù)解析后的數(shù)據(jù)庫REDO LOG的信息實時更新所述目標端600的數(shù)據(jù)。

在一實施例中，圖3為本發(fā)明另一實施例的數(shù)據(jù)同步裝置的結(jié)構(gòu)示意圖，如圖3所示，還包括：基礎信息查詢模塊700，用于接受用戶輸入的查詢請求，并根據(jù)所述查詢請求獲取并展示所述源端的業(yè)務基礎數(shù)據(jù)。該模塊接收用戶輸入，并將用戶所查詢的信息發(fā)送給業(yè)務基礎數(shù)據(jù)獲取模塊200，然后通過其獲取所述源端500的業(yè)務基礎數(shù)據(jù)后，將查詢后的結(jié)果集信息再傳送返回到基礎信息查詢模塊，并展示給用戶。

在具體實施的過程中，基礎信息查詢模塊由查詢框展示單元710、結(jié)果展示單元720以及結(jié)果集信息查詢單元730組成。結(jié)果集信息查詢單元730連接于業(yè)務基礎數(shù)據(jù)獲取模塊200。查詢展示單元710通過接受用戶輸入，將欲查詢信息傳送至結(jié)果集信息查詢單元730，結(jié)果集信息查詢單元730獲取目標端600的業(yè)務基礎數(shù)據(jù)后，將單個或者多個業(yè)務基礎數(shù)據(jù)整合為結(jié)果集信息返回給結(jié)果展示單元720，結(jié)果展示單元720接收結(jié)果集信息并通過翻頁方式異步展示給用戶。

在一實施例中，圖4為本發(fā)明又一實施例的數(shù)據(jù)同步裝置的結(jié)構(gòu)示意圖，如圖4所示，還包括：REDO LOG監(jiān)測模塊800，用于監(jiān)測所述數(shù)據(jù)庫REDO LOG的生成情況、傳輸數(shù)量及執(zhí)行情況。

在具體實施的過程中，REDO LOG監(jiān)測模塊800連接REDO LOG記錄模塊300，用于監(jiān)測REDO LOG的生成情況，當出現(xiàn)生成過程產(chǎn)生錯誤或者信息缺失的情況，將該信息反饋給用戶，提醒用戶針對不同情況采取相應措施。另外，REDO LOG監(jiān)測模塊800還同時連接REDO LOG解析更新模塊400，用以對REDO LOG的數(shù)據(jù)傳輸狀況進行監(jiān)測，當數(shù)據(jù)庫REDO LOG的傳輸過程中出現(xiàn)丟包、誤碼時，將該信息反饋給用戶，提醒用戶針對不同情況采取相應措施。

在一實施例中，圖5為本發(fā)明再一實施例的數(shù)據(jù)同步裝置的結(jié)構(gòu)示意圖，如圖5所示，還包括：REDO LOG傳輸控制模塊900，連接于REDO LOG記錄模塊300和REDO LOG解析更新模塊400，用于控制所述數(shù)據(jù)庫REDO LOG的傳輸過程的開啟與關閉，例如當在多個源端未更新數(shù)據(jù)的情況時，可以控制關閉REDO LOG記錄模塊300和REDO LOG解析更新模塊400之間的傳輸通道，以節(jié)省帶寬資源。此外，REDO LOG傳輸控制模塊900也可以根據(jù)REDO LOG監(jiān)測模塊800所監(jiān)測的具體情況對傳輸通道進行控制。

在此說明的是，雖然上述提及了數(shù)據(jù)同步裝置的若干模塊，但是所屬領域技術(shù)人員應該知道以上模塊并非強制限定的，在實際的實施過程中多個模塊的特征和功能可以在一個模塊中集成實現(xiàn)。

下面就本發(fā)明的數(shù)據(jù)同步裝置如何實現(xiàn)數(shù)據(jù)同步的，做簡單介紹：

業(yè)務基礎信息輸入模塊100接收到用戶輸入的業(yè)務基礎信息，將其傳送至業(yè)務基礎數(shù)據(jù)獲取模塊200，業(yè)務基礎數(shù)據(jù)獲取模塊200根據(jù)用戶輸入的業(yè)務基礎信息，在源端500中調(diào)取與之相應業(yè)務基礎數(shù)據(jù)并將其發(fā)送至REDO LOG記錄模塊300。然后，該裝置存儲獲取的所述源端500的業(yè)務基礎數(shù)據(jù)，并在存儲的業(yè)務基礎數(shù)據(jù)發(fā)生變動后，記錄變動所對應的數(shù)據(jù)庫REDO LOG，并通過TCP/IP協(xié)議發(fā)送至REDO LOG解析更新模塊400，REDO LOG解析更新模塊400會根據(jù)解析后的數(shù)據(jù)庫REDO LOG的信息實時更新所述目標端600的數(shù)據(jù)，從而完成數(shù)據(jù)同步的過程。期間，若出現(xiàn)用戶查詢請求時，基礎信息查詢模塊700會根據(jù)用戶的查詢請求內(nèi)容調(diào)取源端500的信息并進行展示；并且，在整個的數(shù)據(jù)同步過程中，REDO LOG監(jiān)測模塊800會不定期對數(shù)據(jù)庫REDO LOG的生成情況、傳輸數(shù)量及執(zhí)行情況實行監(jiān)測，反映數(shù)據(jù)同步情況，REDO LOG傳輸控制模塊900也會響應用戶的需求控制述數(shù)據(jù)庫REDO LOG的傳輸?shù)拈_啟與關閉。

在此舉例說明，本發(fā)明的數(shù)據(jù)同步裝置基于債項計量應用場景下，如何實現(xiàn)數(shù)據(jù)同步的，具體過程如下：

用戶輸入具體的債項計量的業(yè)務基礎信息，本發(fā)明數(shù)據(jù)同步裝置會將該業(yè)務基礎信息調(diào)取債項計量對應的源端中的相應數(shù)據(jù)，并將該數(shù)據(jù)發(fā)送至REDO LOG記錄模塊，由于存儲該數(shù)據(jù)會相較于之前存儲的數(shù)據(jù)產(chǎn)生變化，針對此變動記錄數(shù)據(jù)庫REDO LOG，并通過TCP/IP協(xié)議將含有該債項計量數(shù)據(jù)的變動信息的數(shù)據(jù)庫REDO LOG發(fā)送至REDO LOG解析更新模塊，將其進行解析，解析后得到數(shù)據(jù)操控語言，然后將該數(shù)據(jù)操控語言應用至債項計量的目標端，從而按照該操控語言對目標端數(shù)據(jù)實現(xiàn)同步。當在進行數(shù)據(jù)同步的時候，用戶還可以通過本發(fā)明的數(shù)據(jù)同步裝置以實現(xiàn)查詢數(shù)據(jù)的目的。首先，用戶輸入的查詢請求，查詢展示單元接收用戶的確認后，將查詢信息通過http請求發(fā)送至結(jié)果集信息查詢單元，然后從目標端查詢債項結(jié)果后，最后返回至信息查詢單元并展示給用戶。

本發(fā)明的數(shù)據(jù)同步裝置根據(jù)所述查詢請求獲取并展示所述源端的債項計量的業(yè)務基礎數(shù)據(jù)。

本發(fā)明的有益效果在于，本發(fā)明通過利用數(shù)據(jù)庫軟件的系統(tǒng)級日志REDO LOG以及基于TCP/IP傳輸協(xié)議，實現(xiàn)多系統(tǒng)間大量數(shù)據(jù)的精確快速同步?？朔爽F(xiàn)有同步大量數(shù)據(jù)時效率偏低或資源消耗較大等缺點。首先，本發(fā)明數(shù)據(jù)同步方法對業(yè)務服務器的資源消耗情況依賴較低；其次，當業(yè)務相關數(shù)據(jù)發(fā)生變動后，即可及時進行同步，大幅提高數(shù)據(jù)同步時效性。原先批量同步通過需要T+1日，聯(lián)機同步通常1秒左右，而本發(fā)明的數(shù)據(jù)同步裝置的同步時間約為幾秒，雖然較聯(lián)機同步略差，但遠遠好于批量同步時間，且該同步時效性已可滿足絕大部分業(yè)務場景使用需求；并且，較傳統(tǒng)的聯(lián)機接口模式或批量接口模式，該數(shù)據(jù)同步裝置不僅傳輸時效性高，而且傳輸數(shù)據(jù)量大，應用開發(fā)成本較小。傳統(tǒng)的聯(lián)機接口通常適用于同步以K為單位的數(shù)據(jù)量，而本裝置則基本不受傳輸量大小限制。

本發(fā)明中應用了具體實施例對本發(fā)明的原理及實施方式進行了闡述，以上實施例的說明只是用于幫助理解本發(fā)明的方法及其核心思想；同時，對于本領域的一般技術(shù)人員，依據(jù)本發(fā)明的思想，在具體實施方式及應用范圍上均會有改變之處，綜上所述，本說明書內(nèi)容不應理解為對本發(fā)明的限制。