數據處理方法及裝置制造方法
【專利摘要】本發(fā)明公開了一種數據處理方法及裝置，屬于計算機【技術領域】。所述方法包括：將數據處理過程中各應用程序接口的調用操作按調用的順序綁定；當所述應用程序接口的調用操作用于修改數據時，在調用所述應用程序接口之前，復制所述數據作為影子數據；當調用所述應用程序接口修改數據后提交失敗時，從所述用于修改數據的所述應用程序接口的調用操作的前一個最近鄰調用開始，按照所述綁定順序的反方向，根據所述影子數據對已調用的各所述應用程序接口的調用進行回滾操作。本發(fā)明通過采用上述方案，當調用應用程序接口修改數據后提交失敗時，均可以根據影子數據進行回滾操作，以將修改的數據進行還原，從而能夠有效地提高數據處理的效率。
【專利說明】數據處理方法及裝置

【技術領域】
[0001] 本發(fā)明涉及計算機【技術領域】，特別涉及一種數據處理方法及裝置。

【背景技術】
[0002] 隨著計算機軟件的迅猛發(fā)展，各種軟件的應用使用越來越普及。在應用中，可以通 過各種應用程序接口（Application Programming Interface ;API)進行數據的增加 ,刪除、 修改和查詢等操作。
[0003] 例如，以游戲中購買道具為例詳細介紹各種API進行數據處理的操作流程。第一 種購買道具的方式具體為：當應用（Application ；App)接收到API接收的購買道具請求之 后，App先通過調用讀取道具API，讀取道具的數量，再調用發(fā)放道具API向購買用戶發(fā)放道 具，該操作修改了道具的值，即使用戶擁有的道具值為在原來讀取的道具的數量上加上本 次新發(fā)放的道具值；修改完后提交（commit)數據。Commit成功之后，再通過調用讀取金幣 API，讀出金幣值，再調用扣除金幣API扣除本購買道具需要的金幣，該操作修改了金幣值， 即使用戶的金幣值為用戶原來的金幣減去本次所付的金幣，修改完后commit數據。調用發(fā) 放道具API和調用扣除金幣API的操作處理互相獨立，當調用發(fā)放道具API發(fā)送道具成功， 調用扣除金幣API扣除金幣失敗，用戶可以利用該漏洞瘋狂購買道具，而不用支付金幣。第 二種購買道具的方式具體為：當App通過調用API接收到購買道具請求之后，App先調用 讀取金幣API，讀出金幣值，再調用扣除金幣API扣除本購買道具需要的金幣，該操作修改 了金幣值，即使用戶的金幣值為用戶原來的金幣減去本次所付的金幣，修改完后commit數 據。Commit成功之后，先通過讀取道具API，讀取道具的數量，再通過調用發(fā)放道具API向 購買用戶發(fā)放道具，該操作修改了道具的值，即使用戶擁有的道具值為在原來讀取的道具 的數量上加上本次新發(fā)放的道具值；修改完后commit數據。當調用扣除金幣API扣除金幣 成功，調用發(fā)放道具API發(fā)送道具失敗，會遭到用戶的投訴。其中的用戶采用用戶的賬戶來 標識，即所述用戶具體指的是用戶賬戶。
[0004] 在實現本發(fā)明的過程中，發(fā)明人發(fā)現現有技術至少存在以下問題：
[0005] 當現有技術中的數據處理中包括多種調用API的處理時，各種API的調用互相獨 立，其處理結果無法同步，導致了一旦某個API寫數據失敗，其他API無法獲知該處理結果， 而繼續(xù)進行數據處理操作，會造成數據處理錯誤，從而導致該數據處理的效率較低。


【發(fā)明內容】

