WO2020088072A1 - 一种容灾数据处理方法、装置及系统 - Google Patents

一种容灾数据处理方法、装置及系统 Download PDF

Info

Publication number
WO2020088072A1
WO2020088072A1 PCT/CN2019/103499 CN2019103499W WO2020088072A1 WO 2020088072 A1 WO2020088072 A1 WO 2020088072A1 CN 2019103499 W CN2019103499 W CN 2019103499W WO 2020088072 A1 WO2020088072 A1 WO 2020088072A1
Authority
WO
WIPO (PCT)
Prior art keywords
disaster recovery
blacklist
account
user
gateway
Prior art date
Application number
PCT/CN2019/103499
Other languages
English (en)
French (fr)
Inventor
张亮亮
Original Assignee
阿里巴巴集团控股有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 阿里巴巴集团控股有限公司 filed Critical 阿里巴巴集团控股有限公司
Publication of WO2020088072A1 publication Critical patent/WO2020088072A1/zh

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14Error detection or correction of the data by redundancy in operation
    • G06F11/1402Saving, restoring, recovering or retrying
    • G06F11/1446Point-in-time backing up or restoration of persistent data
    • G06F11/1448Management of the data involved in backup or backup restore
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14Error detection or correction of the data by redundancy in operation
    • G06F11/1402Saving, restoring, recovering or retrying
    • G06F11/1446Point-in-time backing up or restoration of persistent data
    • G06F11/1458Management of the backup or restore process
    • G06F11/1464Management of the backup or restore process for networked environments

