為了使本技術領域的人員更好地理解本說明書中的技術方案，下面將結合本說明書一個或多個實施例中的圖式，對本說明書一個或多個實施例中的技術方案進行清楚、完整地描述，顯然，所描述的實施例僅是說明書的一部分實施例，而不是全部的實施例。基於說明書一個或多個實施例，本發明所屬技術領域中具有通常知識者在沒有做出創造性勞動前提下所獲得的所有其他實施例，都應當屬於本說明書實施例方案保護的範圍。
資料庫發生網路故障或者意外終止，可能會導致部分或者全部服務不可用，業內稱為資料庫failover(容災)。一般資料庫有會主庫和備庫，資料庫failover通常發生在主庫上。當主庫不可用後，拉起備庫需要一定時間，在這段時間內，為了保障業務進行，帳戶資料通常會寫入FO庫(或稱容災庫)。在備庫被拉起或者主庫被修復後，再將容災庫中資料寫入主庫或備庫中。
但利用容災庫來進行帳務資料處理時，因主庫當機瞬間，可能導致主庫和其他即時同步資料庫資料狀態不一致，從而無法準確知曉容災期間主庫中用戶的準確帳務資料，例如用戶的準確餘額，限制了用戶的正常交易，給用戶帶來不好的體驗。同時流程切換過程中還可能會出現部分分散式伺服器狀態不一致，而導致主庫、容災庫存在同時記帳的風險。
相應地，本說明書實施例提供了一種資料庫容災資料處理方法，在帳務容災期間，先利用閘道記帳方式對流入類交易資料進行處理，並將閘道記帳的帳戶打標並列入為閘道黑名單中。同時非同步產生真實黑名單，所述真實黑名單用戶可以為主庫發生容災的瞬間，主庫和其他即時同步資料庫資料狀態不一致而產生的未決帳戶。當確定產生真實黑名單後，則可以先將閘道黑名單與真實黑名單合併獲得總黑名單。然後，將總黑名單中不屬於真實黑名單的用戶帳戶鎖定，並對鎖定用戶帳戶的資料進行合併更新處理，從而獲得鎖定用戶帳戶的完整帳務資料。
利用本說明書實施例的方案，當主機出現當機後，可以將資料處理轉移到容災庫中進行，防止出現主庫、容災庫同時記帳。並採用只允許流入類交易的閘道記帳方式，將閘道記帳用戶進行打標，列入閘道黑名單中。同時，還可以非同步識別未決帳戶，產生真實黑名單；並在真實黑名單確定後，對真實黑名單之外的閘道帳戶進行資料合併更新處理。從而可以實現除真實黑名單之前的其他用戶在容災期間均可以進行正常交易。
圖1是本說明書提供的所述一種容災資料處理方法實施例流程示意圖。雖然本說明書提供了如下述實施例或圖式所示的方法操作步驟或裝置結構，但基於常規或者無需創造性的勞動在所述方法或裝置中可以包括更多或者部分合併後更少的操作步驟或模組單元。在邏輯性上不存在必要因果關係的步驟或結構中，這些步驟的執行順序或裝置的模組結構不限於本說明書實施例或圖式所示的執行順序或模組結構。所述的方法或模組結構的在實際中的裝置、伺服器或終端產品應用時，可以按照實施例或者圖式所示的方法或模組結構來進行循序執行或者並存執行(例如，並行處理器或者多執行緒處理的環境、甚至包括分散式處理、伺服器集群的實施環境)。
具體的一個實施例如圖1所示，本說明書提供的容災資料處理方法的一個實施例中，所述方法可以包括：
S202：當容災資料庫獲取業務請求方發送的第一業務處理請求後，判斷所述第一業務處理請求的類型是否為流入類，獲得第一判斷結果。
在主機容災狀態下，可以停止主機資料記錄，呼叫容災資料庫對業務進行處理。本說明書的一個實施例中，容災資料庫對業務處理過程中，在確定未決帳戶資料之前，可以先進行閘道記帳。其中，所述閘道記帳可以包括只允許流入不允許流出的資料處理狀態。容災資料庫進行閘道記帳時，僅可用來處理流入類交易，而不允許處理流出類交易。
所述流入類交易通常指對於某個用戶帳戶而言，交易的資金流向是指向該用戶帳戶的，通常的表現如用戶帳戶資金增加。例如，可以包括向支付寶餘額中存入資金的交易，如可以包括透過銀行卡等第三方平臺向帳戶A的支付寶餘額中存入資金的交易，也可以包括透過其他帳戶的支付寶餘額向帳戶A的支付寶餘額中存入資金的交易等。相應地，可以將從用戶帳戶流出資金的交易稱為流出類交易，通常的表現如用戶帳戶資金減少。如帳戶A的支付寶餘額中流出資金的交易稱為帳戶A的流出類交易。
所述第一業務處理請求中可以包括業務類型、交易資金等交易資訊、以及用戶資訊(如用戶ID)等。當容災資料庫獲取第一業務處理請求後，可以先獲取業務類型，所述業務類型可以包括流入類交易、流出類交易。然後，可以判斷所述交易類型是否為流入類交易，獲得第一判斷結果。
S204：若第一判斷結果為是，則根據所述第一業務處理請求中的用戶資訊來確定對應的閘道帳戶，以及根據所述閘道帳戶對所述第一業務處理請求中的交易進行閘道記帳，並將所述用戶資訊對應的用戶打標後列入閘道黑名單。
若第一判斷結果為是，即第一業務處理請求中的業務類型為流入類，則可以對所述第一業務處理請求中的交易進行閘道記帳。為了區別其他狀態下的帳戶，本說明書實施例中可以將閘道記帳狀態下對應的帳戶稱之為閘道帳戶。
在一些實施方式中，可以根據所述第一業務處理請求中的用戶資訊來判斷是否存在對應的閘道帳戶。若根據用戶資訊而判斷存在對應的閘道帳戶，則可以將所述第一業務處理請求中的交易金額記錄到所述用戶資訊對應的閘道帳戶中。
如果不存在對應的閘道帳戶，則可以根據所述用戶資訊來新建一個餘額為零的帳戶，作為所述用戶資訊對應用戶的閘道帳戶。然後，可以獲取所述第一業務處理請求中的交易金額，將交易金額記錄在該新建的閘道帳戶中。並將進行閘道記帳的用戶進行打標，如可以標記為閘道黑名單用戶，列入閘道黑名單列表中。
通常帳戶可以透過用戶資訊來進行標識，如用戶ID等。為了便於資料處理，可以將各個資料庫及各狀態下的帳戶採用相同的標識，如用戶ID。若帳戶A在主機中的帳戶標識為用戶A的ID，則帳戶A在閘道記帳狀態下對應的閘道帳戶標識也為用戶A的ID，以便於各資料庫以及各狀態下記錄的資料讀取、合併及更新等處理。
相應地，可以將進行閘道記帳的用戶對應的用戶ID進行打標，並將用戶ID列入閘道黑名單列表中。
當然，具體實施時，也可以採用其他的方式對帳戶進行標識，這裡不做限定。
若判斷業務類型為流出類，則可以拒絕相應的業務處理請求，如可以返回請求出錯等消息。
S206：確定非同步產生的真實黑名單，將真實黑名單與閘道黑名單進行合併獲得總黑名單。
當主庫發生容災瞬間或者一段時間內，主庫和其他即時同步資料庫資料可能存在狀態不一致，而產生未決帳戶資料，可以將該部分未決帳戶確定為真實黑名單。如，主庫接收到帳戶C的流入類交易資訊，用戶向帳戶C中存入200元，主庫進行相應記帳。但是此時發生主庫容災，其他同步資料庫未來得及進行資料同步，從而導致主庫帳戶C的資料與其他同步資料庫不一致，無法確定帳戶C的準確餘額。
假設流入類交易前，帳戶C的餘額為100元，流入類交易後，帳戶C的餘額應為300元。但同步資料庫未接收到相應資料，同步資料庫帳戶C餘額仍為100元。若帳戶C欲進行流出類交易200元，該資料處理由某同步資料庫進行，則可能導致交易失敗。
在一些實施方式中，利用容災資料庫進行閘道記帳期間，可以同時利用與閘道記帳不同的其它資料處理線路，非同步分析主庫與其他即時同步資料庫的資料，確定未決帳戶，獲得真實黑名單列表。
閘道記帳過程中，因不知哪些帳戶屬於未決帳戶，採用只允許流入類交易而不允許流出類交易的方式，可以防止平臺資金損失，同時還可以確保部分流入類交易的正常進行。
在非同步確定真實黑名單後，可以撈取閘道記帳期間產生的閘道黑名單，然後，將真實黑名單與閘道黑名單進行合併，獲得總黑名單列表。
S208：對總黑名單中不屬於真實黑名單的用戶進行鎖定，對鎖定用戶對應的閘道帳戶資料進行合併更新處理，獲得鎖定用戶對應的容災帳戶。
可以將總黑名單中不屬於真實黑名單的用戶對應的閘道帳戶鎖定。在一些實施方式中，如可以對總黑名單中不屬於真實黑名單的用戶的閘道帳戶進行撈取，並先暫停該部分帳戶的交易處理請求。然後，對鎖定用戶對應的閘道帳戶資料進行合併更新處理，獲得鎖定用戶對應的容災帳戶。相應地，鎖定用戶的容災帳戶中包含了該用戶的完整帳戶資訊。為了便於區分，本說明書實施例中，可以將容災資料庫中完整記帳期間對應的用戶帳戶稱之為容災帳戶。
需特殊說明的是，所述閘道帳戶、容災帳戶均為在容災資料庫中的用戶帳戶，可以透過用戶資訊與其他資料庫中的帳戶資料來進行相互關聯。對於同一個用戶，二者可以是專閘針對不同記帳狀態下所產生的不同帳戶；也可以是同一個帳戶，僅僅是為了便於表述，在不同記帳狀態下定義的名稱不同。具體實施時，可以根據實際需要來進行設定，這裡不做限定。
在一些實施方式中，可以從讀庫和tair(緩存)等同步資料庫中獲取鎖定用戶在主庫當機前的最新資料記錄，並與鎖定用戶的閘道帳戶資料合併，將鎖定用戶對應的閘道帳戶中的資料更新成完整的帳務資料，獲得鎖定用戶對應的容災帳戶。
圖2是本說明書提供的另一種容災資料處理方法實施例流程示意圖。如圖2所示，本說明書的另一個實施例中，所述獲得鎖定用戶對應的容災帳戶之後，還可以包括：
S2102：當容災資料庫獲取業務請求方發送的第二業務處理請求後，根據所述第二業務處理請求中的用戶資訊來判斷相應用戶是否屬於真實黑名單，獲得第三判斷結果；
S2104：第三判斷結果為否時，根據所述第二業務處理請求中的用戶資訊確定相應用戶對應的容災帳戶；
S2106：根據所述相應用戶對應的容災帳戶對所述第二業務處理請求中的交易進行完整記帳。
為了更好地區分表述，本說明書實施例中，可以將確定總黑名單之前的閘道記帳期間獲取的業務處理請求稱之為第一業務處理請求，將確定總黑名單之後的完整記帳期間獲取的業務處理請求稱之為第二業務處理請求。二者只是文字表述的差別，在內容上並沒有特殊的限定。相應地，所述第二業務處理請求中也可以包括業務類型、交易資金等交易資訊、以及用戶資訊(如用戶ID)等。
所述完整記帳可以包括既允許流入也允許流出的資料處理狀態。容災資料庫進行完整記帳時，既允許處理流入類交易，也允許處理流出類交易。
獲得鎖定用戶的完整帳務資料後，當容災資料庫獲取業務請求方發送的第二業務處理請求後，可以根據所述第二業務處理請求中的用戶資訊來判斷相應用戶是否屬於真實黑名單。如果屬於真實黑名單，則可以拒絕進行相應的交易請求。
如果不屬於真實黑名單，則可以根據所述第二業務處理請求中的用戶資訊來確定相應用戶對應的容災帳戶。如果確定存在相應的容災帳戶，則可以根據對應的容災帳戶對業務處理請求中的相應交易進行完整記帳。
經過步驟S208的處理後，鎖定用戶均對應有包含完整帳務資料的容災帳戶，因此，如果該業務處理請求為鎖定帳戶的業務處理請求時，則可以根據用戶資訊來確定相應用戶的容災帳戶，並可以根據該容災帳戶來進行正常的流入類及流出類交易處理。以及可以將相應的交易資料記錄在對應的容災帳戶中。
本說明書實施例中，可以將既不屬於未決帳戶，也未在閘道記帳期間進行交易的用戶稱之為正常用戶。則可以說明正常用戶在主庫的其他即時同步資料中的帳務記錄資料正確且完整。
在一些實施方式中，對於正常用戶，如果沒有在容災資料庫中進行過業務處理，則可以不在容災資料中產生對應的帳戶資訊，以確保後續資料回遷的簡便性。
根據所述第二業務處理請求中的用戶資訊來確定對應的容災帳戶時，如果沒有匹配到相應的容災帳戶，則可以說明該用戶是第一次在容災資料中進行業務處理。則可以在容災資料庫中新建一個餘額為零的容災帳戶，然後，可以根據所述第二業務處理請求中的用戶資訊來調取讀庫及tair(緩存)等資料庫中相應用戶的帳務資料，合併到相應用戶對應的容災帳戶中，將該容災帳戶中的帳務資料更新成完整的帳務資料。則合併更新處理後的容災帳戶中包含了相應用戶的完整帳務資料。然後，可以基於合併更新處理後的容災帳戶對該業務處理請求中的交易進行處理，並記錄在相應的容災帳戶中，實現用戶的完整記帳。
如果在容災資料庫中再次接收到關於該用戶的業務處理請求時，則可以根據用戶資訊來確定相應的容災帳戶，並根據該用戶對應的容災帳戶而對業務處理請求中的相應交易進行完整記帳。
相應地，本說明書的一個實施例中，所述根據所述第二業務處理請求中的用戶資訊來確定相應用戶對應的容災帳戶，可以包括：
當根據所述第二業務處理請求中的用戶資訊未匹配到對應的容災帳戶時，根據所述第二業務處理請求中的用戶資訊而產生容災帳戶，並對該容災帳戶的資料進行合併更新處理；
相應地，根據合併更新處理後的容災帳戶對所述第二業務處理請求中的交易進行完整記帳。
本說明書上述實施例提供的方案，在主庫故障後，可以暫停主庫的帳務處理，臨時調取容災資料庫而對帳務資料進行處理，防止主庫異常帳務處理帶來較多的未決帳戶。在確定未決帳戶之前，可以先在容災資料庫中利用閘道記帳的方式來進行帳務處理，閘道記帳過程中，採用只允許流入類交易而不允許流出類交易的方式，可以防止平臺資金損失。並對閘道記帳的用戶進行打標，列入閘道黑名單列表中。
在閘道記帳的同時，可以非同步分析主庫故障至容災資料庫啟用時間段內產生的未決帳戶，產生真實黑名單。當真實黑名單產生後，可以將閘道黑名單與真實黑名單合併，獲得總黑名單列表。
確定總黑名單列表後，可以對總黑名單中不屬於真實黑名單的用戶進行帳務資料合併，獲得相應用戶的完整帳務資料。
當再次接收到業務處理請求時，對於鎖定用戶可以利用已包含完整帳務資料的容災帳戶來進行正常帳務處理。對於正常用戶，則可以產生相應的容災帳戶，並從同步資料庫中調取完整帳務資料，利用包含完整帳務資料的容災帳戶來進行正常業務處理。從而實現除真實黑名單之外的用戶的正常帳務處理。
從而，利用上述實施例提供的方案，可以最大程度地確保容災期間資料庫的帳務處理能力。
本說明書的另一個實施例中，可以採用非同步方式撈取總黑名單中不屬於真實黑名單的用戶並進行鎖定，對鎖定用戶得帳戶資料進行合併更新批次處理。
在一些實施方式中，可以先暫停鎖定用戶的交易處理，在對其他用戶進行正常記帳的同時，利用與正常記帳不同的其它資料處理線路，非同步撈取鎖定用戶清單，放入任務佇列中。然後，對鎖定用戶清單中的資料以批次處理的方式進行資料合併更新處理，從而可以高效的實現對鎖定用戶的資料更新處理。同時，還可以確保在此期間，容災資料庫中其他資料的正常交易處理。
圖3是本說明書提供的另一種容災資料處理方法實施例流程示意圖。如圖3所示，本說明書的另一個實施例中，所述方法還可以包括：
S2202：對鎖定用戶對應的閘道帳戶資料進行合併更新批次處理時，當容災資料庫獲取業務請求方發送的第二業務處理請求後，根據所述第二業務處理請求中的用戶資訊來判斷相應用戶是否屬於總黑名單，獲得第二判斷結果；
S2204：第二判斷結果為否時，根據所述第二業務處理請求中的用戶資訊來確定相應用戶對應的容災帳戶；
S2206：根據所述相應用戶對應的容災帳戶對所述第二業務處理請求中的交易進行完整記帳；
在一些實施方式中，當採用非同步的方式對鎖定用戶對應的閘道帳戶資料進行合併更新批次處理的同時，還可以根據第二業務處理請求中的用戶資訊來判斷相應用戶是否屬於總黑名單，獲得第二判斷結果。如果第二判斷結果為否，即相應用戶不屬於未決帳戶，也未在閘道記帳期間進行交易，則該用戶屬於正常用戶。
此時，對於正常用戶，可以根據所述第二業務處理請求中的用戶資訊來確定相應用戶對應的容災帳戶，根據所述相應用戶對應的容災帳戶對所述第二業務處理請求中的交易進行完整記帳。
具體實施時，參考上述實施例的方案，根據所述第二業務處理請求中的用戶資訊來確定對應的容災帳戶時，如果沒有匹配到相應的容災帳戶，則可以說明該用戶是第一次在容災資料中進行業務處理。
則可以在容災資料庫中新建一個餘額為零的容災帳戶，然後，可以根據所述第二業務處理請求中的用戶資訊來調取讀庫及tair(緩存)等資料庫中相應用戶的帳務資料，合併到相應用戶對應的容災帳戶中，將該容災帳戶中的帳務資料更新成完整的帳務資料。則合併更新處理後的容災帳戶中包含了相應用戶的完整帳務資料。然後，可以基於合併更新處理後的容災帳戶而對該業務處理請求中的交易進行處理，並記錄在相應的容災帳戶中，實現用戶的完整記帳。
如果在容災資料庫中再次接收到關於該用戶的業務處理請求時，則可以根據用戶資訊來確定相應的容災帳戶，並根據該用戶對應的容災帳戶對業務處理請求中的相應交易進行完整記帳。
當確定非同步進行的鎖定用戶的帳戶資料合併更新完畢後，則可以對除真實黑名單之外的所有用戶進行完整記帳。相應的完整記帳實施方案可以參考步驟S2102-S2106中提供的方案來實施，這裡不做贅述。
本說明書上述實施例提供的方案，透過採用非同步方式對總黑名單中不屬於真實黑名單的用戶進行帳務資料進行合併更新處理的同時，對總黑名單列表之外的正常用戶在容災資料庫中進行正常帳務處理。從而可以進一步提升容災期間資料庫的帳務處理能力。
圖4表示本說明書的一個實施情況中容災資料處理示意圖。如圖4所示，以支付寶的餘額記帳為例來說明本說明書實施例方案的具體實現方式。為了便於說明，可以將容災資料庫中資料處理方式看作兩個不同的階段：閘道failover階段(對應於閘道記帳狀態)、完整failover階段(對應於完整記帳狀態)。
主庫當機前，假設用戶A在主庫有餘額100元，主庫帳號表為：
Failover庫(容災庫)帳號表：無記錄。
Failover記錄表：無記錄。
主庫當機後，可以非同步產生真實黑名單，同時容災資料庫進行閘道記帳。此時，若用戶A透過銀行卡向支付寶餘額中充值100元，可以先初始化failover(容災庫)記錄為閘道記帳，並對用戶A初始化一個餘額為零的failover帳戶資訊，可以將此failover帳戶資訊稱之為閘道帳戶。然後，將用戶A充值的100元存入用戶A對應的閘道帳戶，並對用戶A進行打標並存入閘道黑名單列表中。則：
主庫帳號表為：
Failover庫中帳號表為：
Failover記錄表為：
當非同步判斷產生真實黑名單後，容災資料庫撈取真實黑名單與閘道黑名單，合併獲得總黑名單。並將總黑名單中不屬於真實黑名單的用戶進行鎖定，獲得鎖定用戶。
然後，非同步結合讀庫、fair資料對用戶A在Failover庫中帳號進行合併更新，更新後：
主庫帳號表為：
Failover庫帳號表為：
可以將用戶A在Failover庫中帳號進行合併更新後的帳戶稱之為用戶A的容災帳戶。此後，若再接收到用戶A業務處理請求，則可以利用用戶A的容災帳戶對業務處理請求中的交易進行完整記帳。如，若用戶A使用餘額支出100，則：
Failover庫帳號表為：
Failover記錄表為：
假設用戶B在總黑名單產生前，未進行閘道記帳，其主機帳戶餘額為300元。總黑名單產生之後，容災資料庫接收到用戶B的業務處理請求，可以先判斷用戶B是否屬於總黑名單。若不屬於，則可以為用戶B初始化一個餘額為零的容災帳戶，並撈取用戶B在讀庫、fair中的最新記錄資料合併至用戶B的容災帳戶中，獲得用戶B合併更新後的容災帳戶。此時：
主庫帳號表為：
Failover庫帳號表為：
若接收到的業務處理請求中的交易資訊為用戶B使用餘額支出100，利用用戶B合併更新後的容災帳戶對該交易正常處理後，則：
Failover庫帳號表為：
Failover記錄表為：
相應地，假設真實黑名單產生之後，若判斷用戶C屬於真實黑名單，則完整記帳狀態下，可以拒絕對用戶C的業務處理請求。若用戶C還屬於閘道黑名單，即用戶C在閘道記帳狀態下進行過流入類交易，則可以在容災資料庫中保留用戶C的閘道記帳記錄資料，以備於後續資料回遷等處理。
從而，利用本說明書上述實施例提供的方案，可以實現在容災期間對除真實黑名單之外的其他用戶帳戶的正常交易，且同時避免了容災庫、主庫同時記帳的風險。
在備庫被拉起或者主庫被修復後，可以將容災庫的資料進行回遷。本說明書的一個實施例中，可以根據記帳狀態對容災庫中的資料進行回遷處理，其中，所述記帳狀態包括閘道記帳、完整記帳。
若判斷記帳狀態為閘道記帳，則可以僅將閘道帳戶餘額增加至主庫或者備庫餘額中。若判斷記帳狀態為完整記帳，則可以將相應採用完整記帳的用戶資料進行整體回遷。從而可以提高回遷資料處理的效率以及準確性。
本說明書中的各個實施例均採用漸進的方式描述，各個實施例之間相同相似的部分互相參見即可，每個實施例重點說明的都是與其他實施例的不同之處。具體上可以參照前述相關處理相關實施例的描述，在此不做一一贅述。
上述對本說明書特定實施例進行了描述。其它實施例在所附申請專利範圍的範疇之內。在一些情況下，在申請專利範圍中記載的動作或步驟可以按照不同於實施例中的順序來執行並且仍然可以實現期望的結果。另外，在圖式中描繪的過程不一定要求示出的特定順序或者連續順序才能實現期望的結果。在某些實施方式中，多工處理和並行處理也是可以的或者可能是有利的。
本說明書一個或多個實施例提供的一種容災資料處理方法，可以透過在主庫容災期間，先利用閘道記帳方式對流入類交易資料進行處理，將閘道記帳的用戶打標並列入為閘道黑名單中。同時非同步產生真實黑名單，所述真實黑名單用戶可以為主庫發生容災的瞬間，主庫和其他即時同步資料庫資料狀態不一致而產生的未決帳戶。當確定產生真實黑名單後，則可以先將閘道黑名單與真實黑名單合併獲得總黑名單。然後，對總黑名單中不屬於真實黑名單的用戶帳戶進行鎖定，並對鎖定用戶的帳戶資料進行合併更新處理，從而獲得鎖定用戶的完整帳戶資訊。從而，可以防止主機出現當機後主庫、容災庫同時記帳的同時，還可以確保除未決帳戶之外的其他帳戶的正常交易。
基於上述所述的容災資料處理方法，本說明書一個或多個實施例還提供一種容災資料處理裝置。所述的裝置可以包括使用了本說明書實施例所述方法的系統、軟體(應用程式)、模組、元件、伺服器等並結合必要的實施硬體的裝置。基於同一個創新構思，本說明書實施例提供的一個或多個實施例中的裝置如下面的實施例所述。由於裝置解決問題的實現方案與方法相似，因此本說明書實施例具體的裝置的實施可以參見前述方法的實施，重複之處不再贅述。以下所使用的，術語“單元”或者“模組”可以實現預定功能的軟體和/或硬體的組合。儘管以下實施例所描述的裝置較佳地以軟體來實現，但是硬體，或者軟體和硬體的組合的實現也是可能並被構想的。具體地，圖5表示說明書提供的一種容災資料處理裝置實施例的模組結構示意圖，如圖5所示，所述裝置可以包括：
業務資料獲取模組102，可以用於當容災資料庫獲取業務請求方發送的第一業務處理請求後，判斷所述第一業務處理請求的類型是否為流入類，獲得第一判斷結果；
閘道記帳模組104，可以用於若第一判斷結果為是，則根據所述第一業務處理請求中的用戶資訊來確定對應的閘道帳戶，以及根據所述閘道帳戶對所述第一業務處理請求中的交易進行閘道記帳，並將所述用戶資訊對應的用戶打標後列入閘道黑名單；
黑名單合併模組106，可以用來確定非同步產生的真實黑名單，將真實黑名單與閘道黑名單進行合併獲得總黑名單；
帳戶更新模組108，可以用來對總黑名單中不屬於真實黑名單的用戶進行鎖定，對鎖定用戶對應的閘道帳戶資料進行合併更新處理，獲得鎖定用戶對應的容災帳戶。
利用上述實施例中的方案，可以實現在容災期間對除真實黑名單之外的其他用戶帳戶的正常交易。且同時避免了容災庫、主庫同時記帳的風險。
圖6表示說明書提供的另一種容災資料處理裝置實施例的模組結構示意圖。如圖6所示，本說明書的另一個實施例中，所述裝置還可以包括第二完整記帳模組，所述第二完整記帳模組110，所述第二完整記帳模組110可以包括：
第二判斷單元，可以用於當容災資料庫獲取業務請求方發送的第二業務處理請求後，根據所述第二業務處理請求中的用戶資訊來判斷相應用戶是否屬於真實黑名單，獲得第三判斷結果；
第二完整記帳單元，可以用於第三判斷結果為否時，根據所述第二業務處理請求中的用戶資訊來確定相應用戶對應的容災帳戶，以及根據所述相應用戶對應的容災帳戶對所述第二業務處理請求中的交易進行完整記帳。
本說明書的一個或者多個實施例中，所述第二完整記帳單元可以包括：
帳戶更新子單元，可以用於當根據所述第二業務處理請求中的用戶資訊未匹配到對應的容災帳戶時，根據所述第二業務處理請求中的用戶資訊而產生容災帳戶，並對該容災帳戶的資料進行合併更新處理；
完整記帳子單元，可以用於根據合併更新處理後的容災帳戶對所述第二業務處理請求中的交易進行完整記帳。
利用上述實施例提供的方案，可以最大程度地確保容災期間資料庫的帳務處理能力。
本說明書的一個實施例中，所述帳戶更新模組108可以包括：
帳戶更新單元，可以用來採用非同步的方式撈取總黑名單中不屬於真實黑名單的用戶並進行鎖定，並對鎖定用戶對應的閘道帳戶資料進行合併更新批次處理。
利用上述實施例中的方案，可以提高帳戶合併更新處理的效率。
圖7表示說明書提供的另一種容災資料處理裝置實施例的模組結構示意圖。如圖7所示，本說明書的另一個實施例中，當第一帳戶更新模組108採用非同步方式對鎖定用戶進行資料合併更新處理時，所述裝置還可以包括第一完整記帳模組109，所述第一完整記帳模組109可以包括：
第一判斷單元，可以用來對鎖定用戶對應的閘道帳戶資料進行合併更新批次處理時，當容災資料庫獲取業務請求方發送的第二業務處理請求後，根據所述第二業務處理請求中的用戶資訊來判斷相應用戶是否屬於總黑名單，獲得第二判斷結果；
第一完整記帳單元，可以用於第二判斷結果為否時，根據所述第二業務處理請求中的用戶資訊來確定相應用戶對應的容災帳戶，以及根據所述相應用戶對應的容災帳戶對所述第二業務處理請求中的交易進行完整記帳。
相應地，當第一帳戶更新模組108執行完相應操作後，可以進一步利用第二完整記帳模組110來進行後續操作。
需要特殊說明的是，相應的第一完整記帳模組以及第二完整記帳模組僅僅是為了更清楚表述而進行區分定義，二者可以是不同的模組，也可以是同一個模組。當二者是同一個模組時，用以在不同階段執行分配給的不同任務。
本說明書的另一個實施例中，所述裝置還可以包括：
資料回遷模組，可以用於根據記帳狀態對容災庫中的資料進行回遷處理，其中，所述記帳狀態包括閘道記帳以及完整記帳。
利用上述實施例中的方案，可以提高回遷資料處理的效率以及準確性。
需要說明的，上述所述的裝置根據方法實施例的描述還可以包括其他的實施方式。具體的實現方式可以參照相關方法實施例的描述，在此不作一一贅述。
本說明書一個或多個實施例提供的一種容災資料處理裝置，可以透過在主庫容災期間，先利用閘道記帳方式對流入類交易資料進行處理，將閘道記帳的用戶打標並列入為閘道黑名單中。同時非同步產生真實黑名單，所述真實黑名單用戶可以為主庫發生容災的瞬間，主庫和其他即時同步資料庫資料狀態不一致而產生的未決帳戶。當確定產生真實黑名單後，則可以先將閘道黑名單與真實黑名單合併獲得總黑名單。然後，對總黑名單中不屬於真實黑名單的用戶帳戶進行鎖定，並對鎖定用戶的帳戶資料進行合併更新處理，從而獲得鎖定用戶的完整帳戶資訊。從而，可以防止主機出現當機後主庫、容災庫同時記帳的同時，還可以確保除未決帳戶之外的其他帳戶的正常交易。
本說明書提供的上述實施例所述的方法或裝置可以透過電腦程式來實現業務邏輯並被記錄在儲存媒體上，所述的儲存媒體可以被電腦讀取並執行，實現本說明書實施例所描述方案的效果。因此，本說明書還提供一種容災資料處理設備，包括處理器及儲存處理器可執行指令的記憶體，所述指令被所述處理器執行時實現包括以下步驟：
當容災資料庫獲取業務請求方發送的第一業務處理請求後，判斷所述第一業務處理請求的類型是否為流入類，獲得第一判斷結果；
若第一判斷結果為是，則根據所述第一業務處理請求中的用戶資訊來確定對應的閘道帳戶，以及根據所述閘道帳戶對所述第一業務處理請求中的交易進行閘道記帳，並將所述用戶資訊對應的用戶打標後列入閘道黑名單；
確定非同步產生的真實黑名單，將真實黑名單與閘道黑名單進行合併獲得總黑名單；
對總黑名單中不屬於真實黑名單的用戶進行鎖定，對鎖定用戶對應的閘道帳戶資料進行合併更新處理，獲得鎖定用戶對應的容災帳戶。
所述儲存媒體可以包括用以儲存資訊的物理裝置，通常是將資訊數位化後再以利用電、磁或者光學等方式的媒體來加以儲存。所述儲存媒體有可以包括：利用電能方式來儲存資訊的裝置如，各式記憶體，如RAM、ROM等；利用磁能方式來儲存資訊的裝置如，硬碟、軟碟、磁帶、磁芯記憶體、磁泡記憶體、U碟；利用光學方式來儲存資訊的裝置如，CD或DVD。當然，還有其他方式的可讀儲存媒體，例如量子記憶體、石墨烯記憶體等等。
需要說明的，上述所述的處理設備根據方法實施例的描述還可以包括其他的實施方式。具體的實現方式可以參照相關方法實施例的描述，在此不作一一贅述。
本說明書實施例所提供的方法實施例可以在移動終端、電腦終端、伺服器或者類似的計算裝置中執行。以運行在伺服器上為例，圖8是應用本發明實施例的一種容災資料處理伺服器的硬體結構方塊圖。如圖8所示，伺服器10可以包括一個或多個(圖中僅示出一個)處理器100(處理器100可以包括但不限於微處理器MCU或可程式設計邏輯裝置FPGA等的處理裝置)、用以儲存資料的記憶體200、以及用於通訊功能的傳輸模組300。本發明所屬技術領域中具有通常知識者可以理解到，圖8所示的結構僅為示意，其並不對上述電子裝置的結構造成限定。例如，伺服器10還可包括比圖8中所示更多或者更少的元件，例如還可以包括其他的處理硬體，如資料庫或多級緩存、GPU，或者具有與圖8所示不同的配置。
記憶體200可用以儲存應用軟體的軟體程式以及模組，如本發明實施例中的搜尋方法對應的程式指令/模組，處理器100透過運行儲存在記憶體200內的軟體程式以及模組，從而執行各種功能應用程式以及資料處理。記憶體200可包括高速隨機記憶體，還可包括非易失性記憶體，如一個或者多個磁性儲存裝置、快閃記憶體、或者其他非易失性固態記憶體。在一些實例中，記憶體200可進一步包括相對於處理器100遠端設置的記憶體，這些遠端儲存器可以透過網路而被連接至電腦終端。上述網路的實例包括但不限於網際網路、企業內部網、局域網、移動通訊網及其組合。
傳輸模組300用以經由一個網路來接收或者發送資料。上述的網路具體實例可包括電腦終端的通訊供應商提供的無線網路。在一個實例中，傳輸模組300包括一個網路介面卡(Network Interface Controller，NIC)，其可透過基站與其他網路設備相連從而可與網際網路進行通訊。在一個實例中，傳輸模組300可以為射頻(Radio Frequency，RF)模組，其用以透過無線方式而與網際網路進行通訊。
上述實施例所述的一種容災資料處理設備，可以透過在主庫容災期間，先利用閘道記帳方式對流入類交易資料進行處理，將閘道記帳的用戶打標並列入為閘道黑名單中。同時非同步產生真實黑名單，所述真實黑名單用戶可以為主庫發生容災的瞬間，主庫和其他即時同步資料庫資料狀態不一致而產生的未決帳戶。當確定產生真實黑名單後，則可以先將閘道黑名單與真實黑名單合併獲得總黑名單。然後，對總黑名單中不屬於真實黑名單的用戶帳戶進行鎖定，並對鎖定用戶的帳戶資料進行合併更新處理，從而獲得鎖定用戶的完整帳戶資訊。從而，可以防止主機出現當機後主庫、容災庫同時記帳的同時，還可以確保除未決帳戶之外的其他帳戶的正常交易。
本說明書還提供一種容災資料處理系統，所述系統可以為單獨的容災資料處理系統，也可以應用在業務處理分散式系統中。所述的系統可以為單獨的伺服器，也可以包括使用了本說明書的一個或多個所述方法或一個或多個實施例裝置的伺服器集群、系統(包括分散式系統)、軟體(應用程式)、實際操作裝置、邏輯閘電路裝置、量子電腦等並結合必要的實施硬體的終端裝置。所述容災資料處理系統可以包括至少一個處理器以及儲存電腦可執行指令的記憶體，所述處理器執行所述指令時實現上述任意一個或者多個實施例中所述方法的步驟。
需要說明的，上述所述的系統根據方法或者裝置實施例的描述還可以包括其他的實施方式，具體的實現方式可以參照相關方法實施例的描述，在此不作一一贅述。
上述實施例所述的一種容災資料處理系統，可以透過在主庫容災期間，先利用閘道記帳方式對流入類交易資料進行處理，將閘道記帳的用戶打標並列入為閘道黑名單中。同時非同步產生真實黑名單，所述真實黑名單用戶可以為主庫發生容災的瞬間，主庫和其他即時同步資料庫資料狀態不一致而產生的未決帳戶。當確定產生真實黑名單後，則可以先將閘道黑名單與真實黑名單合併獲得總黑名單。然後，對總黑名單中不屬於真實黑名單的用戶帳戶進行鎖定，並對鎖定用戶的帳戶資料進行合併更新處理，從而獲得鎖定用戶的完整帳戶資訊。從而，可以防止主機出現當機後主庫、容災庫同時記帳的同時，還可以確保除未決帳戶之外的其他帳戶的正常交易。
需要說明的是，本說明書上述所述的裝置或者系統根據相關方法實施例的描述還可以包括其他的實施方式，具體的實現方式可以參照方法實施例的描述，在此不作一一贅述。本說明書中的各個實施例均採用漸進的方式描述，各個實施例之間相同相似的部分互相參見即可，每個實施例重點說明的都是與其他實施例的不同之處。尤其，對於硬體+程式類、儲存媒體+程式實施例而言，由於其基本上類似於方法實施例，所以描述的比較簡單，相關之處參見方法實施例的部分說明即可。
儘管本說明書實施例內容中提到閘道記帳、資料合併更新處理之類的獲取、定義、互動、計算、判斷等操作和資料描述，但是，本說明書實施例並不局限於必須是符合標準資料模型/範本或本說明書實施例所描述的情況。某些行業標準或者使用自訂方式或實施例描述的實施基礎上略加修改後的實施方案也可以實現上述實施例相同、等同或相近、或變形後可預料的實施效果。應用這些修改或變形後的資料獲取、儲存、判斷、處理方式等獲取的實施例，仍然可以屬於本說明書的可選實施方案範圍之內。
上述對本說明書特定實施例進行了描述。其它實施例在所附申請專利範圍的範疇內。在一些情況下，在申請專利範圍中記載的動作或步驟可以按照不同於實施例中的順序來執行並且仍然可以實現期望的結果。另外，在圖式中描繪的過程不一定要求示出的特定順序或者連續順序才能實現期望的結果。在某些實施例中，多工處理和並行處理也是可以的或者可能是有利的。
上述實施例闡明的系統、裝置、模組或單元，具體可以由電腦晶片或實體實現，或者由具有某種功能的產品來實現。一種典型的實現設備為電腦。具體地，電腦例如可以為個人電腦、膝上型電腦、車載人機互動設備、蜂巢式電話、相機電話、智慧型電話、個人數位助理、媒體播放機、導航設備、電子郵件設備、遊戲控制台、平板電腦、可穿戴設備或者這些設備中的任何設備的組合。
為了描述的方便，描述以上裝置時以功能分為各種模組來分別描述。當然，在實施本說明書一個或多個時可以把各模組的功能在同一個或多個軟體和/或硬體中實現，也可以將實現同一功能的模組由多個子模組或子單元的組合來實現等。以上所描述的裝置實施例僅僅是示意性的，例如，所述單元的劃分，僅僅為一種邏輯功能劃分，實際實現時可以有另外的劃分方式，例如多個單元或元件可以結合或者可以整合到另一個系統，或一些特徵可以忽略，或不執行。另一點，所顯示或討論的相互之間的耦合或直接耦合或通訊連接可以是透過一些介面、裝置或單元的間接耦合或通訊連接，可以是電性、機械或其它的形式。
本發明所屬技術領域中具有通常知識者也知道，除了以純電腦可讀程式碼方式來實現控制器以外，完全可以透過將方法步驟進行邏輯程式設計來使得控制器以邏輯閘、開關、特殊應用積體電路、可程式設計邏輯控制器和嵌入式微控制器等的形式來實現相同功能。因此這種控制器可以被認為是一種硬體部件，而對其內部包括的用來實現各種功能的裝置也可以視為硬體部件內的結構。或者甚至，可以將用來實現各種功能的裝置視為既可以是實現方法的軟體模組又可以是硬體部件內的結構。
本發明是參照根據本發明實施例的方法、設備(系統)、和電腦程式產品的流程圖和／或方塊圖來描述的。應理解可由電腦程式指令實現流程圖和／或方塊圖中的每一個流程和／或方塊、以及流程圖和／或方塊圖中的流程和／或方塊的結合。可提供這些電腦程式指令到通用電腦、專用電腦、嵌入式處理機或其他可程式設計資料處理設備的處理器以產生一個機器，使得透過電腦或其他可程式設計資料處理設備的處理器執行的指令產生用來實現在流程圖中的一個流程或多個流程和／或方塊圖中的一個方塊或多個方塊中指定的功能的裝置。
這些電腦程式指令也可被儲存在能引導電腦或其他可程式設計資料處理設備以特定方式操作的電腦可讀記憶體中，使得儲存在該電腦可讀記憶體中的指令產生包括指令裝置的製造品，該指令裝置實現在流程圖中的一個流程或多個流程和／或方塊圖中的一個方塊或多個方塊中指定的功能。
這些電腦程式指令也可被裝載到電腦或其他可程式設計資料處理設備上，使得在電腦或其他可程式設計設備上執行一系列操作步驟以產生電腦實現的處理，從而在電腦或其他可程式設計設備上執行的指令提供用來實現在流程圖中的一個流程或多個流程和／或方塊圖中的一個方塊或多個方塊中指定的功能的步驟。
在一個典型的配置中，計算設備包括一個或多個處理器(CPU)、輸入/輸出介面、網路介面和記憶體。
還需要說明的是，術語“包括”、“包含”或者其任何其他變體意在涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、商品或者設備不僅包括那些要素，而且還包括沒有明確列出的其他要素，或者是還包括為這種過程、方法、商品或者設備所固有的要素。在沒有更多限制的情況下，由語句“包括一個……”限定的要素，並不排除在包括所述要素的過程、方法或者設備中還存在另外的相同要素。
本發明所屬技術領域中具有通常知識者應明白，本說明書一個或多個實施例可提供為方法、系統或電腦程式產品。因此，本說明書一個或多個實施例可採用完全硬體實施例、完全軟體實施例或結合軟體和硬體態樣的實施例的形式。而且，本說明書一個或多個實施例可採用在一個或多個其中包含有電腦可用程式碼的電腦可用儲存媒體(包括但不限於磁碟記憶體、CD-ROM、光學記憶體等)上實施的電腦程式產品的形式。
本說明書一個或多個實施例可以在由電腦執行的電腦可執行指令的一般上下文中描述，例如程式模組。一般地，程式模組包括執行特定任務或實現特定抽象資料類型的常式、程式、物件、元件、資料結構等等。也可以在分散式計算環境中實踐本本說明書一個或多個實施例，在這些分散式計算環境中，由透過通訊網路而被連接的遠端處理設備來執行任務。在分散式計算環境中，程式模組可以位於包括儲存裝置在內的本地和遠端電腦儲存媒體中。
本說明書中的各個實施例均採用漸進的方式來描述，各個實施例之間相同相似的部分互相參見即可，每個實施例重點說明的都是與其他實施例的不同之處。尤其，對於系統實施例而言，由於其基本上類似於方法實施例，所以描述的比較簡單，相關之處參見方法實施例的部分說明即可。在本說明書的描述中，參考術語“一個實施例”、“一些實施例”、“示例”、“具體示例”、或“一些示例”等的描述意指結合該實施例或示例描述的具體特徵、結構、材料或者特點包含於本說明書的至少一個實施例或示例中。在本說明書中，對上述術語的示意性表述並不必須針對的是相同的實施例或示例。而且，描述的具體特徵、結構、材料或者特點可以在任一個或多個實施例或示例中以合適的方式結合。此外，在不相互矛盾的情況下，本發明所屬技術領域中具有通常知識者可以將本說明書中描述的不同實施例或示例以及不同實施例或示例的特徵進行結合和組合。
以上所述僅為本說明書的實施例而已，並不用來限制本說明書。對於本發明所屬技術領域中具有通常知識者來說，本說明書可以有各種更改和變化。凡在本說明書的精神和原理之內所作的任何修改、等同替換、改進等，均應包含在本說明書的申請專利範圍的範疇之內。In order to enable those skilled in the art to better understand the technical solutions in this specification, the following will combine the drawings in one or more embodiments of this specification to clearly and complete the technical solutions in one or more embodiments of this specification. It is obvious that the described embodiments are only a part of the embodiments of the specification, rather than all the embodiments. Based on one or more embodiments of the specification, all other embodiments obtained by a person with ordinary knowledge in the technical field of the present invention without creative work shall fall within the protection scope of the embodiment scheme of this specification. A network failure or unexpected termination of the database may cause some or all of the services to be unavailable, which is called database failover (disaster tolerance) in the industry. General database has a main database and a standby database, and database failover usually occurs on the main database. When the main database is unavailable, it takes a certain time to pull up the standby database. During this time, in order to ensure business progress, the account information is usually written into the FO database (or disaster recovery database). After the standby database is pulled up or the main database is repaired, the data in the disaster recovery database is written into the main database or the standby database. However, when the disaster recovery database is used for accounting data processing, the moment the main database is down, the data status of the main database and other real-time synchronization databases may be inconsistent, so that the accurate accounting data of users in the main database during the disaster recovery period cannot be accurately known. For example, the user’s accurate balance restricts the user’s normal transactions and brings a bad experience to the user. At the same time, there may be inconsistencies in the state of some distributed servers during the process switching process, which leads to the risk of accounting for the main database and disaster tolerance inventory at the same time. Correspondingly, the embodiment of this specification provides a database disaster recovery data processing method. During the accounting disaster recovery period, the inbound transaction data is processed by the gateway accounting method, and the gateway accounting accounts are marked and listed as The gateway is in the blacklist. At the same time, a real blacklist is generated asynchronously, and the real blacklist user can be a pending account generated by the inconsistent data status of the main database and other real-time synchronized databases at the moment when disaster recovery occurs in the main database. When it is determined that the real blacklist is generated, the gateway blacklist and the real blacklist can be merged to obtain the total blacklist. Then, the user accounts in the total blacklist that are not part of the real blacklist are locked, and the information of the locked user account is merged and updated, so as to obtain the complete accounting information of the locked user account. Using the solution of the embodiment of the present specification, when the host machine crashes, data processing can be transferred to the disaster recovery library to prevent the main library and the disaster recovery library from simultaneously accounting. And adopt the gateway accounting method that only allows inbound transactions to mark the gateway accounting users and include them in the gateway blacklist. At the same time, it can also identify pending accounts asynchronously to generate a real blacklist; and after the real blacklist is determined, the data of the gateway accounts outside the real blacklist are merged and updated. In this way, all users before the real blacklist can perform normal transactions during the disaster recovery period. FIG. 1 is a schematic flowchart of an embodiment of the disaster recovery data processing method provided in this specification. Although this specification provides method operation steps or device structures as shown in the following embodiments or drawings, the method or device may include more or fewer operation steps after partial combination based on conventional or no creative labor. Or module unit. In steps or structures where there is no necessary causal relationship logically, the execution order of these steps or the module structure of the device is not limited to the execution order or module structure shown in the embodiments or drawings of this specification. When the method or module structure is applied to an actual device, server or terminal product, it can be executed sequentially or concurrently (for example, parallel processing) according to the method or module structure shown in the embodiment or the diagram Server or multi-threaded processing environment, even including distributed processing, server cluster implementation environment). A specific implementation is shown in Figure 1. In an embodiment of the disaster tolerance data processing method provided in this specification, the method may include: S202: After the disaster tolerance database obtains the first service processing request sent by the service requester , Determine whether the type of the first service processing request is an inflow type, and obtain a first determination result. In the host disaster recovery state, you can stop the host data recording and call the disaster recovery database to process the business. In an embodiment of this specification, in the process of business processing by the disaster recovery database, before determining pending account data, gateway accounting may be performed. Wherein, the gateway accounting may include a data processing state that only allows inflow and does not allow outflow. When the disaster recovery database performs gateway accounting, it can only be used to process inbound transactions, and not allow outbound transactions. The inflow transaction generally refers to a certain user account, the fund flow direction of the transaction is directed to the user account, and the usual performance is as an increase in user account funds. For example, it can include the transaction of depositing funds to the Alipay balance. For example, it can include the transaction of depositing funds to the Alipay balance of account A through a third-party platform such as a bank card, and it can also include the transaction of depositing funds to account A through the Alipay balance of other accounts. Transactions of depositing funds in Alipay balance, etc. Correspondingly, the transaction of outflow of funds from the user account can be referred to as an outflow transaction, which usually manifests as a decrease in user account funds. For example, the transaction of outflow of funds in the Alipay balance of account A is called the outflow transaction of account A. The first service processing request may include transaction information such as service type, transaction funds, and user information (such as user ID). After the disaster tolerance database obtains the first service processing request, the service type may be obtained first, and the service type may include inflow type transactions and outflow type transactions. Then, it can be determined whether the transaction type is an inflow transaction, and the first determination result is obtained. S204: If the first judgment result is yes, determine the corresponding gateway account according to the user information in the first service processing request, and perform the transaction in the first service processing request according to the gateway account Gateway accounting, and marking the user corresponding to the user information into the gateway blacklist. If the first judgment result is yes, that is, the service type in the first service processing request is an inflow type, the transaction in the first service processing request may be accounted for through the gateway. In order to distinguish accounts in other states, in the embodiments of this specification, the corresponding account in the gateway accounting state may be referred to as a gateway account. In some embodiments, it can be determined whether there is a corresponding gateway account based on the user information in the first service processing request. If it is determined based on the user information that there is a corresponding gateway account, the transaction amount in the first service processing request may be recorded in the gateway account corresponding to the user information. If there is no corresponding gateway account, an account with a balance of zero can be created based on the user information as the gateway account of the user corresponding to the user information. Then, the transaction amount in the first service processing request can be obtained, and the transaction amount can be recorded in the newly created gateway account. And mark users who perform gateway accounting. For example, they can be marked as gateway blacklist users and included in the gateway blacklist list. Usually the account can be identified by user information, such as user ID. In order to facilitate data processing, each database and account in each state can use the same identification, such as user ID. If the account identifier of account A in the host is the ID of user A, the corresponding gateway account identifier of account A in the state of gateway accounting is also the ID of user A, so as to facilitate the reading of the data recorded in each database and each state Fetch, merge and update processing. Correspondingly, the user ID corresponding to the user performing the gateway accounting can be marked, and the user ID can be included in the gateway blacklist. Of course, during specific implementation, other methods can also be used to identify the account, which is not limited here. If it is judged that the service type is an outgoing type, the corresponding service processing request can be rejected, for example, a request error message can be returned. S206: Determine the real blacklist generated asynchronously, and merge the real blacklist with the gateway blacklist to obtain a total blacklist. When the disaster recovery of the main database occurs at the moment or within a period of time, the data of the main database and other real-time synchronization databases may have inconsistencies, resulting in pending account data, which can be determined as a real blacklist. For example, the main library receives the incoming transaction information of account C, and the user deposits 200 yuan into account C, and the main library performs corresponding accounting. However, at this time, disaster recovery of the main database occurs, and other synchronized databases will have time to synchronize data in the future, resulting in inconsistencies between the data of the main database account C and other synchronized databases, and the accurate balance of account C cannot be determined. Assume that before the inflow transaction, the balance of account C is 100 yuan, and after the inflow transaction, the balance of account C should be 300 yuan. However, the synchronization database did not receive the corresponding data, and the balance of the synchronization database account C is still 100 yuan. If account C wants to conduct an outflow transaction of 200 yuan, and the data processing is performed by a synchronized database, the transaction may fail. In some implementations, during gateway accounting using the disaster recovery database, other data processing circuits different from the gateway accounting can be used at the same time to analyze the data of the main database and other real-time synchronization database asynchronously, determine pending accounts, and obtain Real blacklist list. In the process of gateway accounting, because I do not know which accounts are pending accounts, the method of allowing only inbound transactions but not outbound transactions can prevent the loss of platform funds and ensure the normal progress of some inbound transactions. After the real blacklist is determined asynchronously, the gateway blacklist generated during the gateway accounting period can be retrieved, and then the real blacklist and the gateway blacklist are merged to obtain the total blacklist list. S208: Lock users who are not in the real blacklist on the total blacklist, merge and update the gateway account data corresponding to the locked users, and obtain the disaster recovery account corresponding to the locked users. You can lock the gateway accounts of users who are not in the real blacklist in the total blacklist. In some implementations, for example, it is possible to retrieve the gateway accounts of users who are not in the real blacklist in the total blacklist, and first suspend the transaction processing request of this part of the account. Then, merge and update the gateway account data corresponding to the locked user to obtain the disaster recovery account corresponding to the locked user. Correspondingly, the disaster recovery account of the locked user contains the user's complete account information. In order to facilitate the distinction, in the embodiment of this specification, the user account corresponding to the complete billing period in the disaster recovery database may be called the disaster recovery account. It should be noted that the gateway account and the disaster recovery account are all user accounts in the disaster recovery database, which can be correlated with the account data in other databases through user information. For the same user, the two can be different accounts generated by the special gate for different billing states; they can also be the same account, just for ease of presentation, the names defined in different billing states are different. During specific implementation, it can be set according to actual needs, which is not limited here. In some implementations, the latest data record of the locked user before the main library crashes can be obtained from the synchronization database such as the reader library and tair (cache), and merged with the locked user's gateway account data, will lock the user's corresponding The data in the gateway account is updated to complete accounting data, and the disaster recovery account corresponding to the locked user is obtained. Fig. 2 is a schematic flowchart of another embodiment of a disaster recovery data processing method provided in this specification. As shown in FIG. 2, in another embodiment of this specification, after obtaining the disaster tolerance account corresponding to the locked user, it may further include: S2102: After the disaster tolerance database obtains the second service processing request sent by the service requester , Judging whether the corresponding user belongs to the real blacklist according to the user information in the second service processing request, and obtaining a third judgment result; S2104: when the third judgment result is no, according to the user in the second service processing request The information determines the disaster tolerance account corresponding to the corresponding user; S2106: Perform complete accounting for the transaction in the second service processing request according to the disaster tolerance account corresponding to the corresponding user. In order to better distinguish the expression, in the embodiment of this specification, the service processing request obtained during the gateway accounting period before the determination of the total blacklist may be referred to as the first service processing request, which will be obtained during the complete accounting period after the determination of the total blacklist The service processing request of is called the second service processing request. The two are just the difference between the text and there is no special restriction on the content. Correspondingly, the second service processing request may also include transaction information such as service type, transaction funds, and user information (such as user ID). The complete accounting may include the data processing status allowing both inflow and outflow. When the disaster recovery database performs complete accounting, it is allowed to process both incoming and outgoing transactions. After obtaining the complete accounting information of the locked user, after the disaster recovery database obtains the second service processing request sent by the service requester, it can judge whether the corresponding user belongs to the real blacklist according to the user information in the second service processing request . If it belongs to the real blacklist, you can refuse the corresponding transaction request. If it does not belong to the real blacklist, the disaster recovery account corresponding to the corresponding user can be determined according to the user information in the second service processing request. If it is determined that there is a corresponding disaster recovery account, the corresponding transaction in the service processing request can be fully accounted for according to the corresponding disaster recovery account. After the processing in step S208, all locked users have a disaster recovery account that contains complete accounting data. Therefore, if the business processing request is a business processing request for a locked account, the disaster recovery of the corresponding user can be determined according to the user information Account, and can perform normal inflow and outflow transaction processing based on the disaster recovery account. And the corresponding transaction data can be recorded in the corresponding disaster recovery account. In the embodiments of this specification, users who neither belong to pending accounts nor conduct transactions during the gateway accounting period may be referred to as normal users. It can indicate that the accounting record data of the normal user in the other real-time synchronization data of the main database is correct and complete. In some embodiments, for normal users, if no business processing has been performed in the disaster recovery database, the corresponding account information may not be generated in the disaster recovery data to ensure the simplicity of subsequent data migration. When determining the corresponding disaster recovery account according to the user information in the second service processing request, if the corresponding disaster recovery account is not matched, it can indicate that the user is performing business processing in the disaster recovery data for the first time. Then you can create a disaster recovery account with a zero balance in the disaster recovery database, and then you can retrieve the corresponding user's information in the database such as the reader database and tair (cache) according to the user information in the second service processing request. The accounting information is merged into the disaster recovery account corresponding to the corresponding user, and the accounting information in the disaster recovery account is updated to complete accounting information. Then the disaster recovery account after the merge and update process contains the complete accounting information of the corresponding user. Then, the transaction in the service processing request can be processed based on the disaster recovery account after the merge and update processing, and recorded in the corresponding disaster recovery account, so as to realize the complete accounting of the user. If the user's service processing request is received again in the disaster recovery database, the corresponding disaster recovery account can be determined according to the user information, and the corresponding transaction in the business processing request can be processed according to the user's corresponding disaster recovery account. Perform complete accounting. Correspondingly, in an embodiment of this specification, the determining the disaster tolerance account corresponding to the corresponding user according to the user information in the second service processing request may include: When the information does not match the corresponding disaster recovery account, a disaster recovery account is generated according to the user information in the second service processing request, and the data of the disaster recovery account is merged and updated; accordingly, after the merge update processing The disaster-tolerant account of the complete accounting for the transaction in the second service processing request. The above-mentioned embodiment of this specification provides the solution, after the main library fails, the accounting processing of the main library can be suspended, and the disaster recovery database can be temporarily transferred to process the accounting data to prevent the abnormal accounting processing of the main library from bringing more 'S pending account. Before determining the pending accounts, you can use gateway accounting in the disaster recovery database for accounting processing. In the gateway accounting process, only allow inbound transactions and not outflow transactions are used to prevent the platform Loss of funds. And mark the users of the gateway accounting and put them in the gateway blacklist. At the same time of gateway accounting, the pending accounts generated during the period from the failure of the main database to the activation of the disaster recovery database can be analyzed asynchronously to generate a real blacklist. When the real blacklist is generated, the gateway blacklist and the real blacklist can be merged to obtain the total blacklist. After the general blacklist is determined, the users who are not in the real blacklist in the general blacklist can be combined with accounting information to obtain the complete accounting data of the corresponding users. When the service processing request is received again, the locked user can use the disaster recovery account that contains complete accounting information to perform normal accounting processing. For normal users, a corresponding disaster recovery account can be generated, complete accounting data can be retrieved from the synchronization database, and the disaster recovery account containing complete accounting data can be used for normal business processing. So as to realize the normal accounting processing of users except the real blacklist. Therefore, by using the solution provided by the foregoing embodiment, the accounting processing capability of the database during the disaster recovery period can be ensured to the greatest extent. In another embodiment of the present specification, users who are not in the real blacklist in the total blacklist can be retrieved in an asynchronous manner and locked, and the account data of the locked users are merged and updated in batches. In some embodiments, the transaction processing of the locked user may be suspended first, and while normal accounting is performed on other users, other data processing lines different from the normal accounting are used to retrieve the locked user list asynchronously and put it into the task queue. Then, the data in the locked user list is processed in batch processing to merge and update data, so that the data update processing for locked users can be efficiently realized. At the same time, it can also ensure the normal transaction processing of other data in the disaster recovery database during this period. FIG. 3 is a schematic flowchart of another embodiment of a disaster recovery data processing method provided in this specification. As shown in FIG. 3, in another embodiment of the present specification, the method may further include: S2202: When the gateway account data corresponding to the locked user is merged and updated in batches, when the disaster recovery database obtains the service requester After the second service processing request is sent, determine whether the corresponding user belongs to the general blacklist according to the user information in the second service processing request, and obtain the second judgment result; S2204: When the second judgment result is no, according to the The user information in the second service processing request is used to determine the disaster recovery account corresponding to the corresponding user; S2206: complete accounting for the transaction in the second service processing request according to the disaster recovery account corresponding to the corresponding user; in some embodiments , When the gateway account data corresponding to the locked user is merged and updated batch processing in an asynchronous manner, it is also possible to determine whether the corresponding user belongs to the total blacklist according to the user information in the second service processing request, and obtain the first 2. Judgment results. If the second judgment result is negative, that is, the corresponding user does not belong to a pending account and does not conduct a transaction during the gateway accounting period, then the user belongs to a normal user. At this time, for normal users, the disaster recovery account corresponding to the corresponding user can be determined according to the user information in the second service processing request, and the disaster recovery account corresponding to the corresponding user can be The transaction is fully booked. In specific implementation, referring to the solution of the above-mentioned embodiment, when the corresponding disaster recovery account is determined according to the user information in the second service processing request, if the corresponding disaster recovery account is not matched, it can indicate that the user is the first Perform business processing in disaster recovery data. Then you can create a disaster recovery account with a zero balance in the disaster recovery database, and then you can retrieve the corresponding user's information in the database such as the reader database and tair (cache) according to the user information in the second service processing request. The accounting information is merged into the disaster recovery account corresponding to the corresponding user, and the accounting information in the disaster recovery account is updated to complete accounting information. Then the disaster recovery account after the merge and update process contains the complete accounting information of the corresponding user. Then, the transaction in the service processing request can be processed based on the merged and updated disaster tolerance account, and recorded in the corresponding disaster tolerance account, so as to realize the complete accounting of the user. If the user's service processing request is received in the disaster recovery database again, the corresponding disaster recovery account can be determined according to the user information, and the corresponding transaction in the business processing request can be performed according to the user's corresponding disaster recovery account. Complete accounting. When it is determined that the account information of the locked user is merged and updated asynchronously, all users except the real blacklist can be fully accounted for. The corresponding complete billing implementation scheme can be implemented with reference to the scheme provided in steps S2102-S2106, which will not be repeated here. The solution provided in the above-mentioned embodiment of this specification uses an asynchronous method to merge and update the accounting data of users who are not in the real blacklist in the general blacklist. At the same time, the normal users outside the general blacklist are in disaster recovery. Normal accounting processing in the database. This can further improve the accounting processing capabilities of the database during disaster recovery. Figure 4 shows a schematic diagram of disaster recovery data processing in an implementation of this specification. As shown in Fig. 4, taking Alipay’s balance accounting as an example to illustrate the specific implementation of the solution of the embodiment of this specification. For ease of description, the data processing method in the disaster recovery database can be regarded as two different stages: the gateway failover stage (corresponding to the gateway accounting status) and the complete failover stage (corresponding to the complete accounting status). Before the main library crashes, suppose that user A has a balance of 100 yuan in the main library. The main library account table is: Failover database (disaster recovery database) account table: no record. Failover record table: No record. After the main database is down, the real blacklist can be generated asynchronously, and the disaster recovery database can perform gateway accounting. At this point, if user A recharges 100 yuan into Alipay balance through a bank card, he can first initialize the failover (disaster recovery library) record as a gateway accounting, and initialize a failover account information with a zero balance for user A, which can failover The account information is called a gateway account. Then, the 100 yuan recharged by user A is deposited into the gateway account corresponding to user A, and user A is marked and stored in the gateway blacklist. Then: The main library account table is: The account table in the Failover library is: The Failover record table is: When the real blacklist is generated by asynchronous judgment, the disaster recovery database retrieves the real blacklist and the gateway blacklist, and merges them to obtain the total blacklist. And lock users who are not part of the real blacklist in the total blacklist, and obtain locked users. Then, combine the read database and fair data asynchronously to merge and update user A's account in the Failover database. After the update: The main database account table is: Failover library account table is: The account after the merge and update of the account of user A in the Failover database can be called the disaster recovery account of user A. Thereafter, if the service processing request of user A is received again, the disaster recovery account of user A can be used to complete accounting for the transaction in the service processing request. For example, if user A uses the balance to spend 100, then: Failover database account table is: The Failover record table is: Suppose that user B did not perform gateway accounting before the generation of the total blacklist, and his host account balance was 300 yuan. After the general blacklist is generated, the disaster recovery database receives the service processing request of user B, and can first determine whether user B belongs to the general blacklist. If it does not, you can initialize a disaster recovery account with a zero balance for user B, and retrieve the latest record data of user B in the reading library and fair and merge it into the disaster recovery account of user B to obtain the updated capacity of user B. Disaster account. At this time: The main library account table is: Failover library account table is: If the transaction information in the received service processing request is that user B uses the balance to spend 100, and the transaction is processed normally using the updated disaster recovery account of user B, then: The Failover database account table is: The Failover record table is: Correspondingly, assuming that after the real blacklist is generated, if it is judged that the user C belongs to the real blacklist, the service processing request to the user C can be rejected in the complete accounting state. If user C still belongs to the gateway blacklist, that is, user C has performed inbound transactions in the state of gateway accounting, the gateway accounting record data of user C can be kept in the disaster recovery database for subsequent data migration, etc. deal with. Therefore, by using the solutions provided by the foregoing embodiments of this specification, normal transactions to user accounts other than the real blacklist during disaster recovery can be realized, and at the same time, the risk of simultaneous accounting of the disaster recovery library and the main library can be avoided. After the standby database is pulled up or the main database is repaired, the data in the disaster recovery database can be moved back. In an embodiment of the present specification, the data in the disaster recovery library can be migrated back according to the accounting status, where the accounting status includes gateway accounting and complete accounting. If it is judged that the accounting status is gateway accounting, you can only add the gateway account balance to the main library or standby library balance. If it is judged that the billing status is complete billing, the corresponding user data with complete billing can be migrated back as a whole. Thereby, the efficiency and accuracy of data processing for relocation can be improved. The various embodiments in this specification are described in a gradual manner, and the same or similar parts between the various embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. For details, reference may be made to the description of the foregoing related processing related embodiments, which will not be repeated here. The foregoing describes specific embodiments of this specification. Other embodiments are within the scope of the attached patent application. In some cases, the actions or steps described in the scope of the patent application may be performed in a different order from the embodiment and still achieve desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or sequential order shown in order to achieve the desired result. In some embodiments, multiplexing and parallel processing are also possible or may be advantageous. One or more embodiments of this specification provide a disaster recovery data processing method. During the disaster recovery period of the main database, the inbound transaction data can be processed by the gateway accounting method, and the users of the gateway accounting can be marked and listed as The gateway is in the blacklist. At the same time, a real blacklist is generated asynchronously, and the real blacklist user can be a pending account generated by the inconsistent data status of the main database and other real-time synchronized databases at the moment when disaster recovery occurs in the main database. When it is determined that the real blacklist is generated, the gateway blacklist and the real blacklist can be merged to obtain the total blacklist. Then, the user accounts in the total blacklist that are not part of the real blacklist are locked, and the account data of the locked users are merged and updated, so as to obtain the complete account information of the locked users. As a result, it can prevent the main library and the disaster recovery library from accounting at the same time after the host crashes, and at the same time, it can also ensure the normal transactions of other accounts except the pending account. Based on the disaster tolerance data processing method described above, one or more embodiments of this specification also provide a disaster tolerance data processing device. The described devices may include systems, software (applications), modules, components, servers, etc. that use the methods described in the embodiments of this specification, combined with necessary implementation hardware devices. Based on the same innovative concept, the devices in one or more embodiments provided in the embodiments of this specification are as described in the following embodiments. Since the implementation scheme of the device to solve the problem is similar to the method, the implementation of the specific device in the embodiment of this specification can refer to the implementation of the foregoing method, and the repetition will not be repeated. As used below, the term "unit" or "module" can be a combination of software and/or hardware that can implement predetermined functions. Although the device described in the following embodiments is preferably implemented by software, the implementation of hardware or a combination of software and hardware is also possible and conceived. Specifically, FIG. 5 shows a schematic diagram of the module structure of an embodiment of a disaster tolerance data processing device provided in the specification. As shown in FIG. 5, the device may include: a business data acquisition module 102, which can be used as a disaster tolerance database After obtaining the first service processing request sent by the service requester, it is judged whether the type of the first service processing request is an inflow type, and the first judgment result is obtained; the gateway accounting module 104 can be used if the first judgment result is If yes, the corresponding gateway account is determined according to the user information in the first service processing request, and the transaction in the first service processing request is accounted for through the gateway according to the gateway account, and the The user corresponding to the user information is marked on the gateway blacklist; the blacklist merging module 106 can be used to determine the real blacklist generated asynchronously, and merge the real blacklist with the gateway blacklist to obtain the total blacklist; The account update module 108 can be used to lock users who are not in the real blacklist in the total blacklist, merge and update the gateway account data corresponding to the locked users, and obtain the disaster recovery accounts corresponding to the locked users. Using the solution in the foregoing embodiment, normal transactions to user accounts other than the real blacklist can be realized during the disaster recovery period. At the same time, it avoids the risk of simultaneous accounting for the disaster recovery library and the main library. FIG. 6 shows a schematic diagram of the module structure of another embodiment of the disaster tolerance data processing device provided in the specification. As shown in FIG. 6, in another embodiment of this specification, the device may further include a second complete accounting module, the second complete accounting module 110, and the second complete accounting module 110 may include: The second judgment unit may be used to determine whether the corresponding user belongs to the real blacklist according to the user information in the second service processing request after the disaster tolerance database obtains the second service processing request sent by the service requester, and obtains the first Three judgment results; The second complete accounting unit can be used to determine the disaster tolerance account corresponding to the corresponding user according to the user information in the second service processing request when the third judgment result is no, and according to the corresponding user corresponding The disaster-tolerant account of the complete accounting for the transaction in the second service processing request. In one or more embodiments of this specification, the second complete billing unit may include: an account update subunit, which may be used when the user information in the second service processing request does not match the corresponding disaster recovery account When the disaster recovery account is generated according to the user information in the second service processing request, and the data of the disaster recovery account is merged and updated; the complete accounting subunit can be used to update the processed disaster recovery account according to the merge Perform complete accounting for the transaction in the second service processing request. Using the solution provided by the foregoing embodiment, the accounting processing capability of the database during the disaster recovery period can be ensured to the greatest extent. In an embodiment of this specification, the account update module 108 may include: an account update unit, which can be used to obtain and lock users who are not in the real blacklist from the total blacklist in an asynchronous manner, and lock the users The corresponding gateway account data is merged and updated in batches. Using the solution in the foregoing embodiment, the efficiency of the account consolidation update processing can be improved. FIG. 7 shows a schematic diagram of the module structure of another embodiment of the disaster recovery data processing device provided in the specification. As shown in FIG. 7, in another embodiment of this specification, when the first account update module 108 uses an asynchronous method to perform data consolidation and update processing on locked users, the device may also include a first complete accounting module 109 , The first complete billing module 109 may include: a first judging unit, which may be used to merge and update the gateway account data corresponding to the locked user in batch processing, when the disaster tolerance database obtains the first sent by the service requester After the service processing request, determine whether the corresponding user belongs to the general blacklist according to the user information in the second service processing request, and obtain the second judgment result; the first complete accounting unit can be used when the second judgment result is no , Determine the disaster recovery account corresponding to the corresponding user according to the user information in the second service processing request, and perform complete accounting for the transaction in the second service processing request according to the disaster recovery account corresponding to the corresponding user. Correspondingly, after the first account update module 108 has performed the corresponding operation, the second complete accounting module 110 can be further used to perform subsequent operations. It needs to be specially explained that the corresponding first complete accounting module and the second complete accounting module are only distinguished and defined for clearer presentation, and the two can be different modules or the same module. When the two are the same module, they are used to execute different tasks assigned to them in different stages. In another embodiment of this specification, the device may further include: a data migration module, which can be used to perform migration processing on the data in the disaster recovery library according to the accounting status, wherein the accounting status includes gateway accounting and complete Keep accounts. Utilizing the solutions in the above-mentioned embodiments can improve the efficiency and accuracy of processing back migration data. It should be noted that the above-mentioned device may also include other implementation manners according to the description of the method embodiment. For specific implementation manners, reference may be made to the description of the related method embodiments, which will not be repeated here. One or more embodiments of this specification provide a disaster recovery data processing device that can process inbound transaction data by using gateway accounting during the disaster recovery period of the main database, and mark and list the users of the gateway accounting as The gateway is in the blacklist. At the same time, a real blacklist is generated asynchronously, and the real blacklist user can be a pending account generated by the inconsistent data status of the main database and other real-time synchronized databases at the moment when disaster recovery occurs in the main database. When it is determined that the real blacklist is generated, the gateway blacklist and the real blacklist can be merged to obtain the total blacklist. Then, the user accounts in the total blacklist that are not part of the real blacklist are locked, and the account data of the locked users are merged and updated, so as to obtain the complete account information of the locked users. As a result, it can prevent the main library and the disaster recovery library from accounting at the same time after the host crashes, and at the same time, it can also ensure the normal transactions of other accounts except the pending account. The method or device described in the above-mentioned embodiment provided in this specification can realize the business logic through a computer program and be recorded on a storage medium, and the storage medium can be read and executed by a computer to realize the solution described in the embodiment of this specification Effect. Therefore, this specification also provides a disaster-tolerant data processing device, which includes a processor and a memory storing executable instructions of the processor. When the instructions are executed by the processor, the implementation includes the following steps: When the disaster-tolerant database obtains a business request After the first service processing request sent by the party, it is judged whether the type of the first service processing request is an inflow type, and the first judgment result is obtained; if the first judgment result is yes, then according to the first service processing request The user information is used to determine the corresponding gateway account, and the transaction in the first service processing request is accounted for through the gateway according to the gateway account, and the user corresponding to the user information is marked and listed as the gateway black List; Determine the real blacklist generated asynchronously, merge the real blacklist and the gateway blacklist to obtain the total blacklist; lock the users who are not in the real blacklist in the total blacklist, and lock the corresponding gateway account of the user The data is merged and updated, and the disaster recovery account corresponding to the locked user is obtained. The storage medium may include a physical device for storing information, and the information is usually digitized and then stored in an electric, magnetic, or optical medium. The storage media may include: devices that use electrical energy to store information, such as various types of memory, such as RAM, ROM, etc.; devices that use magnetic energy to store information, such as hard disks, floppy disks, magnetic tapes, magnetic core memories Body, bubble memory, U disk; devices that use optical methods to store information, such as CDs or DVDs. Of course, there are other ways of readable storage media, such as quantum memory, graphene memory, and so on. It should be noted that the above-mentioned processing device may also include other implementation manners according to the description of the method embodiment. For specific implementation manners, reference may be made to the description of the related method embodiments, which will not be repeated here. The method embodiments provided in the embodiments of this specification can be executed in a mobile terminal, a computer terminal, a server, or a similar computing device. Taking running on a server as an example, FIG. 8 is a block diagram of the hardware structure of a disaster-tolerant data processing server applying an embodiment of the present invention. As shown in FIG. 8, the server 10 may include one or more (only one is shown in the figure) processor 100 (the processor 100 may include, but is not limited to, a processing device such as a microprocessor MCU or a programmable logic device FPGA. ), a memory 200 for storing data, and a transmission module 300 for communication functions. Those with ordinary knowledge in the technical field to which the present invention pertains can understand that the structure shown in FIG. 8 is only illustrative, and does not limit the structure of the above electronic device. For example, the server 10 may also include more or fewer components than shown in FIG. 8, for example, may also include other processing hardware, such as a database or multi-level cache, GPU, or have different components from those shown in FIG. Configuration. The memory 200 can be used to store software programs and modules of application software, such as program instructions/modules corresponding to the search method in the embodiment of the present invention. The processor 100 runs the software programs and modules stored in the memory 200, In order to perform various functional applications and data processing. The memory 200 may include a high-speed random memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory 200 may further include a memory disposed remotely relative to the processor 100, and these remote storages may be connected to a computer terminal through a network. Examples of the aforementioned networks include but are not limited to the Internet, corporate intranet, local area network, mobile communication network, and combinations thereof. The transmission module 300 is used to receive or send data via a network. The foregoing specific examples of the network may include a wireless network provided by a communication provider of a computer terminal. In one example, the transmission module 300 includes a network interface controller (NIC), which can be connected to other network devices through a base station to communicate with the Internet. In one example, the transmission module 300 may be a radio frequency (RF) module, which is used for wireless communication with the Internet. The disaster recovery data processing equipment described in the above embodiment can process the inbound transaction data by using the gateway accounting method during the disaster recovery period of the main database, and mark the users of the gateway accounting and add them to the gateway blacklist. in. At the same time, a real blacklist is generated asynchronously, and the real blacklist user can be a pending account generated by the inconsistent data status of the main database and other real-time synchronized databases at the moment when disaster recovery occurs in the main database. When it is determined that the real blacklist is generated, the gateway blacklist and the real blacklist can be merged to obtain the total blacklist. Then, the user accounts in the total blacklist that are not part of the real blacklist are locked, and the account data of the locked users are merged and updated, so as to obtain the complete account information of the locked users. As a result, it can prevent the main library and the disaster recovery library from accounting at the same time after the host crashes, and at the same time, it can also ensure the normal transactions of other accounts except the pending account. This specification also provides a disaster-tolerant data processing system, which can be a separate disaster-tolerant data processing system, or it can be applied to a business processing distributed system. The system can be a standalone server, or it can include server clusters, systems (including distributed systems), and software (applications) that use one or more of the methods or one or more of the embodiment devices in this specification. Programs), actual operating devices, logic gate circuit devices, quantum computers, etc., combined with the necessary implementation hardware terminal devices. The disaster-tolerant data processing system may include at least one processor and a memory storing computer-executable instructions. When the processor executes the instructions, the steps of the method described in any one or more of the foregoing embodiments are implemented. It should be noted that the above-mentioned system may also include other implementation manners based on the description of the method or device embodiment. For the specific implementation manner, reference may be made to the description of the relevant method embodiment, which will not be repeated here. The disaster recovery data processing system described in the above embodiment can process the inbound transaction data by using the gateway accounting method during the disaster recovery period of the main database, and mark the users of the gateway accounting and add them to the gateway blacklist. in. At the same time, a real blacklist is generated asynchronously, and the real blacklist user can be a pending account generated by the inconsistent data status of the main database and other real-time synchronized databases at the moment when disaster recovery occurs in the main database. When it is determined that the real blacklist is generated, the gateway blacklist and the real blacklist can be merged to obtain the total blacklist. Then, the user accounts in the total blacklist that are not part of the real blacklist are locked, and the account data of the locked users are merged and updated, so as to obtain the complete account information of the locked users. As a result, it can prevent the main library and the disaster recovery library from accounting at the same time after the host crashes, and at the same time, it can also ensure the normal transactions of other accounts except the pending account. It should be noted that the device or system described above in this specification may also include other implementation manners based on the description of the related method embodiments. For specific implementation manners, refer to the description of the method embodiments, which will not be repeated here. The various embodiments in this specification are described in a gradual manner, and the same or similar parts between the various embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the hardware+programs, storage media+program embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the part of the method embodiments. Although the content of the embodiments of this specification refers to the acquisition, definition, interaction, calculation, judgment and other operations and data descriptions such as gateway accounting, data merging and updating processing, the embodiments of this specification are not limited to the data that must meet the standard. The model/template or the situation described in the examples of this specification. Certain industry standards or implementations described in custom methods or examples with slight modifications can also achieve the same, equivalent or similar implementation effects of the foregoing examples, or predictable implementation effects after modification. The examples obtained by applying these modified or deformed data acquisition, storage, judgment, processing methods, etc., can still fall within the scope of the optional implementation scheme of this specification. The foregoing describes specific embodiments of this specification. Other embodiments are within the scope of the attached patent application. In some cases, the actions or steps described in the scope of the patent application may be performed in a different order from the embodiment and still achieve desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or sequential order shown in order to achieve the desired result. In some embodiments, multiplexing and parallel processing are also possible or may be advantageous. The systems, devices, modules or units explained in the above embodiments may be implemented by computer chips or entities, or implemented by products with certain functions. A typical implementation device is a computer. Specifically, the computer may be, for example, a personal computer, a laptop computer, a vehicle-mounted human-computer interaction device, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, and a game console. , Tablets, wearable devices, or any combination of these devices. For the convenience of description, when describing the above device, the functions are divided into various modules to describe separately. Of course, when implementing one or more of this specification, the functions of each module can be implemented in the same one or more software and/or hardware, or the modules that implement the same function can be composed of multiple sub-modules or sub-units. The combination to achieve and so on. The device embodiments described above are merely illustrative. For example, the division of the units is only a logical function division, and there may be other divisions in actual implementation. For example, multiple units or elements can be combined or integrated into Another system, or some features can be ignored, or not implemented. In addition, the displayed or discussed mutual coupling or direct coupling or communication connection may be indirect coupling or communication connection through some interfaces, devices or units, and may be in electrical, mechanical or other forms. Those with ordinary knowledge in the technical field to which the present invention pertains will also know that in addition to implementing the controller in a purely computer-readable manner, it is entirely possible to design the method steps in a logic program to make the controller use logic gates, switches, and special application products. The same function can be realized in the form of bulk circuit, programmable logic controller and embedded microcontroller. Therefore, such a controller can be regarded as a hardware component, and the devices included in the controller for realizing various functions can also be regarded as a structure within the hardware component. Or even, the device used to implement various functions can be regarded as both a software module for implementing the method and a structure within a hardware component. The present invention is described with reference to flowcharts and/or block diagrams of methods, equipment (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and/or block in the flowchart and/or block diagram, and the combination of processes and/or blocks in the flowchart and/or block diagram can be realized by computer program instructions. These computer program instructions can be provided to the processors of general-purpose computers, special-purpose computers, embedded processors, or other programmable data processing equipment to generate a machine that can be executed by the processor of the computer or other programmable data processing equipment A device for realizing the function specified in one or more processes in the flowchart and/or one or more blocks in the block diagram is generated. These computer program instructions can also be stored in a computer-readable memory that can guide a computer or other programmable data processing equipment to operate in a specific manner, so that the instructions stored in the computer-readable memory generate instructions including the manufacturing of the instruction device The instruction device realizes the function specified in one process or multiple processes in the flowchart and/or one block or multiple blocks in the block diagram. These computer program instructions can also be loaded on a computer or other programmable data processing equipment, so that a series of operation steps are executed on the computer or other programmable equipment to generate computer-implemented processing, so that the computer or other programmable data processing equipment The instructions executed on the device provide steps for implementing functions specified in one process or multiple processes in the flowchart and/or one block or multiple blocks in the block diagram. In a typical configuration, the computing device includes one or more processors (CPU), input/output interfaces, network interfaces, and memory. It should also be noted that the terms "include", "include" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, product or equipment including a series of elements not only includes those elements, but also includes Other elements that are not explicitly listed, or include elements inherent to this process, method, commodity, or equipment. If there are no more restrictions, the element defined by the sentence "including a..." does not exclude the existence of other same elements in the process, method, or device that includes the element. Those with ordinary knowledge in the technical field to which the present invention pertains should understand that one or more embodiments of this specification can be provided as a method, a system or a computer program product. Therefore, one or more embodiments of this specification may adopt the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Moreover, one or more embodiments of this specification can be implemented on one or more computer-usable storage media (including but not limited to magnetic disk memory, CD-ROM, optical memory, etc.) containing computer-usable program codes. In the form of a computer program product. One or more embodiments of this specification may be described in the general context of computer-executable instructions executed by a computer, such as a program module. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. It is also possible to practice one or more embodiments of this specification in a distributed computing environment. In these distributed computing environments, remote processing devices connected through a communication network perform tasks. In a distributed computing environment, program modules can be located in local and remote computer storage media including storage devices. The various embodiments in this specification are described in a gradual manner, and the same or similar parts between the various embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, as for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and for related parts, please refer to the part of the description of the method embodiment. In the description of this specification, descriptions with reference to the terms "one embodiment", "some embodiments", "examples", "specific examples", or "some examples" etc. mean specific features described in conjunction with the embodiment or example , Structure, materials or features are included in at least one embodiment or example in this specification. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the described specific features, structures, materials or characteristics can be combined in any one or more embodiments or examples in a suitable manner. In addition, if there is no contradiction, a person with ordinary knowledge in the technical field to which the present invention belongs can combine and combine the different embodiments or examples and the features of the different embodiments or examples described in this specification. The above descriptions are only examples of this specification, and are not used to limit this specification. For those with ordinary knowledge in the technical field to which the present invention pertains, this specification can have various modifications and changes. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of this specification shall be included in the scope of the patent application of this specification.