[0006] 為了解決現有技術的問題，本發(fā)明實施例提供了一種數據處理方法及裝置。所述 技術方案如下：
[0007] -方面，提供了一種數據處理方法，所述方法包括：
[0008] 將數據處理過程中各應用程序接口的調用操作按調用的順序綁定；
[0009] 當所述應用程序接口的調用操作用于修改數據時，在調用所述應用程序接口之 前，復制所述數據作為影子數據；當調用所述應用程序接口修改數據后提交失敗時，從所述 用于修改數據的所述應用程序接口的調用操作的前一個最近鄰調用開始，按照所述綁定順 序的反方向，根據所述影子數據對已調用的各所述應用程序接口的調用進行回滾操作。
[0010] 可選地，如上所述的數據處理方法中，還包括：
[0011] 當調用所述應用程序接口修改數據后提交成功時，繼續(xù)按照所述綁定的順序，對 剩余的各所述應用程序接口的調用操作按照順序調用。
[0012] 可選地，如上所述的數據處理方法中，所述應用程序接口的調用操作包括所述修 改數據的操作，寫入數據的操作或者讀取數據的操作。
[0013] 可選地，如上所述的數據處理方法中，當所述應用程序接口的調用操作用于修改 數據時，在調用所述應用程序接口之前，復制所述數據作為影子數據之前，還包括：
[0014] 調用查詢所述數據的應用程序接口，獲取到所述數據。
[0015] 可選地，如上所述的數據處理方法中，調用查詢所述數據的應用程序接口，獲取到 所述數據之后，調用所述應用程序接口修改數據之前，所述方法還包括：
[0016] 將獲取到的所述數據進行解碼。
[0017] 可選地，如上所述的數據處理方法中，當調用所述應用程序接口修改所述數據后 之后，提交所述修改后的數據之前，還包括：
[0018] 對所述修改后的數據進行編碼。
[0019] 另一方面，提供了一種數據處理裝置，所述裝置包括：
[0020] 綁定模塊，用于將數據處理過程中各應用程序接口的調用操作按調用的順序綁 定;
[0021] 復制模塊，用于當所述應用程序接口的調用操作用于修改數據時，在調用所述應 用程序接口之前，復制所述數據作為影子數據；
[0022] 回滾模塊，用于當調用所述應用程序接口修改數據后提交失敗時，從所述用于修 改數據的所述應用程序接口的調用操作的前一個最近鄰調用開始，按照所述綁定順序的反 方向，根據所述影子數據對已調用的各所述應用程序接口的調用進行回滾操作。
[0023] 可選地，如上所述的數據處理裝置中，還包括：
[0024] 調用模塊，用于調用所述應用程序接口修改數據；
[0025] 所述調用模塊，還當調用所述應用程序接口修改數據后提交成功時，繼續(xù)按照所 述綁定的順序，對剩余的各所述應用程序接口的調用操作按照順序調用。
[0026] 可選地，如上所述的數據處理裝置中，所述應用程序接口的調用操作包括所述修 改數據的操作，寫入數據的操作或者讀取數據的操作。
[0027] 可選地，如上所述的數據處理裝置中，還包括：
[0028] 查詢模塊，用于當所述應用程序接口的調用操作用于修改數據時，在調用所述應 用程序接口之前，復制所述數據作為影子數據之前，調用查詢所述數據的應用程序接口，獲 取到所述數據。
[0029] 可選地，如上所述的數據處理裝置中，還包括：
[0030] 解碼模塊，用于在所述查詢模塊調用查詢所述數據的應用程序接口，獲取到所述 數據之后，調用所述應用程序接口修改數據之前，將獲取到的所述數據進行解碼。
[0031] 可選地，如上所述的數據處理裝置中，還包括：
[0032] 編碼模塊，用于當調用所述應用程序接口修改所述數據后之后，提交所述修改后 的數據之前，對所述修改后的數據進行編碼。
[0033] 本發(fā)明實施例提供的技術方案帶來的有益效果是：
[0034] 通過將數據處理過程中各應用程序接口的調用操作按調用的順序綁定；當應用程 序接口的調用操作用于修改數據時，在調用應用程序接口之前，復制數據作為影子數據；當 調用應用程序接口修改數據后提交失敗時，從用于修改數據的應用程序接口的調用操作的 前一個最近鄰調用開始，按照綁定順序的反方向，根據影子數據對已調用的各應用程序接 口的調用進行回滾操作。本發(fā)明實施例的技術方案，由于將數據處理過程中各應用程序接 口的調用操作按調用的順序綁定，當調用應用程序接口修改數據后提交失敗時，均可以根 據影子數據進行回滾操作，以將修改的數據進行還原，克服了現有技術中部分寫數據失敗 的缺陷，從而能夠有效地提高數據處理的效率。

【專利附圖】