Definitions

  • the embodiments of the present specification relate to the technical field of computer data processing, and in particular, to a disaster recovery data processing method, device, and system.
  • a network failure or unexpected termination of the database may cause some or all of the services to be unavailable. It is called a database failover (FO for short) in the industry.
  • the database has a main database and a standby database.
  • the database failover usually occurs on the main database.
  • the main library is unavailable, it takes a certain amount of time to pull up the standby library.
  • account data is usually written to the FO library (or disaster recovery library).
  • the standby database is pulled up or the main database is repaired, the data in the disaster recovery database is written to the main database or the standby database.
  • the instantaneous downtime of the main database may cause the data state of the main database and other real-time synchronized databases to be inconsistent, so that the accurate accounting data of users in the main database during disaster recovery cannot be accurately known, such as The user's accurate balance limits the user's normal transactions and brings a bad experience to the user.
  • the purpose of the embodiments of the present specification is to provide a disaster recovery data processing method, device and system, which can effectively guarantee normal transactions of users during disaster recovery.
  • a disaster recovery data processing method includes:
  • the disaster recovery database After the disaster recovery 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 judgment result;
  • the first judgment result is yes, determine the corresponding gateway account according to the user information in the first business processing request, and perform gateway accounting for the transaction in the first business processing request according to the gateway account, and Mark the user corresponding to the user information and add it to the gateway blacklist;
  • Lock users in the total blacklist that do not belong to the real blacklist and merge and update the gateway account data corresponding to the locked user to obtain the disaster recovery account corresponding to the locked user.
  • a disaster recovery data processing device includes:
  • the business data acquisition module is used to determine whether the type of the first business processing request is an inflow type after the disaster recovery database acquires the first business processing request sent by the business requester, and obtain a first judgment result;
  • the gateway accounting module is used to determine the corresponding gateway account according to the user information in the first service processing request if the first judgment result is yes, and to process the transaction in the first service processing request according to the gateway account Perform gateway accounting and mark the user corresponding to the user information as a gateway blacklist;
  • Blacklist merge module used to determine the real blacklist generated asynchronously, merge the real blacklist with the gateway blacklist to obtain the total blacklist;
  • the account update module is used to lock users in the total blacklist that do not belong to the real blacklist, and merge and update the gateway account data corresponding to the locked user to obtain the disaster recovery account corresponding to the locked user.
  • a disaster recovery data processing device includes a processor and a memory for storing processor-executable instructions. When the instructions are executed by the processor, the implementation includes the following steps:
  • the disaster recovery database After the disaster recovery 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 judgment result;
  • the first judgment result is yes, determine the corresponding gateway account according to the user information in the first business processing request, and perform gateway accounting for the transaction in the first business processing request according to the gateway account, and Mark the user corresponding to the user information and add it to the gateway blacklist;
  • Lock users in the total blacklist that do not belong to the real blacklist and merge and update the gateway account data corresponding to the locked user to obtain the disaster recovery account corresponding to the locked user.
  • a disaster recovery data processing system includes at least one processor and a memory storing computer-executable instructions.
  • processors execute the instructions, the steps of the method described in any one of the embodiments of the present specification are implemented.
  • a disaster recovery data processing method, device, and system provided in one or more embodiments of this specification can use the gateway accounting method to first process the inflow transaction data during the disaster recovery of the main database, and record the gateway accounting users. Mark and add to the gateway blacklist.
  • the real blacklist is generated asynchronously, and the users of the real blacklist can be the pending accounts generated when the data state of the main database and other real-time synchronous databases are inconsistent at the moment of disaster recovery of the main database.
  • the gateway blacklist and the real blacklist can be combined to obtain the total blacklist.
  • the user accounts in the total blacklist that do not belong to the real blacklist are locked, and the account data of the locked user is merged and updated to obtain the complete account information of the locked user. Therefore, it is possible to prevent the main database and the disaster recovery database from simultaneously accounting after the host computer is down, and also to ensure the normal transactions of other accounts except for the pending account.
  • FIG. 1 is a schematic flowchart of an embodiment of a disaster recovery data processing method provided by this specification
  • FIG. 2 is a schematic flowchart of another embodiment of a disaster recovery data processing method provided by this specification.
  • FIG. 3 is a schematic flowchart of another embodiment of a disaster recovery data processing method provided by this specification.
  • FIG. 4 is a schematic diagram of a process flow of disaster recovery data in an embodiment provided by this specification.
  • FIG. 5 is a schematic diagram of a module structure of an embodiment of a disaster recovery data processing device provided in this specification
  • FIG. 6 is a schematic diagram of a module structure of another embodiment of a disaster recovery data processing device provided in this specification.
  • FIG. 7 is a schematic diagram of a module structure of another embodiment of a disaster recovery data processing device provided in this specification.
  • FIG. 8 is a schematic structural diagram of a server according to an exemplary embodiment of the present specification.
  • a network failure or accidental termination of the database may cause some or all services to be unavailable, known in the industry as database failover (disaster tolerance).
  • database failover drug tolerance
  • the database has a main database and a standby database.
  • the database failover usually occurs on the main database.
  • the main library is unavailable, it takes a certain amount of time to pull up the standby library.
  • account data is usually written to the FO library (or disaster recovery library). After the standby database is pulled up or the main database is repaired, the data in the disaster recovery database is written to the main database or the standby database.
  • the instantaneous downtime of the main database may cause the data state of the main database and other real-time synchronized databases to be inconsistent, so that the accurate accounting data of users in the main database during disaster recovery cannot be accurately known, such as The user's accurate balance limits the user's normal transactions and brings a bad experience to the user.
  • the embodiments of the present specification provide a database disaster recovery data processing method.
  • the gateway transaction method is first used to process the incoming transaction data, and the gateway accounting account is marked for parallel Added to the gateway blacklist.
  • the real blacklist is generated asynchronously, and the users of the real blacklist can be the pending accounts generated when the data state of the main database and other real-time synchronous databases are inconsistent at the moment of disaster recovery of the main database.
  • the gateway blacklist and the real blacklist can be combined to obtain the total blacklist.
  • the user accounts in the total blacklist that do not belong to the real blacklist are locked, and the data of the locked user accounts are merged and updated to obtain the complete accounting data of the locked user accounts.
  • the data processing can be transferred to the disaster recovery database to prevent the main database and the disaster recovery database from simultaneously accounting.
  • adopt the gateway accounting method that only allows inflow transactions mark the gateway accounting users and add them to the gateway blacklist.
  • FIG. 1 is a schematic flowchart of an embodiment of a disaster recovery data processing method provided in this specification.
  • 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 part of the combined operation steps based on conventional or no creative labor. Or modular unit.
  • steps or structures where there is no necessary causality in logic 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 of the present specification or the drawings.
  • the method or module structure shown in the embodiments or drawings can be executed sequentially or in parallel (for example, parallel processor or multi-thread processing) Environment, even including distributed processing, server cluster implementation environment).
  • the method may include:
  • gateway accounting may be performed first.
  • the gateway accounting may include a data processing state where only inflows are allowed and outflows are not allowed.
  • disaster recovery database is used for gateway accounting, it can only be used to process inbound transactions, but not for outbound transactions.
  • the inflow transaction usually refers to that for a user account, the flow of funds of the transaction is directed to the user account, and the usual performance is that the user account funds increase.
  • it may include a transaction to charge funds to the Alipay balance, such as a transaction to charge funds to the Alipay balance of account A through a third-party platform such as a bank card, or it may include a Alipay to account A through the Alipay balance of other accounts
  • the balance is filled with funds, etc.
  • the outflow of funds from the user account can be referred to as outflow transactions.
  • the usual performance is the decrease of the user account funds.
  • 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).
  • transaction information such as service type, transaction funds, and user information (such as user ID).
  • the service type may be obtained first, and the service type may include inflow transactions and outflow transactions. Then, it can be judged whether the transaction type is an inflow transaction, and a first judgment result is obtained.
  • the transaction in the first service processing request may be gateway-accounted.
  • the corresponding account in the gateway accounting state may be referred to as a gateway account.
  • a new account with zero balance can be created according to the user information as the gateway account corresponding to the user information. Then, the transaction amount in the first business processing request may be obtained, and the transaction amount may be recorded in the newly created gateway account. Mark the users who are accounted for by the gateway. For example, users who can be marked as gateway blacklists are included in the gateway blacklist.
  • accounts can be identified by user information, such as user ID.
  • user information such as user ID.
  • the user ID corresponding to the user who performs gateway accounting can be marked, and the user ID can be included in the gateway blacklist.
  • the corresponding business 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.
  • the data in the main database and other real-time synchronization databases may have inconsistent states, and pending account data may be generated.
  • This part of the pending accounts may be determined as a true blacklist.
  • the main library receives the inflow transaction information of account C, the user deposits 200 yuan into account C, and the main library performs corresponding accounting.
  • disaster recovery of the main database occurs at this time, and other synchronized databases may have to synchronize data in the future, resulting in inconsistency between the data of the main database account C and other synchronized databases, and the inaccurate balance of account C cannot be determined.
  • the balance of account C is 100 yuan, and after the inflow transaction, the balance of account C should be 300 yuan.
  • the synchronization database did not receive the corresponding data, and the balance of the synchronization database account C was still 100 yuan. If account C wants to perform an outflow transaction of 200 yuan, and the data processing is performed by a synchronous database, it may cause the transaction to fail.
  • other data processing lines different from the gateway accounting can be used at the same time to asynchronously analyze the data of the main database and other real-time synchronization databases to determine pending accounts and obtain a true blacklist List.
  • the method of allowing only inflow transactions and not allowing outflow transactions can prevent the loss of platform funds and also ensure the normal progress of some inflow transactions.
  • the gateway blacklist generated during gateway accounting can be retrieved, and then the real blacklist and the gateway blacklist are merged to obtain the total blacklist.
  • S208 Lock users in the total blacklist that do not belong to the real blacklist, and merge and update the gateway account data corresponding to the locked user to obtain the disaster recovery account corresponding to the locked user.
  • the gateway account of a user who is not part of the real blacklist in the total blacklist may be retrieved, and the transaction processing request of the part of the account may be suspended first. Then, merge and update the gateway account data corresponding to the locked user to obtain the disaster recovery account corresponding to the locked user.
  • the locked user ’s disaster recovery account contains the user ’s complete account information.
  • the user account corresponding to the complete accounting period in the disaster recovery database may be referred to as a disaster recovery account.
  • the gateway account and the disaster recovery account are all user accounts in the disaster recovery database, and can be related to account data in other databases through user information.
  • the two can be different accounts specifically generated for different accounting states; they can also be the same account, just for ease of expression, the names defined in different accounting states are different. In the specific implementation, it can be set according to actual needs, which is not limited here.
  • the latest data records of the locked user before the main database is down can be obtained from the synchronization database such as reading library and tair (cache), and merged with the locked user's gateway account data to merge the locked user's gateway account
  • the data is updated to complete account data to obtain the disaster recovery account corresponding to the locked user.
  • 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 recovery account corresponding to the locked user, the method may further include:
  • S2106 Completely record the transaction in the second service processing request according to the disaster recovery account corresponding to the corresponding user.
  • the service processing request acquired during the gateway accounting period before the determination of the total blacklist may be referred to as the first service processing request, and the complete accounting period after the determination of the total blacklist may be
  • the acquired business processing request is called a second business processing request.
  • 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 a data processing state that allows both inflow and outflow.
  • the disaster recovery database performs complete accounting, it allows both inbound and outbound transactions to be processed.
  • the disaster recovery database After obtaining the complete account data of the locked user, when the disaster recovery database obtains the second service processing request sent by the service requester, it can determine 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 to make the corresponding transaction request.
  • the disaster recovery account corresponding to the corresponding user may 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 business processing request may be fully recorded according to the corresponding disaster recovery account.
  • the locked users all correspond to disaster recovery accounts containing complete accounting data. Therefore, if the business processing request is a business processing request of a locked account, the disaster recovery account of the corresponding user can be determined according to the user information , And can perform normal inflow and outflow transaction processing according to the disaster recovery account. And the corresponding transaction data can be recorded in the corresponding disaster recovery account.
  • a normal user who neither belongs to a pending account nor conducts a transaction during gateway accounting can be referred to as a normal user. It can indicate that the normal user's accounting record data in the other real-time synchronization data of the main database is correct and complete.
  • the corresponding account information may not be generated in the disaster recovery data to ensure the convenience of subsequent data migration.
  • 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 may indicate that the user is performing business processing in the disaster recovery data for the first time. Then, a disaster recovery account with a zero balance can be created in the disaster recovery database, and then the account data of the corresponding user in the database such as the reading library and tair (cache) can be retrieved according to the user information in the second service processing request , Merge into the disaster recovery account corresponding to the corresponding user, and update the accounting data in the disaster recovery account to complete accounting data.
  • the disaster recovery account after the merged update process contains the complete account data of the corresponding user. Then, the transaction in the business processing request can be processed based on the merged and updated disaster recovery account, and recorded in the corresponding disaster recovery account, so as to realize the user's complete bookkeeping.
  • the corresponding disaster recovery account can be determined according to the user information, and the corresponding transaction in the business processing request can be completely recorded based on the disaster recovery account corresponding to the user Account.
  • the determining the disaster recovery account corresponding to the corresponding user according to the user information in the second service processing request may include:
  • the transactions in the second service processing request are fully recorded according to the disaster recovery account after the merge update processing.
  • the solution provided by the above embodiment of this specification can suspend the accounting processing of the main database after the main database fails, and temporarily call the disaster recovery database to process the accounting data to prevent the abnormal accounting processing of the main database from bringing more Account.
  • the gateway accounting process the method of allowing only inflow transactions and not allowing outflow transactions can prevent platform funds loss. Mark the users who are accounted by the gateway and add them to the gateway blacklist.
  • the gateway While the gateway keeps account, it can asynchronously analyze the outstanding accounts generated during the period from the failure of the main database to the start of the disaster recovery database, and generate a true blacklist. After the real blacklist is generated, the gateway blacklist and the real blacklist can be combined to obtain the total blacklist.
  • the account data of users who are not part of the real blacklist in the total blacklist can be combined to obtain the complete account data of the corresponding users.
  • the locked user can use the disaster recovery account that already contains complete accounting data to perform normal accounting processing.
  • you can generate a corresponding disaster recovery account, and retrieve the complete account data from the synchronization database, and use the disaster recovery account that contains the complete account data for normal business processing. Therefore, normal account processing of users other than the real blacklist is realized.
  • users in the total blacklist that are not part of the real blacklist can be retrieved and locked in an asynchronous manner, and the account data of the locked users can be combined and updated in batches.
  • the transaction processing of the locked user may be suspended first, and while other users are being normally accounted, other data processing lines different from the normal account may be used to asynchronously retrieve the list of locked users and put them in the task queue. Then, the data in the locked user list is batch-processed for data merge and update processing, so that the data update processing for the locked user can be efficiently achieved. 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 performing merge update batch processing on the gateway account data corresponding to the locked user, after the disaster recovery database obtains the second service processing request sent by the service requester, determine whether the corresponding user is based on the user information in the second service processing request Belong to the total blacklist, get the second judgment result;
  • S2206 Completely record the transaction in the second service processing request according to the disaster recovery account corresponding to the corresponding user;
  • batch processing can also be performed according to the user information in the second service processing request to determine whether the corresponding user belongs to the total blacklist and obtain the second critical result. If the second judgment result is no, that is, the corresponding user does not belong to the pending account, nor does the transaction take place during the gateway accounting period, the user belongs to the normal user.
  • the disaster recovery account corresponding to the corresponding user may be determined according to the user information in the second service processing request, and the transaction in the second service processing request may be processed according to the disaster recovery account corresponding to the corresponding user Perform complete bookkeeping.
  • a disaster recovery account with a zero balance can be created in the disaster recovery database, and then the account data of the corresponding user in the database such as the reading library and tair (cache) can be retrieved according to the user information in the second service processing request , Merge into the disaster recovery account corresponding to the corresponding user, and update the accounting data in the disaster recovery account to complete accounting data.
  • the disaster recovery account after the merged update process contains the complete account data of the corresponding user.
  • the transaction in the business processing request can be processed based on the merged and updated disaster recovery account, and recorded in the corresponding disaster recovery account, so as to realize the user's complete bookkeeping.
  • the corresponding disaster recovery account can be determined according to the user information, and the corresponding transaction in the business processing request can be completely recorded based on the disaster recovery account corresponding to the user Account.
  • the solution provided by the above embodiment of this specification adopts the asynchronous method to merge and update the accounting data of users who are not in the real blacklist in the general blacklist, and at the same time, normal users outside the general blacklist are in the disaster recovery database Normal account processing is performed. This can further improve the accounting processing capability of the database during disaster recovery.
  • FIG. 4 shows a schematic diagram of disaster recovery data processing in an implementation scenario 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 embodiments of the present specification.
  • the data processing method in the disaster recovery database can be regarded as two different stages: gateway failover stage (corresponding to the gateway accounting state) and complete failover stage (corresponding to the complete accounting state).
  • the main library account table is:
  • Failover library (disaster recovery library) account table: no record.
  • Failover record form no record.
  • the real blacklist can be generated asynchronously, and the disaster recovery database is used for gateway accounting.
  • the disaster recovery database is used for gateway accounting.
  • user A adds 100 yuan to the Alipay balance through the bank card, he can first initialize the failover (disaster recovery database) record as gateway accounting, and initialize a failover account information with zero balance for user A.
  • the account information is called the gateway account. Then, deposit the 100 yuan recharged by user A into the gateway account corresponding to user A, mark user A and save it in the gateway blacklist. then:
  • the main bank account table is:
  • the account table in the Failover library is:
  • the Failover record table is:
  • the disaster recovery database retrieves the real blacklist and the gateway blacklist and merges to obtain the total blacklist. And lock the users who are not in the real blacklist in the total blacklist to obtain locked users.
  • the main bank account table is:
  • the Failover library account table is:
  • user A's disaster recovery account The account of user A's account in the Failover database after consolidation and update may be called user A's disaster recovery account.
  • user A's disaster recovery account can be used to complete accounting for the transaction in the service processing request. For example, if user A spends 100 on the balance, then:
  • the Failover library account table is:
  • the Failover record table is:
  • 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 belong, you can initialize a disaster recovery account with zero balance for user B, and retrieve the latest record data of user B in the library and fair and merge it into user B's disaster recovery account to obtain the merged and updated tolerance of user B Disaster account. at this time:
  • the main bank account table is:
  • the Failover library account table is:
  • the Failover library account table is:
  • the Failover record table is:
  • the service processing request for 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 made inbound transactions under the gateway accounting state, user C's gateway accounting record data can be retained in the disaster recovery database for subsequent data migration and other processing.
  • the data of the disaster recovery database can be moved back.
  • the data in the disaster recovery database may be migrated according to the accounting state, where the accounting state includes gateway accounting and complete accounting.
  • the gateway account balance can only be added to the main or standby database balance. If it is judged that the accounting state is complete accounting, the user data corresponding to the complete accounting can be relocated as a whole. This can improve the efficiency and accuracy of the data migration process.
  • a disaster recovery data processing method can process the inbound transaction data by using the gateway accounting method during the disaster recovery of the main database, and mark the users accounted by the gateway in parallel Added to the gateway blacklist.
  • the real blacklist is generated asynchronously, and the users of the real blacklist can be the pending accounts generated when the data state of the main database and other real-time synchronous databases are inconsistent at the moment of disaster recovery of the main database.
  • the gateway blacklist and the real blacklist can be combined to obtain the total blacklist.
  • the user accounts in the total blacklist that do not belong to the real blacklist are locked, and the account data of the locked user is merged and updated to obtain the complete account information of the locked user. Therefore, it is possible to prevent the main database and the disaster recovery database from simultaneously accounting after the host computer is down, and also to ensure the normal transactions of other accounts except for the pending account.
  • one or more embodiments of this specification further provide a disaster recovery data processing device.
  • the device may include a system, software (application), module, component, server, etc. using the method described in the embodiments of the present specification, combined with necessary hardware implementation devices.
  • the devices in one or more embodiments provided by the embodiments of this specification are as described in the following embodiments. Since the implementation solution of the device to solve the problem is similar to the method, the implementation of the specific device in the embodiments of the present specification may refer to the implementation of the foregoing method, and the repetition is not repeated.
  • the term "unit” or "module” may implement a combination of software and / or hardware that achieves a predetermined function.
  • FIG. 5 shows a schematic diagram of a module structure of an embodiment of a disaster recovery data processing device provided in the specification. As shown in FIG. 5, the device may include:
  • the business data acquisition module 102 may be used to determine whether the type of the first business processing request is an inflow type after the disaster recovery database acquires the first business processing request sent by the business requester, and obtain the first judgment result;
  • the gateway accounting module 104 may be used to determine the corresponding gateway account according to the user information in the first service processing request if the first judgment result is yes, and to process the first service processing request according to the gateway account The transaction in is accounted by the gateway, and the user corresponding to the user information is marked and added to the gateway blacklist;
  • the blacklist merge 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 may be used to lock users in the total blacklist that do not belong to the real blacklist, perform merge update processing on the gateway account data corresponding to the locked user, and obtain a disaster recovery account corresponding to the locked user.
  • FIG. 6 shows a schematic block diagram of another embodiment of the disaster recovery data processing apparatus provided in the specification.
  • the apparatus 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 business processing request after the disaster recovery database obtains the second business processing request sent by the business requester, to obtain a third judgment result;
  • the second complete accounting unit can be used to determine the disaster recovery account corresponding to the corresponding user according to the user information in the second service processing request when the third judgment result is negative, and based on the disaster recovery account corresponding to the corresponding user Complete accounting for the transaction in the second service processing request.
  • the second complete accounting unit may include:
  • the account update subunit may be used to generate a disaster recovery account according to the user information in the second business processing request when the user information in the second business processing request does not match the corresponding disaster recovery account, and The data of the disaster recovery account is merged and updated;
  • the complete accounting subunit may be used to perform complete accounting of the transaction in the second service processing request according to the disaster recovery account after the merge update processing.
  • the account processing capability of the database during disaster recovery can be guaranteed to the greatest extent.
  • the account update module 108 may include:
  • the account update unit can be used to retrieve and lock users in the total blacklist that do not belong to the real blacklist in an asynchronous manner, and perform batch update and merge processing on the gateway account data corresponding to the locked users.
  • FIG. 7 shows a schematic block diagram of another embodiment of the disaster recovery data processing apparatus provided in the specification.
  • the device may further include a first complete accounting module 109.
  • the first complete accounting module 109 may include:
  • the first judgment unit may be used to perform batch update processing on the merged and updated gateway account data corresponding to the locked user, when the disaster recovery database obtains the second service processing request sent by the service requester, according to the second service processing request
  • the user information judges whether the corresponding user belongs to the total blacklist, and obtains the second judgment result
  • the first complete accounting unit may be used to determine the disaster recovery account corresponding to the corresponding user according to the user information in the second service processing request when the second judgment result is negative, and based on the disaster recovery account corresponding to the corresponding user Complete accounting for the transaction in the second service processing request.
  • the second complete accounting module 110 may be further used for subsequent operations.
  • first complete accounting module and the second complete accounting module are only for distinguishing and defining more clearly, and the two may be different modules or the same module. When the two are the same module, they are used to perform different tasks assigned at different stages.
  • the device may further include:
  • the data migration module can be used to perform migration processing on the data in the disaster recovery database according to the accounting state, where the accounting state includes gateway accounting and complete accounting.
  • a disaster recovery data processing device can process the inbound transaction data by using the gateway accounting method during the disaster recovery of the main database, and mark the users accounted by the gateway in parallel Added to the gateway blacklist.
  • the real blacklist is generated asynchronously, and the users of the real blacklist can be the pending accounts generated when the data state of the main database and other real-time synchronous databases are inconsistent at the moment of disaster recovery of the main database.
  • the gateway blacklist and the real blacklist can be combined to obtain the total blacklist.
  • the user accounts in the total blacklist that do not belong to the real blacklist are locked, and the account data of the locked user is merged and updated to obtain the complete account information of the locked user. Therefore, it is possible to prevent the main database and the disaster recovery database from simultaneously accounting after the host computer is down, and also to ensure the normal transactions of other accounts except for the pending account.
  • this specification also provides a disaster recovery data processing device, which includes a processor and a memory that stores processor executable instructions, and when the instructions are executed by the processor, the implementation includes the following steps:
  • the disaster recovery database After the disaster recovery 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 judgment result;
  • the first judgment result is yes, determine the corresponding gateway account according to the user information in the first business processing request, and perform gateway accounting for the transaction in the first business processing request according to the gateway account, and Mark the user corresponding to the user information and add it to the gateway blacklist;
  • Lock users in the total blacklist that do not belong to the real blacklist and merge and update the gateway account data corresponding to the locked user to obtain the disaster recovery account corresponding to the locked user.
  • the storage medium may include a physical device for storing information, usually after the information is digitized and then stored in a medium using electrical, magnetic, or optical means.
  • the storage medium 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, and bubble memories, U disk; a device that uses optical means to store information such as CD or DVD.
  • 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, and bubble memories, U disk
  • a device that uses optical means to store information such as CD or DVD.
  • quantum memory graphene memory, and so on.
  • FIG. 8 is a block diagram of a hardware structure of a disaster recovery data processing server to which an embodiment of the present invention is applied.
  • 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.
  • 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
  • a transmission module 300 for communication functions.
  • the server 10 may further include more or fewer components than those shown in FIG. 8, and may also include other processing hardware, such as a database or a multi-level cache, a GPU, or have a configuration different from that shown in FIG. 8.
  • the memory 200 may 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, and the processor 100 executes various functions by running the software programs and modules stored in the memory 200 Application and data processing.
  • the memory 200 may include a high-speed random access 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.
  • the memory 200 may further include memories remotely provided with respect to the processor 100, and these remote memories may be connected to a computer terminal through a network. Examples of the above network include but are not limited to the Internet, 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 specific example of the network described above may include a wireless network provided by a communication provider of computer terminals.
  • the transmission module 300 includes a network adapter (Network Interface Controller, NIC), which can be connected to other network devices through the base station to communicate with the Internet.
  • the transmission module 300 may be a radio frequency (RF) module, which is used to communicate with the Internet in a wireless manner.
  • RF radio frequency
  • the disaster recovery data processing device described in the above embodiment can process the inbound transaction data by using the gateway accounting method during the disaster recovery of the main database, and mark the user accounted by the gateway as a gateway black In the list.
  • the real blacklist is generated asynchronously, and the users of the real blacklist can have pending accounts generated at the moment when the disaster recovery of the main database occurs and the data status of the main database and other real-time synchronous databases are not consistent.
  • the gateway blacklist and the real blacklist can be combined to obtain the total blacklist.
  • the user accounts in the total blacklist that do not belong to the real blacklist are locked, and the account data of the locked user is merged and updated to obtain the complete account information of the locked user. Therefore, it is possible to prevent the main database and the disaster recovery database from simultaneously accounting after the host computer is down, and also to ensure the normal transactions of other accounts except for the pending account.
  • the system may be a separate disaster recovery data processing system, or may be applied in a business processing distributed system.
  • the system may be a separate server, or it may include a server cluster, system (including distributed system), software (application) using one or more of the methods or one or more embodiments of this specification. Terminal devices that actually operate devices, logic gate devices, quantum computers, etc., combined with the necessary implementation hardware.
  • the disaster recovery data processing system may include at least one processor and a memory that stores computer-executable instructions. When the processor executes the instructions, the steps of the method in any one or more of the foregoing embodiments are implemented.
  • the disaster recovery data processing system described in the above embodiment can process the incoming transaction data by using the gateway accounting method during the disaster recovery of the main database, and mark the users accounted by the gateway as gateway black In the list.
  • the real blacklist is generated asynchronously, and the users of the real blacklist can be the pending accounts generated when the data state of the main database and other real-time synchronous databases are inconsistent at the moment of disaster recovery of the main database.
  • the gateway blacklist and the real blacklist can be combined to obtain the total blacklist.
  • the user accounts in the total blacklist that do not belong to the real blacklist are locked, and the account data of the locked user is merged and updated to obtain the complete account information of the locked user. Therefore, it is possible to prevent the main database and the disaster recovery database from simultaneously accounting after the host computer is down, and also to ensure the normal transactions of other accounts except for the pending account.
  • the system, device, module or unit explained in the above embodiments may be specifically implemented by a computer chip or entity, or implemented by a product with a certain function.
  • a typical implementation device is a computer.
  • the computer may be, for example, a personal computer, a laptop computer, an on-board human-machine interaction device, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet A computer, a wearable device, or any combination of these devices.
  • the functions are divided into various modules and described separately.
  • the functions of each module may be implemented in the same or more software and / or hardware, or the modules that achieve the same function may be implemented by a combination of multiple submodules or subunits, etc. .
  • the device embodiments described above are only schematic.
  • the division of the unit is only a division of logical functions.
  • there may be another division manner for example, multiple units or components may be combined or integrated To another system, or some features can be ignored, or not implemented.
  • 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.
  • controller in addition to implementing the controller in the form of pure computer-readable program code, it is entirely possible to logically program method steps to make the controller use logic gates, switches, application specific integrated circuits, programmable logic controllers and embedded The same function is realized in the form of a microcontroller or the like. Therefore, such a controller can be regarded as a hardware component, and the devices included therein for realizing various functions can also be regarded as structures within the hardware component. Or even, the means for realizing various functions can be regarded as both a software module of an implementation method and a structure within a hardware component.
  • These computer program instructions can be provided to the processor of a general-purpose computer, special-purpose computer, embedded processing machine, or other programmable data processing device to produce a machine that enables the generation of instructions executed by the processor of the computer or other programmable data processing device
  • These computer program instructions may also be stored in a computer-readable memory that can guide a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture including an instruction device, the instructions The device implements the functions specified in one block or multiple blocks of the flowchart one flow or multiple flows and / or block diagrams.
  • These computer program instructions can also be loaded onto a computer or other programmable data processing device, so that a series of operating steps are performed on the computer or other programmable device to produce computer-implemented processing, which is executed on the computer or other programmable device
  • the instructions provide steps for implementing the functions specified in one block or multiple blocks of the flowchart one flow or multiple flows and / or block diagrams.
  • the computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.
  • processors CPUs
  • input / output interfaces output interfaces
  • network interfaces network interfaces
  • memory volatile and non-volatile memory
  • one or more embodiments of this specification may be provided as a method, system, or computer program product. Therefore, one or more embodiments of this specification may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Moreover, one or more embodiments of this specification may employ computer programs implemented on one or more computer usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer usable program code The form of the product.
  • computer usable storage media including but not limited to disk storage, CD-ROM, optical storage, etc.
  • One or more embodiments of this specification may be described in the general context of computer-executable instructions executed by a computer, such as program modules.
  • program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types.
  • One or more embodiments of this specification can also be practiced in distributed computing environments in which tasks are performed by remote processing devices connected through a communication network.
  • program modules may be located in local and remote computer storage media including storage devices.

Abstract

本说明书实施例公开了一种容灾数据处理方法、装置及系统,所述方法包括当容灾数据库获取业务请求方发送的第一业务处理请求后,判断所述第一业务处理请求的类型是否为流入类,获得第一判断结果;若第一判断结果为是,则根据所述第一业务处理请求中的用户信息确定对应的网关账户,以及根据所述网关账户对所述第一业务处理请求中的交易进行网关记账,并将对应的用户列入网关黑名单;确定异步生成的真实黑名单,将真实黑名单与网关黑名单进行合并获得总黑名单;对总黑名单中不属于真实黑名单的用户进行锁定,并对锁定用户对应的网关账户数据进行合并更新处理。利用本说明书各个实施例,可以实现在容灾期间对除真实黑名单之外的用户账户的正常交易。

Description

一种容灾数据处理方法、装置及系统 技术领域
本说明书实施例涉及计算机数据处理技术领域,特别地,涉及一种容灾数据处理方法、装置及系统。
背景技术
数据库发生网络故障或者意外终止,可能会导致部分或者全部服务不可用,业内称为数据库failover(简称FO,容灾)。一般数据库有会主库和备库,数据库failover通常发生在主库上。当主库不可用后,拉起备库需要一定时间,在这段时间内,为了保障业务进行,账户数据通常会写入FO库(或称容灾库)。在备库被拉起或者主库被修复后,再将容灾库中数据写入主库或备库中。
但利用容灾库进行账务数据处理时,因主库宕机瞬间,可能导致主库和其他实时同步数据库数据状态不一致,从而无法准确知晓容灾期间主库中用户的准确账务数据,例如用户的准确余额,限制了用户的正常交易,给用户带来不好的体验。同时流程切换过程中还可能会出现部分分布式服务器状态不一致,而导致主库、容灾库存在同时记账的风险。
发明内容
本说明书实施例的目的是提供一种容灾数据处理方法、装置及系统,可以有效的保证容灾期间用户的正常交易。
为实现上述目的,本说明书是通过包括以下实施例实现的:
一种容灾数据处理方法,所述方法包括:
当容灾数据库获取业务请求方发送的第一业务处理请求后,判断所述第一业务处理请求的类型是否为流入类,获得第一判断结果;
若第一判断结果为是,则根据所述第一业务处理请求中的用户信息确定对应的网关账户,以及根据所述网关账户对所述第一业务处理请求中的交易进行网关记账,并 将所述用户信息对应的用户打标后列入网关黑名单;
确定异步生成的真实黑名单,将真实黑名单与网关黑名单进行合并获得总黑名单;
对总黑名单中不属于真实黑名单的用户进行锁定,对锁定用户对应的网关账户数据进行合并更新处理,获得锁定用户对应的容灾账户。
一种容灾数据处理装置,所述装置包括:
业务数据获取模块,用于当容灾数据库获取业务请求方发送的第一业务处理请求后,判断所述第一业务处理请求的类型是否为流入类,获得第一判断结果;
网关记账模块,用于若第一判断结果为是,则根据所述第一业务处理请求中的用户信息确定对应的网关账户,根据所述网关账户对所述第一业务处理请求中的交易进行网关记账,并将所述用户信息对应的用户打标后列入网关黑名单;
黑名单合并模块,用于确定异步生成的真实黑名单,将真实黑名单与网关黑名单进行合并获得总黑名单;
账户更新模块,用于对总黑名单中不属于真实黑名单的用户进行锁定,对锁定用户对应的网关账户数据进行合并更新处理,获得锁定用户对应的容灾账户。
一种容灾数据处理设备,包括处理器及用于存储处理器可执行指令的存储器,所述指令被所述处理器执行时实现包括以下步骤:
当容灾数据库获取业务请求方发送的第一业务处理请求后,判断所述第一业务处理请求的类型是否为流入类,获得第一判断结果;
若第一判断结果为是,则根据所述第一业务处理请求中的用户信息确定对应的网关账户,以及根据所述网关账户对所述第一业务处理请求中的交易进行网关记账,并将所述用户信息对应的用户打标后列入网关黑名单;
确定异步生成的真实黑名单,将真实黑名单与网关黑名单进行合并获得总黑名单;
对总黑名单中不属于真实黑名单的用户进行锁定,对锁定用户对应的网关账户数据进行合并更新处理,获得锁定用户对应的容灾账户。
一种容灾数据处理系统,包括至少一个处理器以及存储计算机可执行指令的存储器,所述处理器执行所述指令时实现本说明书任意一个实施例所述方法的步骤。
本说明书一个或多个实施例提供的一种容灾数据处理方法、装置及系统,可以通过在主库容灾期间,先利用网关记账方式对流入类交易数据进行处理,将网关记账的用户打标并列入为网关黑名单中。同时异步生成真实黑名单,所述真实黑名单用户可以为主库发生容灾的瞬间,主库和其他实时同步数据库数据状态不一致而产生的未决账户。当确定生成真实黑名单后,则可以先将网关黑名单与真实黑名单合并获得总黑名单。然后,对总黑名单中不属于真实黑名单的用户账户进行锁定,并对锁定用户的账户数据进行合并更新处理,从而获得锁定用户的完整账户信息。从而,可以防止主机出现宕机后主库、容灾库同时记账的同时,还可以保证除未决账户之外的其他账户的正常交易。
附图说明
为了更清楚地说明本说明书实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本说明书中记载的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动性的前提下,还可以根据这些附图获得其他的附图。在附图中:
图1为本说明书提供的一种容灾数据处理方法实施例的流程示意图;
图2为本说明书提供的另一种容灾数据处理方法实施例的流程示意图;
图3为本说明书提供的另一种容灾数据处理方法实施例的流程示意图;
图4为本说明书提供的一个实施例中容灾数据处理流程示意图;
图5为本说明书提供的一种容灾数据处理装置实施例的模块结构示意图;
图6为本说明书提供的另一种容灾数据处理装置实施例的模块结构示意图;
图7为本说明书提供的另一种容灾数据处理装置实施例的模块结构示意图;
图8是根据本说明书的一个示例性实施例的服务器的示意结构图。
具体实施方式
为了使本技术领域的人员更好地理解本说明书中的技术方案,下面将结合本说明书一个或多个实施例中的附图,对本说明书一个或多个实施例中的技术方案进行清楚、 完整地描述,显然,所描述的实施例仅是说明书一部分实施例,而不是全部的实施例。基于说明书一个或多个实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都应当属于本说明书实施例方案保护的范围。
数据库发生网络故障或者意外终止,可能会导致部分或者全部服务不可用,业内称为数据库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元,主库账号表为:
账号 余额
A 100
Failover库(容灾库)账号表:无记录。
Failover记录表:无记录。
主库宕机后,可以异步生成真实黑名单,同时容灾数据库进行网关记账。此时,若用户A通过银行卡向支付宝余额中充值100元,可以先初始化failover(容灾库)记录为网关记账,并对用户A初始化一个余额为零的failover账户信息,可以将此failover账户信息称之为网关账户。然后,将用户A充值的100元存入用户A对应的网关账户,并对用户A进行打标并存入网关黑名单列表中。则:
主库账号表为:
账号 余额
A 100
Failover库中账号表为:
账号 余额
A 100
Failover记录表为:
账号 记账状态
A 网关记账
当异步判断生成真实黑名单后,容灾数据库捞取真实黑名单与网关黑名单,合并获得总黑名单。并将总黑名单中不属于真实黑名单的用户进行锁定,获得锁定用户。
然后,异步结合读库、fair数据对用户A在Failover库中账号进行合并更新, 更新后:
主库账号表为:
账号 余额
A 100
Failover库账号表为:
账号 余额
A 200
可以将用户A在Failover库中账号进行合并更新后的账户称之为用户A的容灾账户。此后,若再接收到用户A业务处理请求,则可以利用用户A的容灾账户对业务处理请求中的交易进行完整记账。如,若用户A使用余额支出100,则:
Failover库账号表为:
账号 余额
A 100
Failover记录表为:
账号 记账状态
A 完整记账
假设用户B在总黑名单生成前,未进行网关记账,其主机账户余额为300元。总黑名单生成之后,容灾数据库接收到用户B的业务处理请求,可以先判断用户B是否属于总黑名单。若不属于,则可以为用户B初始化一个余额为零的容灾账户,并捞取用户B在读库、fair中的最新记录数据合并至用户B的容灾账户中,获得用户B合并更新后的容灾账户。此时:
主库账号表为:
账号 余额
B 300
Failover库账号表为:
账号 余额
B 300
若接收到的业务处理请求中的交易信息为用户B使用余额支出100,利用用户B合并更新后的容灾账户对该交易正常处理后,则:
Failover库账号表为:
账号 余额
B 200
Failover记录表为:
账号 记账状态
B 完整记账
相应的,假设真实黑名单生成之后,若判断用户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、光学存储器等)上实施的计算机程序产品的形式。
本说明书一个或多个实施例可以在由计算机执行的计算机可执行指令的一般上下文中描述,例如程序模块。一般地,程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本本说明书一个或多个实施例,在这些分布式计算环境中,由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中,程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于系统实施例而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。在本说明书的描述中,参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本说明书的至少一个实施例或示例中。在本说明书中,对上述术语的示意性表述并不必须针对的是相同的实施例或示例。而且,描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外,在不相互矛盾的情况下,本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。
以上所述仅为本说明书的实施例而已,并不用于限制本说明书。对于本领域技术人员来说,本说明书可以有各种更改和变化。凡在本说明书的精神和原理之内所作的任何修改、等同替换、改进等,均应包含在本说明书的权利要求范围之内。