【附圖說明】
[0035] 為了更清楚地說明本發(fā)明實施例中的技術方案，下面將對實施例描述中所需要使 用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本發(fā)明的一些實施例，對于 本領域普通技術人員來講，在不付出創(chuàng)造性勞動的前提下，還可以根據這些附圖獲得其他 的附圖。
[0036] 圖1為本發(fā)明實施例提供的數據處理方法的流程圖。
[0037] 圖2為本發(fā)明實施例提供的數據處理方法的流程圖；
[0038] 圖3為本發(fā)明實施例提供的一種關于事務操作的數據處理流程示意圖；
[0039] 圖4為本發(fā)明實施例提供的數據處理裝置的結構示意圖；
[0040] 圖5為本發(fā)明實施例提供的數據處理裝置。

【具體實施方式】
[0041] 為使本發(fā)明的目的、技術方案和優(yōu)點更加清楚，下面將結合附圖對本發(fā)明實施方 式作進一步地詳細描述。
[0042] 圖1為本發(fā)明實施例提供的數據處理方法的流程圖。如圖1所示，本實施例的數 據處理方法，具體可以包括如下步驟：
[0043] 100、將數據處理過程中各API的調用操作按調用的順序綁定；
[0044] 101、當API的調用操作用于修改數據時，在調用該API之前，復制數據作為影子數 據；
[0045] 具體指的是，按照綁定順序，依次調用數據處理過程中的各API的調用操作時，先 判斷即將要調用的API的調用操作是否為修改數據的操作，若為修改數據時，在調用該API 之前，復制數據作為影子數據。
[0046] 102、當調用該API修改數據后提交失敗時，從用于修改數據的該API的調用操作 的前一個最近鄰調用開始，按照綁定順序的反方向，根據影子數據對已調用的各API的調 用進行回滾操作。
[0047] 每一次調用API修改數據之后，都要進行commit數據，當commit成功，
[0048] 才表示本次調用API修改數據成功，否則，若本次commit失敗，表示本次修改數據 不成功。因此本實施例中，在修改數據不成功時，用于修改數據的該API的調用操作的前一 個最近鄰調用開始，按照綁定順序的反方向，根據該影子數據對已調用的各API的調用進 行回滾操作，從而將本次數據處理流程中所有修改后的數據還原。因此根據影子數據對已 調用的各API的調用進行回滾操作，主要也是對涉及到修改數據的調用API操作進行回滾， 以使得修改后的數據還原。
[0049] 例如以購買道具的過程描述本發(fā)明的技術方案，若按照先發(fā)放道具，后扣除金幣 的流程來實施，首先將讀取道具API，發(fā)放道具API和讀取金幣API和扣除金幣API綁定起 來。調用API的具體過程為：首先調用讀取道具API讀出道具值，接著調用發(fā)放道具AP，因 為發(fā)放道具API為修改數據的操作，因此在調用發(fā)放道具API之前，需要復制讀取的道具值 作為到道具值的影子數據。然后調用發(fā)放道具API，向用戶發(fā)放道具。該操作用于修改道具 的值，即使用戶擁有的道具值為在原來讀取的道具的數量上加上本次新發(fā)放的道具值；修 改完后commit數據。其中的commit的過程主要是一個保存修改后的數據的過程,當commit 成功，便成功向用戶發(fā)放道具。然后先調用讀取金幣API讀取金幣的數值，接著準備調用扣 除金幣API。由于扣除金幣API為修改數據的操作，在調用扣除金幣API之前，復制讀取的 金幣的數值。然后調用扣除金幣API,扣除用戶的金幣數。該扣除金幣API的操作用于修改 金幣的值，即使用戶擁有的金幣數量在原來讀取的金幣的數量的基礎上減去本次應付的金 幣數量；修改完后commit數據，當commit成功,便成功向扣除金幣。本實施例中需要說明 的是，當本次commit失敗，本發(fā)明實施例中由于將數據處理流程中的各API進行綁定，因此 本發(fā)明實施例中，可以根據影子數據對已調用的各API的調用進行回滾操作。由于讀取的 回滾操作不影響數據的修改，該回滾操作主要是針對于涉及到修改數據的調用API操作， 例如該方案中，對上次發(fā)放道具API調用進行回滾操作，收回發(fā)放給用戶的道具，從而得以 將修改的數據進行還原，克服了現有技術中部門寫數據失敗的缺陷，從而能夠有效地提高 數據處理的效率。
[0050] 本實施例的技術方案對于購買道具的過程若先扣除金幣，再發(fā)放道具的方案同樣 可以適用，其實施過程同上述過程類似，在此不再贅述。
[0051] 本實施例的數據處理方法的執(zhí)行主體為一數據處理裝置，該數據處理裝置可以采 用軟件集成。
[0052] 本實施例的數據處理方法，通過將數據處理過程中各應用程序接口的調用操作按 調用的順序綁定；當應用程序接口的調用操作用于修改數據時，在調用應用程序接口之前， 復制數據作為影子數據；當調用應用程序接口修改數據后提交失敗時，從用于修改數據的 應用程序接口的調用操作的前一個最近鄰調用開始，按照綁定順序的反方向，根據影子數 據對已調用的各應用程序接口的調用進行回滾操作。本實施例的技術方案，由于將數據處 理過程中各應用程序接口的調用操作按調用的順序綁定，當調用應用程序接口修改數據后 提交失敗時，均可以根據影子數據進行回滾操作，以將修改的數據進行還原，克服了現有技 術中部門寫數據失敗的缺陷，從而能夠有效地提高數據處理的效率。
[0053] 可選地，在上述圖1所示實施例的技術方案的基礎上，上述實施例的數據處理方 法還包括：當調用API修改數據后提交成功時，繼續(xù)按照綁定的順序，對剩余的各API的調 用操作按照順序調用。
[0054] 需要說明的是，上述圖1所示實施例的技術方案中的API的調用操作包括修改數 據的操作，寫入數據的操作或者讀取數據的操作。
[0055] 可選地，在上述圖1所示實施例的技術方案的基礎上，在步驟101 "當API的調用 操作用于修改數據時，在調用API之前，復制數據作為影子數據"之前，還包括：調用查詢 (query)數據的API，獲取到該查詢的數據。例如具體可以從后端數據庫中讀取該要查詢的 數據。
[0056] 進一步可選地，在調用查詢數據的API，獲取到數據之后，調用API修改數據之前， 還可以包括將獲取到的數據進行解碼。例如具體可以將后端數據庫中存儲的二進制數據解 碼為可以供識別和修改的數據。例如具體可以采用騰訊公司移動互聯(lián)網事業(yè)群開發(fā)的一套 類似于protocol buffer的數據交換格式jce,可以稱為jce交換格式。
[0057] 進一步可選地，同理，在上述實施例中"當調用API修改數據后"之后，"提交修改 后的數據"之前，還可以包括：對修改后的數據進行編碼。該過程為上述編碼的逆過程，同 理采用jce交換格式進行編碼，為上述實施例中的jce交換格式的解碼的逆過程。
[0058] 上述實施例的數據處理方法中，所有可選技術方案可以采用可以結合的方式任意 組合形成本發(fā)明的可選實施例，在此不再贅述。
[0059] 上述實施例的數據處理方法中，由于將數據處理過程中各應用程序接口的調用操 作按調用的順序綁定，當調用應用程序接口修改數據后提交失敗時，均可以根據影子數據 進行回滾操作，以將修改的數據進行還原，克服了現有技術中部門寫數據失敗的缺陷，從而 能夠有效地提高數據處理的效率。
[0060] 圖2為本發(fā)明實施例提供的數據處理方法的流程圖。如圖2所示，本實施例的數 據處理方法，在上述圖1及上述可選實施例的基礎上，進一步更加詳細地介紹本發(fā)明的技 術方案。如圖2所示，本實施例的數據處理方法，具體可以包括如下步驟：
[0061] 200、將數據處理過程中3個API的調用操作按調用的順序綁定；
[0062] 例如數據處理過程中的各API操作包括寫數據的API操作、修改數據的API操作 和讀取數據的API操作中的一個或者多個。本實施例中以一個包括3各API調用的數據處 理過程為例來介紹本發(fā)明的技術方案。例如本實施例中的3個API調用操作按照調用順序 依次為讀取數據的API、修改數據的API和寫入數據的API。
[0063] 201、調用讀取數據的API，獲取讀取的數據；
[0064] 202、復制讀取后的數據，作為影子數據；
[0065] 203、對讀取的數據進行jce解碼；
[0066] 204、調用修改數據的API，進行數據修改；
[0067] 205、將修改后的數據進行jce編碼；
[0068] 206、commit編碼后的數據；
[0069] 207、判斷commit是否成功，當commit成功時，執(zhí)行步驟208,否則結束；
[0070] 此處需要注意的是，此處commit失敗，按照本發(fā)明實施例應該執(zhí)行回滾操作的， 但是由于commit失敗，當前的該修改數據的API調用不會滾，該修改數據的API調用的前 一個最近鄰調用為讀取API的調用，未涉及到修改數據，因此不用回滾。
[0071] 208、調用寫數據的API，寫入新數據；執(zhí)行步驟209 ；
[0072] 209、將寫入的新數據進行jce編碼；執(zhí)行步驟210 ；
[0073] 210、commit編碼后的新數據；執(zhí)行步驟211 ；
[0074] 211、判斷commit是否成功，當commit成功時結束,否則執(zhí)行步驟212 ；
[0075] 該步驟中，當commit成功表示數據處理流程結束。
[0076] 212、根據影子數據對修改數據的API調用進行回滾操作，使得修改后的數據還 原。
[0077] 同理，本實施例的數據處理方法的執(zhí)行主體也為數據處理裝置，該數據處理裝置 可以采用軟件集成。
[0078] 本實施例的數據處理方法，由于將數據處理過程中各應用程序接口的調用操作按 調用的順序綁定，當調用應用程序接口修改數據后提交失敗時，均可以根據影子數據進行 回滾操作，以將修改的數據進行還原，克服了現有技術中部門寫數據失敗的缺陷，從而能夠 有效地提高數據處理的效率。
[0079] 下面實施例中抽象出兩類對象來描述本發(fā)明的實現方案。其中兩類對象，一個是 "數據源對象（Data source)",另一個是"事務對象（Transaction)"。
[0080] 其中Transaction，中文叫做事務，是訪問并可能更新數據庫中各種數據項的一個 程序執(zhí)行單元（unit)。事務通常由高級數據庫操縱語言或編程語言(如SQL，C++或Java) 書寫的用戶程序的執(zhí)行所引起，并用形如begin Transaction和commit Transaction或 rollback Transaction語句（或函數調用)來界定。事務由事務開始（begin Transaction) 和事務結束（commit Transaction或rollback Transaction)之間執(zhí)行的全體操作組成。
[0081] Data source,中文叫數據源，是對后端數據接口的封裝，并對外提供Query、 Commit、Delete等接口?？梢詥为毷褂?，更多時候是配合Transaction -起使用。
[0082] Data source實際上就是對普通API的包裝，它本身會抽象出4個接口 ：查詢 (Query)接口，提交（Commit)接口，刪除（Delete)接口，回滾（RollBack)接口。Query 對應 API的"查詢"，Commit對應API的"增加、改動"，Delete對應API的"刪除"。Data source 可以定義任意多個，不同的Data source對應不同類型的API。比如操作"道具"的API可 以被包裝成"道具Data source",起名為：PropDataSource ;操作"金幣"的API可以被包裝 成"金幣Data source"，起名為：MoneyDataSource。由于Delete接口被調用時直接刪除 數據，無法進行回滾，因此本申請技術方案中不涉及Delete接口的使用。
[0083] Transaction驅動一系列Data source的執(zhí)行，它本身會抽象出4個接口 ：查詢 (Query)接 口，提交（Commit)接口，刪除（Delete)接口，這 3 個接 口 跟 Data source 對 應。除此之外，還提供一叫做綁定（Bind)的接口，調用Bind接口可以將Data source跟 Transaction綁定起來。
[0084]例如：
[0085] j sfc ?|?承幸承傘木木?|?承幸承傘 ^^|** ?|?承?|? *承傘木?|?承?|? *承傘^? * ?|?承幸j Transaction Transaction; // 定義事務又十象 PropDataSource propds; //定義道具數據源對象，內部持有道具的jce結構體 MoneyDataSource moneyds; //定義金幣數據源對象，內部持有金幣的jce結構體 y承承承聿承承氺承承承承聿窣承串傘承承凄欠寺居源?βρ定串傘尜承聿窣承串傘承承承聿承承氺承承承承y Transaction.BInd(propds); //鄭定道具數據源對象 Transaction.Bind(moneyds); // 綁定金幣欲據源對象 ,*氺*本氺本氺本串氺*本*本*本串氺*本氺本才丸才亍杏詢才乘本*本串氺*本氺本*本串氺*本**, Transaction.Query(); // Transaction內部依次調用被綁定數據源的Query接口， II獲取到原始的二進制數據后，內部會自動進行jce的解碼， //將二進制數據解碼成jce結構體 ,氺氺氺氺*氺幸氺承氺氺本本數據修改· 扣除金幣、加道具幸氺*氺*氺承氺氺本氺氺/ y串承串本傘氺傘本串本傘**本串承串本 j亍才是交才乘窣傘承承串串串串串傘承傘車串承窣幸傘承承 *ιγ Transaction.CommitQ; // Transaction內部依次調用被綿定數據源的Commit接口 , //數據源的Commit在執(zhí)行之前會先自動將修改后的jce結構體 //編碼成二進制數據。 //如果某個數據源提交失敗，從該失敗的上一個數據源
[0086] II開始進行反向回滾(RollBack),回滾的方向提交的方向相反
[0087] 圖3為本發(fā)明實施例提供的一種關于事務操作的數據處理流程示意圖。如圖3所 示，本實施例的關于事務操作的數據處理流程，包括如下步驟：
[0088] 第一步、將3個數據源數據源1 (Data source 1)、數據源2 (Data source 2)和 數據源3 (Data source 3)依次Bind(綁定）到事務處理（Transaction)對象；
[0089] 第二步、執(zhí)行Query接口進行查詢，查詢完后現將各數據源進行拷貝得到各數據 源的影子數據，然后自動將Query獲取的二進制數據進行jce解碼；
[0090] 第三步、對各個數據源，將查詢后編碼得到的數據進行修改；
[0091] 第四步、對各個數據源，對修改后的數據進行jce編碼；
[0092] 第五步、對各個數據源，對編碼后的數據進行Commit ；
[0093] 例如，可以同時對各個修改后的數據一起打包，一起Commit。
[0094] 第六步、若commit成功，數據處理結束。若commit失敗，以提交順序相反的方向 進行回滾操作。其中需要注意的提交失敗的數據源本身不進行回滾。
[0095] 本實施例中以各個數據源為對象介紹本發(fā)明的實施例，實際應用中，多個數據源 的查詢，修改和提交可以有先后順序，也可以沒有先后順序。但是只要Commit失敗，就必須 以該次修改數據操作前的最近鄰一次操作開始，按照調用的反方向，進行回滾操作。
[0096] 其中查詢時，按照3個數據源的調用順序依次執(zhí)行,如查詢（Query)Data sourcel 之后，先解碼，再修改，修改完后再編碼，編碼后再commit。在commit成功之后，再查詢 (Query) Data source2,然后也是先解碼,再修改，修改完后再編碼，編碼后再commit。在 commit成功之后,再查詢（Query) Data source3,同理,也是先解碼，再修改，修改完后再編 碼，編碼后再commit。
[0097] 其中的執(zhí)行流程包括Query、Commit。Query跟Commit的執(zhí)行方向相同，RollBack 跟它們的方向相反。上述實施例中也可以只進行Query操作，不進行Commit操作。但是 如果有Commit,在之前必須先Query。上述圖3所示的流程示意圖以RollBack隱藏在 Transaction內部，當Commit失敗時調用的，夕卜部無須顯式調用。需要說明的是,Delete操 作是獨立的，不用依賴任何Query、Commit、RollBack操作。
[0098] 上述實施例，由于將3個數據源Data sourcel>Data source2和Data source3依 次Bind(綁定)到Transaction對象，并在Commit失敗時，執(zhí)行RollBack回滾操作，以將修 改的數據進行還原，克服了現有技術中部門寫數據失敗的缺陷，從而能夠有效地提高數據 處理的效率。
[0099] 圖4為本發(fā)明實施例提供的數據處理裝置的結構示意圖。如圖4所示，本實施例 的數據處理裝置，具體可以包括：綁定模塊10、復制模塊11和回滾模塊12。
[0100] 其中綁定模塊10用于將數據處理過程中各API的調用操作按調用的順序綁定；復 制模塊11用于在數據處理過程中，當某API的調用操作用于修改數據時，在調用API之前， 復制數據作為影子數據；回滾模塊12分別與綁定模塊10和復制模塊11連接，回滾操作12 用于當調用API修改數據后提交失敗時，從用于修改數據的API的調用操作的前一個最近 鄰調用開始，按照綁定模塊10綁定的綁定順序的反方向，根據復制模塊12復制得到的影子 數據對已調用的各API的調用進行回滾操作。
[0101] 本實施例的數據處理裝置，通過采用上述模塊實現數據處理的實現機制與上述相 關方法實施例的實現機制相同，詳細可以參考上述相關實施例的記載，在此不再贅述。
[0102] 本實施例的數據處理裝置，通過采用上述模塊實現將數據處理過程中各應用程序 接口的調用操作按調用的順序綁定；當應用程序接口的調用操作用于修改數據時，在調用 應用程序接口之前，復制數據作為影子數據；當調用應用程序接口修改數據后提交失敗時， 從用于修改數據的應用程序接口的調用操作的前一個最近鄰調用開始，按照綁定順序的反 方向，根據影子數據對已調用的各應用程序接口的調用進行回滾操作。本實施例的技術方 案，由于將數據處理過程中各應用程序接口的調用操作按調用的順序綁定，當調用應用程 序接口修改數據后提交失敗時，均可以根據影子數據進行回滾操作，以將修改的數據進行 還原，克服了現有技術中部門寫數據失敗的缺陷，從而能夠有效地提高數據處理的效率。
[0103] 圖5為本發(fā)明實施例提供的數據處理裝置。如圖5所示，本實施例的數據處理裝 置，在上述圖4所示實施例的基礎上，進一步還包括如下技術方案。
[0104] 如圖5所示，本實施例的數據處理裝置還包括調用模塊13。該調用模塊13與綁定 模塊10連接，調用模塊13用于當調用API修改數據后提交成功時，繼續(xù)按照綁定模塊10 綁定的順序，對剩余的各API的調用操作按照順序調用。其中調用模塊13還用于調用API 修改數據。
[0105] 可選地，上述實施例中的API的調用操作包括修改數據的操作，寫入數據的操作 或者讀取數據的操作。
[0106] 可選地，如圖5所示，本實施例的數據處理裝置還包括查詢模塊14。該查詢模塊 14用于當API的調用操作用于修改數據時，在調用API之前，復制模塊12復制數據作為影 子數據之前，調用查詢數據的API，獲取到數據。復制模塊12與查詢模塊14連接，復制模塊 14用于在數據處理過程中，當某API的調用操作用于修改數據時，在調用API之前，復制查 詢模塊14查詢的數據作為影子數據。
[0107] 進一步可選地，如圖5所示，本實施例的數據處理裝置還包括解碼模塊15。其中該 解碼模塊15與查詢模塊14連接，解碼模塊15用于在查詢模塊14調用查詢數據的API，獲 取到數據之后，調用API修改數據之前，將獲取到的數據進行解碼。調用模塊13也與解碼 模塊15連接，調用模塊13還用于調用API修改解碼模塊15解碼后的數據。
[0108] 進一步可選地，如圖5所示，本實施例的數據處理裝置，還包括編碼模塊16。其中 編碼模塊16與調用模塊13連接，編碼模塊16用于當調用模塊13調用API修改數據后之 后，對修改后的數據進行編碼，然后才能提交修改后的數據。
[0109] 本實施例的數據處理裝置中，所有可選技術方案可以采用可以結合的方式任意組 合形成本發(fā)明的可選實施例，在此不再贅述。
[0110] 本實施例的數據處理裝置，通過采用上述模塊實現將數據處理過程中各應用程序 接口的調用操作按調用的順序綁定，當調用應用程序接口修改數據后提交失敗時，均可以 根據影子數據進行回滾操作，以將修改的數據進行還原，克服了現有技術中部門寫數據失 敗的缺陷，從而能夠有效地提高數據處理的效率。
[0111] 需要說明的是：上述實施例提供的數據處理裝置在數據處理時，僅以上述各功能 模塊的劃分進行舉例說明，實際應用中，可以根據需要而將上述功能分配由不同的功能模 塊完成，即將裝置的內部結構劃分成不同的功能模塊，以完成以上描述的全部或者部分功 能。另外，上述實施例提供的數據處理裝置與數據處理方法實施例屬于同一構思，其具體實 現過程詳見方法實施例，這里不再贅述。
[0112] 本領域普通技術人員可以理解實現上述實施例的全部或部分步驟可以通過硬件 來完成，也可以通過程序來指令相關的硬件完成，所述的程序可以存儲于一種計算機可讀 存儲介質中，上述提到的存儲介質可以是只讀存儲器，磁盤或光盤等。
[0113] 以上所述僅為本發(fā)明的較佳實施例，并不用以限制本發(fā)明，凡在本發(fā)明的精神和 原則之內，所作的任何修改、等同替換、改進等，均應包含在本發(fā)明的保護范圍之內。
【權利要求】
1. 一種數據處理方法，其特征在于，所述方法包括： 將數據處理過程中各應用程序接口的調用操作按調用的順序綁定； 當所述應用程序接口的調用操作用于修改數據時，在調用所述應用程序接口之前，復 制所述數據作為影子數據； 當調用所述應用程序接口修改數據后提交失敗時，從所述用于修改數據的所述應用程 序接口的調用操作的前一個最近鄰調用開始，按照所述綁定順序的反方向，根據所述影子 數據對已調用的各所述應用程序接口的調用進行回滾操作。
2.根據權利要求1所述的方法，其特征在于，所述方法還包括： 當調用所述應用程序接口修改數據后提交成功時，繼續(xù)按照所述綁定的順序，對剩余 的各所述應用程序接口的調用操作按照順序調用。
3.根據權利要求1所述的方法，其特征在于，所述應用程序接口的調用操作包括所述 修改數據的操作，寫入數據的操作或者讀取數據的操作。
4.根據權利要求1-3任一所述的方法，其特征在于，當所述應用程序接口的調用操作 用于修改數據時，在調用所述應用程序接口之前，復制所述數據作為影子數據之前，還包 括： 調用查詢所述數據的應用程序接口，獲取到所述數據。
5.根據權利要求4所述的方法，其特征在于，調用查詢所述數據的應用程序接口，獲取 到所述數據之后，調用所述應用程序接口修改數據之前，所述方法還包括： 將獲取到的所述數據進行解碼。
6.根據權利要求5所述的方法，其特征在于，當調用所述應用程序接口修改所述數據 后之后，提交所述修改后的數據之前，所述方法還包括： 對所述修改后的數據進行編碼。
7. 一種數據處理裝置，其特征在于，所述裝置包括： 綁定模塊，用于將數據處理過程中各應用程序接口的調用操作按調用的順序綁定； 復制模塊，用于當所述應用程序接口的調用操作用于修改數據時，在調用所述應用程 序接口之前，復制所述數據作為影子數據； 回滾模塊，用于當調用所述應用程序接口修改數據后提交失敗時，從所述用于修改數 據的所述應用程序接口的調用操作的前一個最近鄰調用開始，按照所述綁定順序的反方 向，根據所述影子數據對已調用的各所述應用程序接口的調用進行回滾操作。
8.根據權利要求7所述的裝置，其特征在于，所述裝置還包括： 調用模塊，用于調用所述應用程序接口修改數據； 所述調用模塊，還用于當調用所述應用程序接口修改數據后提交成功時，繼續(xù)按照所 述綁定的順序，對剩余的各所述應用程序接口的調用操作按照順序調用。
9.根據權利要求7所述的裝置，其特征在于，所述應用程序接口的調用操作包括所述 修改數據的操作，寫入數據的操作或者讀取數據的操作。
10.根據權利要求7-9任一所述的裝置，其特征在于，所述裝置還包括： 查詢模塊，用于當所述應用程序接口的調用操作用于修改數據時，在調用所述應用程 序接口之前，復制所述數據作為影子數據之前，調用查詢所述數據的應用程序接口，獲取到 所述數據。
11.根據權利要求10所述的裝置，其特征在于，所述裝置還包括： 解碼模塊，用于在所述查詢模塊調用查詢所述數據的應用程序接口，獲取到所述數據 之后，調用所述應用程序接口修改數據之前，將獲取到的所述數據進行解碼。
12.根據權利要求11所述的裝置，其特征在于，所述裝置還包括： 編碼模塊，用于當調用所述應用程序接口修改所述數據后之后，提交所述修改后的數 據之前，對所述修改后的數據進行編碼。
【文檔編號】G06F9/44GK104142818SQ201310172484
【公開日】2014年11月12日 申請日期:2013年5月10日 優(yōu)先權日:2013年5月10日
【發(fā)明者】周齡 申請人:騰訊科技（深圳）有限公司