Claims (14)

  1. 一种容灾数据处理方法,所述方法包括:
    当容灾数据库获取业务请求方发送的第一业务处理请求后,判断所述第一业务处理请求的类型是否为流入类,获得第一判断结果;
    若第一判断结果为是,则根据所述第一业务处理请求中的用户信息确定对应的网关账户,以及根据所述网关账户对所述第一业务处理请求中的交易进行网关记账,并将所述用户信息对应的用户打标后列入网关黑名单;
    确定异步生成的真实黑名单,将真实黑名单与网关黑名单进行合并获得总黑名单;
    对总黑名单中不属于真实黑名单的用户进行锁定,对锁定用户对应的网关账户数据进行合并更新处理,获得锁定用户对应的容灾账户。
  2. 根据权利要求1所述的容灾数据处理方法,所述对总黑名单中不属于真实黑名单的用户进行锁定,对锁定用户对应的网关账户数据进行合并更新处理,包括:
    采用异步方式捞取总黑名单中不属于真实黑名单的用户并进行锁定,对锁定用户对应的网关账户数据进行合并更新批处理。
  3. 根据权利要求2所述的容灾数据处理方法,所述方法还包括:
    对锁定用户对应的网关账户数据进行合并更新批处理时,当容灾数据库获取业务请求方发送的第二业务处理请求后,根据所述第二业务处理请求中的用户信息判断相应用户是否属于总黑名单,获得第二判断结果;
    第二判断结果为否时,根据所述第二业务处理请求中的用户信息确定相应用户对应的容灾账户;
    根据所述相应用户对应的容灾账户对所述第二业务处理请求中的交易进行完整记账。
  4. 根据权利要求1-3任一项所述的容灾数据处理方法,所述获得锁定用户对应的容灾账户之后,还包括:
    当容灾数据库获取业务请求方发送的第二业务处理请求后,根据所述第二业务处理请求中的用户信息判断相应用户是否属于真实黑名单,获得第三判断结果;
    第三判断结果为否时,根据所述第二业务处理请求中的用户信息确定相应用户对应的容灾账户;
    根据所述相应用户对应的容灾账户对所述第二业务处理请求中的交易进行完整记账。
  5. 根据权利要求4所述的容灾数据处理方法,所述根据所述第二业务处理请求中的用户信息确定相应用户对应的容灾账户,包括:
    当根据所述第二业务处理请求中的用户信息未匹配到对应的容灾账户时,根据所述第二业务处理请求中的用户信息生成容灾账户,并对该容灾账户的数据进行合并更新处理;
    相应的,根据合并更新处理后的容灾账户对所述第二业务处理请求中的交易进行完整记账。
  6. 根据权利要求5中所述的容灾数据处理方法,所述方法还包括:
    根据记账状态对容灾库中的数据进行回迁处理,其中,所述记账状态包括网关记账以及完整记账。
  7. 一种容灾数据处理装置,所述装置包括:
    业务数据获取模块,用于当容灾数据库获取业务请求方发送的第一业务处理请求后,判断所述第一业务处理请求的类型是否为流入类,获得第一判断结果;
    网关记账模块,用于若第一判断结果为是,则根据所述第一业务处理请求中的用户信息确定对应的网关账户,根据所述网关账户对所述第一业务处理请求中的交易进行网关记账,并将所述用户信息对应的用户打标后列入网关黑名单;
    黑名单合并模块,用于确定异步生成的真实黑名单,将真实黑名单与网关黑名单进行合并获得总黑名单;
    账户更新模块,用于对总黑名单中不属于真实黑名单的用户进行锁定,对锁定用户对应的网关账户数据进行合并更新处理,获得锁定用户对应的容灾账户。
  8. 根据权利要求7所述的容灾数据处理装置,所述账户更新模块包括:
    账户更新单元,用于采用异步方式捞取总黑名单中不属于真实黑名单的用户并进行锁定,对锁定用户对应的网关账户数据进行合并更新批处理。
  9. 根据权利要求8所述的容灾数据处理装置,所述装置还包括第一完整记账模块,所述第一完整记账模块包括:
    第一判断单元,用于对锁定用户对应的网关账户数据进行合并更新批处理时,当容灾数据库获取业务请求方发送的第二业务处理请求后,根据所述第二业务处理请求中的用户信息判断相应用户是否属于总黑名单,获得第二判断结果;
    第一完整记账单元,用于第二判断结果为否时,根据所述第二业务处理请求中的用户信息确定相应用户对应的容灾账户,以及根据所述相应用户对应的容灾账户对所述第二业务处理请求中的交易进行完整记账。
  10. 根据权利要求7-9任一项所述的容灾数据处理装置,所述装置还包括第二完整记账模块,所述第二完整记账模块包括:
    第二判断单元,用于当容灾数据库获取业务请求方发送的第二业务处理请求后,根据所述第二业务处理请求中的用户信息判断相应用户是否属于真实黑名单,获得第三判断结果;
    第二完整记账单元,用于第三判断结果为否时,根据所述第二业务处理请求中的用户信息确定相应用户对应的容灾账户,以及根据所述相应用户对应的容灾账户对所述第二业务处理请求中的交易进行完整记账。
  11. 根据权利要求10所述的容灾数据处理装置,所述第二完整记账单元包括:
    账户更新子单元,用于当根据所述第二业务处理请求中的用户信息未匹配到对应的容灾账户时,根据所述第二业务处理请求中的用户信息生成容灾账户,并对该容灾账户的数据进行合并更新处理;
    完整记账子单元,用于根据合并更新处理后的容灾账户对所述第二业务处理请求中的交易进行完整记账。
  12. 根据权利要求11所述的容灾数据处理装置,所述装置还包括:
    数据回迁模块,用于根据记账状态对容灾库中的数据进行回迁处理,其中,所述记账状态包括网关记账以及完整记账。
  13. 一种容灾数据处理设备,包括处理器及用于存储处理器可执行指令的存储器,所述指令被所述处理器执行时实现包括以下步骤:
    当容灾数据库获取业务请求方发送的第一业务处理请求后,判断所述第一业务处理请求的类型是否为流入类,获得第一判断结果;
    若第一判断结果为是,则根据所述第一业务处理请求中的用户信息确定对应的网关账户,以及根据所述网关账户对所述第一业务处理请求中的交易进行网关记账,并将所述用户信息对应的用户打标后列入网关黑名单;
    确定异步生成的真实黑名单,将真实黑名单与网关黑名单进行合并获得总黑名单;
    对总黑名单中不属于真实黑名单的用户进行锁定,对锁定用户对应的网关账户数据进行合并更新处理,获得锁定用户对应的容灾账户。
  14. 一种容灾数据处理系统,包括至少一个处理器以及存储计算机可执行指令的存储器,所述处理器执行所述指令时实现权利要求1-6中任意一项所述方法的步骤。
PCT/CN2019/103499 2018-10-29 2019-08-30 一种容灾数据处理方法、装置及系统 WO2020088072A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201811266866.1 2018-10-29
CN201811266866.1A CN109614263B (zh) 2018-10-29 2018-10-29 一种容灾数据处理方法、装置及系统

Publications (1)

Publication Number Publication Date
WO2020088072A1 true WO2020088072A1 (zh) 2020-05-07

Family

ID=66002217

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/103499 WO2020088072A1 (zh) 2018-10-29 2019-08-30 一种容灾数据处理方法、装置及系统

Country Status (3)

Country Link
CN (1) CN109614263B (zh)
TW (1) TWI712879B (zh)
WO (1) WO2020088072A1 (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109614263B (zh) * 2018-10-29 2020-07-03 阿里巴巴集团控股有限公司 一种容灾数据处理方法、装置及系统
CN110232565B (zh) * 2019-05-20 2023-09-05 平安银行股份有限公司 资源清算方法、装置、计算机设备和存储介质
CN112084200A (zh) * 2020-08-24 2020-12-15 中国银联股份有限公司 数据读写处理方法、数据中心、容灾系统及存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120209807A1 (en) * 2009-10-20 2012-08-16 Zte Corporation Method and apparatus for data disaster tolerance preprocessing, and service control point
CN102891849A (zh) * 2012-09-25 2013-01-23 北京星网锐捷网络技术有限公司 业务数据同步方法、恢复方法及装置和网络设备
CN105574020A (zh) * 2014-10-14 2016-05-11 阿里巴巴集团控股有限公司 一种数据库操作方法和装置
CN107153649A (zh) * 2016-03-02 2017-09-12 阿里巴巴集团控股有限公司 一种数据备份方法及装置
CN109614263A (zh) * 2018-10-29 2019-04-12 阿里巴巴集团控股有限公司 一种容灾数据处理方法、装置及系统

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8504526B2 (en) * 2010-06-04 2013-08-06 Commvault Systems, Inc. Failover systems and methods for performing backup operations
CN102110161A (zh) * 2011-02-24 2011-06-29 中兴通讯股份有限公司 备份、恢复多业务数据库的方法及装置
CN103064860A (zh) * 2011-10-21 2013-04-24 阿里巴巴集团控股有限公司 数据库高可用实现方法及其装置
CN103870357A (zh) * 2012-12-17 2014-06-18 中国移动通信集团河南有限公司 一种进行数据复制的方法及系统
CN105677675B (zh) * 2014-11-20 2019-08-27 阿里巴巴集团控股有限公司 业务处理方法及装置
US10084845B2 (en) * 2015-09-14 2018-09-25 Uber Technologies, Inc. Data restoration for datacenter failover
CN106910121A (zh) * 2015-12-23 2017-06-30 阿里巴巴集团控股有限公司 生成账务记录方法及装置
CN107784748B (zh) * 2016-08-24 2020-02-07 深圳市图灵奇点智能科技有限公司 一种基于分布式记账的自助收费终端
CN107577700B (zh) * 2017-07-26 2020-11-10 创新先进技术有限公司 数据库容灾的处理方法及装置

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120209807A1 (en) * 2009-10-20 2012-08-16 Zte Corporation Method and apparatus for data disaster tolerance preprocessing, and service control point
CN102891849A (zh) * 2012-09-25 2013-01-23 北京星网锐捷网络技术有限公司 业务数据同步方法、恢复方法及装置和网络设备
CN105574020A (zh) * 2014-10-14 2016-05-11 阿里巴巴集团控股有限公司 一种数据库操作方法和装置
CN107153649A (zh) * 2016-03-02 2017-09-12 阿里巴巴集团控股有限公司 一种数据备份方法及装置
CN109614263A (zh) * 2018-10-29 2019-04-12 阿里巴巴集团控股有限公司 一种容灾数据处理方法、装置及系统

Also Published As

Publication number Publication date
TW202016737A (zh) 2020-05-01
CN109614263A (zh) 2019-04-12
CN109614263B (zh) 2020-07-03
TWI712879B (zh) 2020-12-11

Similar Documents

Publication Publication Date Title
WO2020088072A1 (zh) 一种容灾数据处理方法、装置及系统
WO2018177235A1 (zh) 一种区块链共识方法及装置
CN107464151B (zh) 高并发业务的订单数据处理方法及装置
WO2020186901A1 (zh) 基于区块链的数据核对系统、方法、计算设备及存储介质
KR101959153B1 (ko) 데이터베이스에서의 계좌와 관련된 거래 요청의 효율적인 처리를 위한 시스템
TW201822033A (zh) 資源處理方法及裝置
CN109670784B (zh) 一种告知等待时间的方法、装置及系统
CN110032598B (zh) 字段更新方法及装置、电子设备
TW201941086A (zh) 一種資料快取方法、裝置及系統
WO2019242357A1 (zh) 基于信用担保的业务处理方法、装置以及设备
CN107392582B (zh) 资源转移的实现方法和装置、收付款的实现方法和装置
CN108874912A (zh) 一种销户方法和服务器
WO2019033741A1 (zh) 投资产品的资源处理方法、装置、存储介质和计算机设备
WO2021008400A1 (zh) 基于区块链的数据批量处理方法、装置、设备及存储介质
WO2023279970A1 (zh) 基于区块链的数据同步的方法和装置
TW201727517A (zh) 資料儲存與業務處理的方法及裝置
TW201802739A (zh) 發票抬頭資訊變更方法、裝置和發票管理系統
CN108459910A (zh) 一种删除资源的方法及设备
CN108563693A (zh) 一种事务的处理方法、装置及设备
US20200175502A1 (en) Confidential transaction in a blockchain network
CN112613964A (zh) 一种对账方法、装置、设备及存储介质
CN110381150B (zh) 区块链上的数据处理方法、装置、电子设备及存储介质
TWI662486B (zh) 檢查分布式業務處理完整度的方法及裝置
CN110046877B (zh) 对账方法和装置、服务器
CN113971007B (zh) 信息处理方法、装置、电子设备及介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19878252

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19878252

Country of ref document: EP

Kind code of ref document: A1