Transaction data disaster recovery switching method, device, computing equipment, and storage medium

Abstract

This application discloses a transaction data disaster recovery switching method, apparatus, computing device, and storage medium, relating to the field of financial technology. The method, which is applicable to a disaster recovery server in a first transaction system that forms a disaster recovery backup relationship with a second transaction system, comprises: receiving a user verification request sent by a first transaction server in the first transaction system; the user verification request is determined by the first transaction server based on a pending user transaction request; the user verification request carries a user identifier in the user transaction request; determining a user verification result for the user verification request based on a first transaction record in a first primary database of the first transaction system with the user identifier and a second transaction record in a disaster recovery database of the first transaction system with the user identifier; feeding back the user verification result to the first transaction server; and the user verification result is used to indicate whether the first transaction server processes the user transaction request. This method avoids economic losses caused by duplicate transactions.

Description

Technical Field

[0001] The present application relates to the field of financial technology, and in particular to a transaction data disaster recovery switching method, apparatus, computing equipment, and storage medium. Background Art

[0002] Typically, when conducting financial transactions at location A, transaction data needs to be synchronized remotely to ensure that, in the event of a data disaster at location A, the data in the backup database at location B can be used to ensure the smooth execution of the financial transaction.

[0003] like Figure 1 As shown in the figure, the data ratio scheme provided by the related technology is shown. In this figure, the financial transaction system in the Internet Data Center (IDC) in location A can read and write data from the main database in location A for financial transactions. At the same time, when the data is written to the main database, the data will also be synchronized to each backup database ( Figure 1 Only backup database 1 and backup database 2 are used for schematic description); the data in the backup database at location A will be asynchronously copied to the primary database at location B. At the same time, the data in the primary database at location B will also be synchronized to the backup database at location B.

[0004] However, due to the long distance between locations A and B, the low network bandwidth and long latency, and the heavy load on the backup database at location A, data synchronization is delayed. If the IDC at location A fails, user traffic will be directly switched to location B to process transaction data before the data is fully synchronized to location B. Data that has already been traded at location A may be processed again, which can easily cause economic losses. For example, if a user makes a transfer transaction at location A and the IDC at location A fails, the database of the IDC at location B has not yet synchronized the data that the user has successfully transferred. Re-executing the transfer transaction will obviously cause economic losses.

[0005] In order to avoid the problem of duplicate transactions when user traffic is switched to location B, the present application provides a transaction data disaster recovery switching method to solve the above problem. Summary of the Invention

[0006] The present application provides a transaction data disaster recovery switching method, apparatus, computing equipment, and storage medium, which are used to avoid the problem of duplicate transactions when user traffic is switched to a disaster recovery site during disaster recovery.

[0007] In a first aspect, an embodiment of the present application provides a transaction data disaster recovery switching method, which is applicable to a disaster recovery server in a first transaction system that forms a disaster recovery backup relationship with a second transaction system, including: receiving a user verification request sent by a first transaction server in the first transaction system; the user verification request is determined by the first transaction server based on the user transaction request to be processed; the user verification request carries a user identifier in the user transaction request; determining a user verification result of the user verification request based on a first transaction record of the user identifier in a first primary database of the first transaction system and a second transaction record of the user identifier in a disaster recovery database of the first transaction system; the transaction records in the second primary database of the second transaction system are asynchronously backed up in the first primary database; the transaction records in the second primary database are consistent with the transaction records in the disaster recovery database; feeding back the user verification result to the first transaction server; the user verification result is used to indicate whether the first transaction server processes the user transaction request.

[0008] In this way, when the transaction data is processed by the first transaction server, the disaster recovery server checks the data in the disaster recovery database and the first main database, and determines whether to execute the transaction request based on the user's verification results. This method avoids the occurrence of duplicate transactions while ensuring the economic interests of users.

[0009] In an optional embodiment, the disaster recovery server determines the user verification result of the user verification request based on the first transaction record of the user identifier in the first primary database of the first transaction system and the second transaction record of the user identifier in the disaster recovery database of the first transaction system, including:

[0010] Determine whether the user identifier is included in the gray list record; the gray list record is obtained when the first transaction record and the second transaction record are inconsistent; when the user identifier is included in the gray list record, determine that the user verification result is verification failure, and the verification failure is used to instruct the first transaction server to process the user transaction request; when the user identifier is not included in the gray list record, determine that the user verification result is verification success, and the verification success is used to instruct the first transaction server not to process the user transaction request.

[0011] In this solution, whether to execute the user's transaction request is determined based on whether the user's identifier is in the gray list record. In this way, it is possible to accurately determine when to process the user's transaction request.

[0012] In an optional embodiment, the user verification result is used to instruct the first transaction server not to process the user transaction request; the method further includes:

[0013] The disaster recovery server updates the first transaction record according to the second transaction record, so that the transaction record of the user identifier in the disaster recovery database is consistent with the transaction record of the user identifier in the first primary database.

[0014] In this solution, when the user verification result indicates that the user transaction request will not be processed, the first transaction record will be updated through the second transaction record so that the user transaction request can be executed.

[0015] In an optional embodiment, the method further includes: deleting the user identifier from the grey list record.

[0016] When it is determined that the second transaction record corresponding to the user identifier has updated the first transaction record, the user identifier may be deleted to save storage resources.

[0017] In a second aspect, an embodiment of the present application provides a transaction data disaster recovery switching method, which is applicable to a first transaction server in a first transaction system that forms a disaster recovery backup relationship with a second transaction system, and includes: after receiving a user transaction request to be processed, sending a user verification request to the disaster recovery server; the user verification request carries the user identifier in the user transaction request; receiving a user verification result of the user verification request fed back by the disaster recovery server, and determining whether to process the user transaction request based on the user verification result; wherein, the user verification result is determined by the disaster recovery server in the first transaction system based on a first transaction record of the user identifier in a first primary database of the first transaction system and a second transaction record of the user identifier in the disaster recovery database of the first transaction system; the transaction records in the second primary database of the second transaction system are asynchronously backed up in the first primary database; the transaction records in the second primary database are consistent with the transaction records in the disaster recovery database.

[0018] In this way, when the transaction data is processed by the first transaction server, the disaster recovery server checks the data in the disaster recovery database and the first main database, and determines whether to execute the transaction request based on the user's verification results. This method avoids the occurrence of duplicate transactions while ensuring the economic interests of users.

[0019] In an optional embodiment, the method further includes:

[0020] The pending user transaction request is obtained from the message cluster; wherein the pending user transaction request is sent by the data distribution center of the first transaction system through the message cluster of the first transaction system.

[0021] This solution processes pending user transaction requests through message clustering, which can ensure that user transaction requests are consumed in sequence, avoiding the situation where there are too many user transaction requests and the user transaction request processing is chaotic. This method can improve the processing efficiency of user transaction requests.

[0022] In an optional embodiment, determining whether to process the user transaction request according to the user verification result includes:

[0023] If the user verification result is that the verification is passed, the first transaction server processes the user transaction request; if the user verification result is that the verification is failed, the first transaction server stops processing the user transaction request.

[0024] In this method, whether to execute the user transaction request is determined based on the user's verification results, which can avoid the occurrence of duplicate transactions.

[0025] In a third aspect, an embodiment of the present application provides a transaction data disaster recovery switching device, the device being applicable to a disaster recovery server in a first transaction system that forms a disaster recovery backup relationship with a second transaction system, comprising:

[0026] a receiving module, configured to receive a user verification request sent by a first transaction server in the first transaction system; the user verification request is determined by the first transaction server based on a pending user transaction request; the user verification request carries a user identifier in the user transaction request;

[0027] a determination module, configured to determine a user verification result of the user verification request based on a first transaction record of the user identifier in a first primary database of the first transaction system and a second transaction record of the user identifier in a disaster recovery database of the first transaction system; the transaction records in the second primary database of the second transaction system are asynchronously backed up in the first primary database; and the transaction records in the second primary database are consistent with the transaction records in the disaster recovery database;

[0028] A feedback module is used to feed back the user verification result to the first transaction server; the user verification result is used to indicate to the first transaction server whether to process the user transaction request.

[0029] In this way, when the transaction data is processed by the first transaction server, the disaster recovery server checks the data in the disaster recovery database and the first main database, and determines whether to execute the transaction request based on the user's verification results. This method avoids the occurrence of duplicate transactions while ensuring the economic interests of users.

[0030] In an optional embodiment, the determining module is specifically configured to:

[0031] determining whether the user identifier is included in a gray list record; the gray list record is obtained when the first transaction record and the second transaction record are inconsistent;

[0032] When the user identifier is included in the gray list record, determining that the user verification result is verification failure, the verification failure is used to instruct the first transaction server not to process the user transaction request;

[0033] When the gray list record does not include the user identifier, the user verification result is determined to be verification passed, and the verification passed is used to instruct the first transaction server to process the user transaction request.

[0034] In this solution, whether to execute the user's transaction request is determined based on whether the user's identifier is in the gray list record. In this way, it is possible to accurately determine when to process the user's transaction request.

[0035] In an optional embodiment, the user verification result is used to instruct the first transaction server not to process the user transaction request; the apparatus further includes:

[0036] An updating module is configured to update the first transaction record according to the second transaction record, so that the transaction record of the user identifier in the disaster recovery database is consistent with the transaction record of the user identifier in the first primary database.

[0037] In this solution, when the user verification result indicates that the user transaction request will not be processed, the first transaction record will be updated through the second transaction record so that the user transaction request can be executed.

[0038] In an optional embodiment, the device further comprises:

[0039] The deletion module is used to delete the user identifier from the grey list record.

[0040] When it is determined that the second transaction record corresponding to the user identifier has updated the first transaction record, the user identifier may be deleted to save storage resources.

[0041] In a fourth aspect, an embodiment of the present application provides a transaction data disaster recovery switching device, which is applicable to a first transaction server in a first transaction system that forms a disaster recovery backup relationship with a second transaction system, including:

[0042] The sending module is used to send a user verification request to the disaster recovery server after receiving the user transaction request to be processed; the user verification request carries the user identifier in the user transaction request;

[0043] A determination module is used to receive the user verification result of the user verification request fed back by the disaster recovery server, and determine whether to process the user transaction request based on the user verification result; wherein, the user verification result is determined by the disaster recovery server in the first transaction system based on the first transaction record of the user identifier in the first primary database of the first transaction system and the second transaction record of the user identifier in the disaster recovery database of the first transaction system; the transaction records in the second primary database of the second transaction system are asynchronously backed up in the first primary database; the transaction records in the second primary database are consistent with the transaction records in the disaster recovery database.

[0044] In this way, when the transaction data is processed by the first transaction server, the disaster recovery server checks the data in the disaster recovery database and the first main database, and determines whether to execute the transaction request based on the user's verification results. This method avoids the occurrence of duplicate transactions while ensuring the economic interests of users.

[0045] In an optional embodiment, the device further includes:

[0046] The acquisition module is configured to acquire the pending user transaction request from the message cluster; wherein the pending user transaction request is sent by the data distribution center of the first transaction system through the message cluster of the first transaction system.

[0047] This solution processes pending user transaction requests through message clustering, which allows user transaction requests to be consumed in sequence and avoids the situation where backup user transaction requests are confused when there are too many user transaction requests. This method can improve the processing efficiency of user transaction requests.

[0048] In an optional embodiment, the determining module is specifically configured to:

[0049] If the user verification result is passed, the first transaction server processes the user transaction request;

[0050] If the user verification result is failure, the first transaction server stops processing the user transaction request.

[0051] In this method, whether to execute the user transaction request is determined based on the user's verification results, which can avoid the occurrence of duplicate transactions.

[0052] In a fifth aspect, an embodiment of the present application further provides a computing device, including:

[0053] Memory and processor;

[0054] a memory for storing program instructions;

[0055] The processor is configured to call the program instructions stored in the memory and implement the transaction data disaster recovery switching method according to any one of the first aspects of the obtained program instructions.

[0056] In a sixth aspect, an embodiment of the present application further provides a computer storage medium, wherein the computer storage medium stores computer-executable instructions, and the computer-executable instructions are used to enable a computer to execute any transaction data disaster recovery switching method in the embodiment of the present application.

[0057] Other features and advantages of the present application will be described in the following description, and in part will become apparent from the description, or will be understood by practicing the present application. The purpose and other advantages of the present application can be realized and obtained by the structures particularly pointed out in the written description, claims, and drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0058] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the following briefly introduces the drawings required for use in the embodiments of the present invention. Obviously, the drawings introduced below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0059] Figure 1 This is a schematic diagram of a scenario of transaction data disaster recovery switching in related technologies;

[0060] Figure 2A A schematic diagram of a transaction data backup scenario provided in an embodiment of the present application;

[0061] Figure 2B A schematic diagram of a transaction data disaster recovery switching scenario provided in an embodiment of the present application;

[0062] Figure 3 A flowchart of a transaction data backup method provided in an embodiment of the present application;

[0063] Figure 4 A flowchart of a transaction data backup method provided in an embodiment of the present application;

[0064] Figure 5A schematic diagram of a transaction data backup scenario provided in an embodiment of the present application;

[0065] Figure 6 A flowchart of a transaction data disaster recovery switching method provided in an embodiment of the present application;

[0066] Figure 7 A flowchart of a transaction data disaster recovery switching method provided in an embodiment of the present application;

[0067] Figure 8 A schematic diagram of a transaction data disaster recovery switching scenario provided in an embodiment of the present application;

[0068] Figure 9 A schematic diagram of the structure of a transaction data disaster recovery switching device provided in an embodiment of the present application;

[0069] Figure 10 A schematic diagram of the structure of a transaction data disaster recovery switching device provided in an embodiment of the present application;

[0070] Figure 11 A schematic diagram of the structure of a computing device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0071] To make the objectives, technical solutions and advantages of the embodiments of the present invention more clear, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention.

[0072] It should be noted that the terms "first," "second," and the like in this application are used to distinguish similar objects and are not necessarily used to describe a specific order or precedence. It should be understood that the terms used in this manner are interchangeable where appropriate, so that the embodiments of the present disclosure described herein can be implemented in an order other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Instead, they are merely examples of devices and methods consistent with certain aspects of this application, as detailed in the appended claims.

[0073] As described in the background technology, in related technologies, backing up data at location A requires asynchronously transferring the data to the primary database at location B through the backup database at location A. Once a disaster occurs at location A (i.e., a natural disaster such as a typhoon, earthquake, mudslide, or heavy rain makes it impossible for location A to provide normal transaction services), the primary database at location B needs to be called to process the data to handle transactions at location A. However, if the data in the primary database at location B does not fully back up the transaction data at location A, directly processing transactions at location A may result in economic losses. Based on this, an embodiment of the present application provides a transaction data disaster recovery switching method.

[0074] The transaction data backup process is described in detail below. In the following embodiments of the present application, "and / or" describes the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can represent: the existence of A alone, the existence of A and B at the same time, and the existence of B alone, where A and B can be singular or plural. The character " / " generally indicates that the objects associated before and after are in an "or" relationship. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, c can be single or multiple. The singular expressions "one", "a kind of", "said", "above", "the" and "this" are intended to also include expressions such as "one or more", unless there is a clear indication to the contrary in the context. Furthermore, unless otherwise indicated, ordinal numbers such as "first" and "second" in the embodiments of this application are used to distinguish between multiple objects and are not used to define the order, sequence, priority, or importance of the multiple objects. For example, the first vehicle and the second vehicle are only used to distinguish between different vehicles and do not indicate a difference in priority or importance between the two vehicles.

[0075] References to "one embodiment" or "some embodiments" in this specification mean that a particular feature, structure, or characteristic described in conjunction with that embodiment is included in one or more embodiments of the present application. Thus, phrases such as "in one embodiment," "in some embodiments," "in other embodiments," and "in other embodiments" appearing in various places in this specification do not necessarily refer to the same embodiment, but rather mean "one or more but not all embodiments," unless otherwise specifically emphasized. The terms "including," "comprising," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized.

[0076] In order to better illustrate the solution of this application, the terms used in this application are explained as follows:

[0077] The second transaction system is an operating system that processes transaction data before disaster recovery in a certain place. This system can be used to handle financial transaction services such as user transfers and user deposits.

[0078] The first trading system is a trading system that forms a disaster recovery backup relationship with the second trading system and is not located in the same geographical location as the second trading system. It has the same function as the second trading system and can also process various financial transaction services.

[0079] The disaster recovery server is a server located at the location of the first trading system, used for real-time synchronization of transaction data currently processed by the second trading system, and is a disaster recovery server in the first trading system that forms a disaster recovery backup relationship with the second trading system.

[0080] The first transaction server is the server at the location of the first transaction system. When disaster recovery occurs at the location of the second transaction system, the first transaction server is started to process the transaction data at the location of the second transaction system. When disaster recovery does not occur at the location of the second transaction system, the first transaction server is not started to process the transaction data at the location of the second transaction system.

[0081] The second transaction server is a server at the location of the second transaction system, and is used to process transaction data of users at the location of the second transaction system.

[0082] Figure 2A A schematic diagram of an application scenario for transaction data backup provided by an embodiment of the present application is shown. The scenario is applied to disaster recovery in a certain location. The application scenario includes a first transaction system 1, a second transaction system 2, a first transaction server 11, a first primary database 12, a disaster recovery server 13, a disaster recovery database 14, a second transaction server 21, a second primary database 22, and a second backup database 23. The second transaction system 2 also includes other backup databases, which are only illustrated in the figure and not identified by serial numbers. The first transaction system 1 also includes backup databases, which are only illustrated in the figure and not identified by serial numbers. When a failure occurs at the location of the second transaction system 2, the first transaction server 11 of the first transaction system 1 is started to provide transaction services.

[0083] In actual application, before applying the transaction data disaster recovery switching solution of this application, multiple backups have been made for the transaction data currently to be processed by the second transaction server 21 of the second transaction system 2. This application only illustrates one backup. For example, if the second transaction system 2 is located at place A, the transaction data currently to be processed at place A can be backed up at multiple places such as place B, place C, and place D. This application does not limit the specific number of backups and the specific geographical location at which the backup is performed. All transaction data backup methods that apply this application are applicable.

[0084] For transaction data backup, please refer to the following description:

[0085] The first transaction server 11, first primary database 12, disaster recovery server 13, and disaster recovery database 14 correspond to the first transaction system 1, while the second transaction server 21, second primary database 22, and second backup database 23 correspond to the second transaction system 2. Users conduct financial transactions through the second transaction server 21, which processes the currently processed transaction data and stores it in the second primary database 22 of the second transaction system 2. For example, if user B transfers 2 million yuan to user C at 1:00 PM on March 20, 2020, and the second transaction server 21 processes the data, it will determine that user B's account balance is 500,000 yuan. Therefore, the transfer of 2 million yuan from user B to user C at 1:00 PM on March 20, 2020, and the account balance of 500,000 yuan, will be stored in the second primary database 22. Furthermore, the transaction data in the second primary database 22 is asynchronously transferred to the first primary database 12 via the second backup database 23 of the second transaction system 2.

[0086] At the same time, the second transaction server 21 also sends the currently processed transaction data to the disaster recovery server 13, and stores the currently processed transaction data in the disaster recovery database 14, such as: the transaction record of user B transferring 2 million yuan to user C at 13:00 on March 20, 2020 is stored in the disaster recovery server 20.

[0087] If the currently processed transaction data cannot be stored in the second primary database 22 and / or the disaster recovery database 14, a transaction failure message is sent to cause the second transaction server 21 to roll back the previously processed transaction data. Any of the following reasons, such as the disaster recovery database being full, the disaster recovery database failing, the second database being full, and the second database failing, which cause the currently processed transaction data to fail to be stored in the disaster recovery database and / or the second primary database, are applicable to the present application. If the second primary database 22 is full and the currently processed transaction data cannot be stored in the second primary database 22, the transaction data to be processed by the second transaction server 21 is rolled back until the second primary database 22 meets the storage requirements before data storage continues. If the disaster recovery database 14 is full and the currently processed transaction data cannot be stored in the disaster recovery database 14, the second transaction server 21 rolls back the transaction data to be processed until the disaster recovery database 14 meets the storage requirements before data storage continues.

[0088] Refer to later Figure 2BThe first transaction server 11 receives the transaction request of the user to be processed and sends a user verification request to the disaster recovery server 13. The disaster recovery server 13 determines the user verification result of the user verification request based on the first transaction record of the user identifier in the first primary database 12 in the first transaction system 1 and the second transaction record of the user identifier in the disaster recovery database 14 in the first transaction system 1. The disaster recovery server 13 feeds back the user verification result to the first transaction server 11, and the first transaction server 11 determines whether to process the user transaction request based on the user verification result.

[0089] During execution, the transaction data in the disaster recovery database 14 is stored in the corresponding transaction data table. The disaster recovery server 13 compares the transaction data for the same user ID in the disaster recovery database 14 with the transaction data in the first master data 12. If they are inconsistent, the user ID is placed in the gray list record of the disaster recovery database 14, and the transaction request corresponding to the user ID is rejected. If they are consistent, the transaction request corresponding to the user ID is executed.

[0090] In addition, if the request corresponding to the user ID is rejected, the transaction data corresponding to the user ID in the first master data 12 will be updated according to the transaction data corresponding to the user ID recorded in the disaster recovery database 14, and the user ID will be deleted from the gray list record.

[0091] In this way, when the transaction data is processed by the first transaction server, the disaster recovery server checks the data in the disaster recovery database and the first main database, and determines whether to execute the transaction request based on the user's verification results. This method avoids the occurrence of duplicate transactions while ensuring the economic interests of users.

[0092] Next, we will introduce the transaction data backup method from the perspective of the disaster recovery server. Figure 3 In the flowchart shown, the disaster recovery server may first execute step 301, and upon determining that the second trading system meets the disaster recovery conditions, obtain the transaction data currently to be processed by the second trading server of the second trading system; wherein the second trading server is used to process the transaction data to be processed and store it in the second primary database of the second trading system; the transaction data in the second primary database is asynchronously backed up in the first primary database of the first trading system.

[0093] Step 302: Store the transaction data to be processed into the disaster recovery database of the first transaction system; wherein the disaster recovery database is used to update the first primary database.

[0094] In one embodiment, the disaster recovery server compares the transaction data in the disaster recovery database with the transaction data in the first primary database; if it is determined that the transaction data in the disaster recovery database is inconsistent with the transaction data in the first primary database, the transaction data in the first primary database is updated based on the transaction data in the disaster recovery database.

[0095] For example, the disaster recovery server queries the primary transaction flow number of the customer in the first master database based on the customer number (5008) and puts it into the primary transaction flow set 1; at the same time, it queries the transaction data of the primary transaction flow of the customer in the disaster recovery database and puts it into the primary transaction flow set 2; then, based on the primary transaction flow number, the data in the primary transaction flow set 1 and the data in the primary transaction flow set 2 are compared. If the comparison results are inconsistent, the disaster recovery server will write the customer (5008) into the gray list table of the disaster recovery database and update the transaction data in the first master database based on the transaction data in the disaster recovery database; if the comparison results are consistent, the disaster recovery server will not update the data in the gray list table of the disaster recovery database. The disaster recovery server compares the transaction data in the disaster recovery database and the first master database to prevent the asynchronous replication delay of the data in the first master database due to the system switch when the second transaction system needs to switch to the first transaction system for transaction processing in the event of a major natural disaster or emergency, thereby preventing the problem of transaction duplication.

[0096] Step 303: After the pending transaction data is not successfully stored in the disaster recovery database, a transaction failure message is sent to the second transaction server. The transaction failure message is used to instruct the second transaction server to roll back the pending transaction data.

[0097] Accordingly, the second transaction server may refer to Figure 4 , executing step 401, when the disaster recovery condition is met, sending the transaction data currently to be processed by the second transaction server of the second transaction system to the disaster recovery server of the first transaction system; wherein the first transaction system and the second transaction system form a disaster recovery backup relationship.

[0098] Step 402 : Process the pending transaction data and store them in a second primary database of the second transaction system; the transaction data in the second primary database is asynchronously backed up in the first primary database of the first transaction system.

[0099] Step 403: After receiving the transaction failure message sent by the disaster recovery server, roll back the pending transaction data; wherein, the transaction failure message is sent by the disaster recovery server to the second transaction server after the pending transaction data is not successfully stored in the disaster recovery database; the disaster recovery database is used to update the first primary database.

[0100] The disaster recovery server obtains the pending transaction data of the second transaction server, and when the disaster recovery server fails to successfully store the pending transaction data in the disaster recovery database, it instructs the second transaction server to roll back the pending transaction data, thereby achieving zero-delay synchronization of transaction data. The transaction data backed up in this way is not affected by distance, bandwidth delay, and the load capacity of the backup database in the production environment, making the synchronization of transaction data more accurate.

[0101] If there is a large amount of transaction data to be processed, the transaction data can be sent through the message cluster via the data distribution center of the second transaction system to avoid a large amount of transaction data being transmitted to the second primary database and the disaster recovery database at the same time, causing backup confusion.

[0102] During specific implementation, the disaster recovery server can obtain the transaction data currently to be processed by the second transaction system through the first message cluster; the second transaction system can obtain the transaction data currently to be processed by the second transaction system through the second message cluster; the information in the first message cluster and the second message cluster is sent through the data distribution center of the second transaction system.

[0103] For example, a user requests financial transaction services from the location of the second transaction system. After receiving the transaction request from the user, the data distribution center of the second transaction system sends the message to both the first message cluster and the second message cluster. The first message cluster and the second message cluster can be RocketMQ message clusters. For example, the message information sent to the first message cluster and the second message cluster may include key transaction information such as a service identity document (ID) (120001), a scenario ID (02), a customer account number (K10000000000203), a counterparty account number (10800101204002010000013), a globally unique transaction serial number (1702201K102067000000000000021448), an initiating channel code (WB), and a transaction amount (50000). The second transaction server may consume messages in the second cluster according to a topic (service ID + scenario ID) registered in the second message cluster, process the data, and write it to the second master database. Assuming that the user performs a transfer transaction, after writing the key information of the transfer time, transfer account, and transfer amount into the second master database, the second transaction server may also calculate the user's account balance after the transfer and write the account balance into the second master database. At the same time, the disaster recovery server consumes the messages in the first message cluster according to the topic (service ID + scenario ID) registered in the first message cluster, processes and records the customer's key transaction information (such as customer account, globally unique transaction serial number, initiation channel code, transaction amount, etc.) to the disaster recovery database, and completes the data backup of key transactions; assuming that the user executes a transfer transaction, the key information of the transfer time, transfer account and transfer amount can be written into the disaster recovery database.

[0104] For the application scenario diagram of consuming the currently pending transaction data based on the message cluster, please refer to Figure 5 , Figure 5 It is shown that this scenario is used to provide an early warning of a possible disaster in a certain place, and the transaction data needs to be backed up. The application scenario includes a first transaction system 1, a second transaction system 2, a first transaction server 11, a first primary database 12, a disaster recovery server 13, a disaster recovery database 14, a first message cluster 15, a second transaction server 21, a second primary database 22, a second backup database 23, a second data distribution center 24, and a second message cluster 25. Among them, the first transaction server 11, the first primary database 12, the disaster recovery server 13, the disaster recovery database 14, and the first message cluster 15 correspond to the first transaction system 1, and the second transaction server 21, the second primary database 22, the second backup database 23, the second data distribution center 24, and the second message cluster 25 correspond to the second transaction system 2. The backup method of transaction data is similar to Figure 2AThe application scenario shown is consistent with that shown in FIG. 1 , and will not be described in detail here. It is only explained that the second data distribution center 24 distributes the currently processed transaction data through the message cluster as follows:

[0105] After receiving the user transaction request, the second data distribution center 24 sends the user transaction request message information to the first message cluster 15 and the second message cluster 25, including key transaction information such as the service ID, scenario ID, customer account number, counterparty account number, globally unique transaction serial number, initiation channel code, and transaction amount. Based on this information, the second transaction server 21 consumes the message from the second message cluster 25 through the topic, processes the message, and stores it in the second primary database 22. The disaster recovery server 13 consumes the message from the first message cluster through the topic and stores it in the disaster recovery database 14.

[0106] When the transaction data has been backed up, the following describes the transaction data disaster recovery switching method from the perspective of the disaster recovery server. Figure 6 As shown in the flowchart, the disaster recovery server may first execute step 601 to receive a user verification request sent by the first transaction server in the first transaction system; the user verification request is determined by the first transaction server based on the user transaction request to be processed; the user verification request carries the user identifier in the user transaction request.

[0107] It should be noted that users will send transaction requests to the first transaction server, and the first transaction server will process these transaction requests to generate user verification requests, and send these user verification requests carrying user identification to the disaster recovery server for verification. For example: User A sends a transaction request to the first transaction server to transfer 1 million yuan to User B. The first transaction server generates a user verification request based on the request and sends it to the disaster recovery server. It can be sent to verify whether User A has performed the transfer operation, or whether User A's account balance supports the transfer operation, etc. Any method that can be used to identify and verify user transaction requests can be used as a user verification request.

[0108] In addition, the user verification request also carries the user identifier in the user transaction request. For example, if User A wants to perform a transfer operation, the user identifier can be an identifier used to represent the identity of User A. It can be identified by numbers, letters, and other forms, which are not specifically limited here.

[0109] Step 602: Determine the user verification result of the user verification request based on the first transaction record of the user identifier in the first primary database of the first transaction system and the second transaction record of the user identifier in the disaster recovery database of the first transaction system; the transaction records in the second primary database of the second transaction system are asynchronously backed up in the first primary database; the transaction records in the second primary database are consistent with the transaction records in the disaster recovery database.

[0110] It should be noted that the disaster recovery server can verify whether the data of the same user ID in the first primary database and the disaster recovery database are consistent based on user needs at irregular intervals, such as from 12:00 pm to 6:00 am when there are few user transaction requests, or certain specified time periods. If they are inconsistent, they will be placed in the gray list record to determine whether to execute the transaction request corresponding to the user ID.

[0111] Alternatively, after the user sends a transaction request, the disaster recovery server checks whether the data in the first primary database and the disaster recovery database are consistent. If inconsistency is found, the transaction record is placed in the gray list record and feedback is given to suspend the user's transaction request.

[0112] In one embodiment, when the first transaction record and the second transaction record are inconsistent, the transaction record corresponding to the user identifier is recorded in a graylist record. To better determine the user verification result, the disaster recovery server may first determine whether the graylist record contains the user identifier. If the graylist record contains the user identifier, the user verification result is determined to be a failure, where the failure indicates that the first transaction server will not process the user's transaction request. If the graylist record does not contain the user identifier, the user verification result is determined to be a success, where the success indicates that the first transaction server will process the user's transaction request.

[0113] It should be noted that the first transaction record in the first primary database is compared with the second transaction record in the disaster recovery database, and inconsistent transaction records under the same user ID are added to the disaster recovery database's graylist. For example, the disaster recovery server queries the customer's primary transaction flow number in the first primary database based on the customer ID (50080) (i.e., the user ID) and places it in primary transaction flow set 1. Simultaneously, the disaster recovery server queries the customer's primary transaction flow number in the disaster recovery database based on the customer ID (50080) and places it in primary transaction flow set 2. Then, the data in the main transaction flow set 1 and the main transaction flow set 2 are compared according to the main transaction flow number; if the comparison results are inconsistent, it can be seen that the asynchronous replication of the data in the first master data is delayed, resulting in the transaction data of the (50080) customer not being replicated after the system switch, then the disaster recovery server writes the customer number (50080) into the gray list record of the disaster recovery database. Since the gray list record includes the customer number, it is determined that the user verification result fails and the user transaction request is refused to be processed; if the comparison results are consistent, there is no need to write the customer number (50080) into the gray list record of the disaster recovery database, and it is determined that the user verification result passes and the user transaction request can be processed.

[0114] Step 603: Feedback the user verification result to the first transaction server; the user verification result is used to indicate whether the first transaction server processes the user transaction request.

[0115] In one embodiment, when the user verification result indicates that the first transaction server should not process the user's transaction request, the first transaction record can be updated based on the second transaction record, thereby ensuring that the transaction record for the user ID in the disaster recovery database is consistent with the transaction record for the user ID in the first primary database. After the update, the user ID can be deleted from the graylist record. This approach ensures the smooth processing of the user's transaction request. Deleting the user ID from the graylist record also frees up unnecessary storage resources and conserves storage space.

[0116] Accordingly, the first transaction server may refer to Figure 7 The method shown executes step 701, and after receiving the user transaction request to be processed, sends a user verification request to the disaster recovery server; the user verification request carries the user identifier in the user transaction request.

[0117] Step 702: Receive the user verification result of the user verification request fed back by the disaster recovery server, and determine whether to process the user transaction request based on the user verification result; wherein, the user verification result is determined by the disaster recovery server in the first transaction system based on the first transaction record of the user ID in the first master database of the first transaction system and the second transaction record of the user ID in the disaster recovery database of the first transaction system; the transaction record in the second master database of the second transaction system is asynchronously backed up in the first master database; the transaction record in the second master database is consistent with the transaction record in the disaster recovery database.

[0118] In one embodiment, if the user verification result is that the verification is passed, the first transaction server processes the user transaction request; if the user verification result is that the verification is failed, the first transaction server stops processing the user transaction request.

[0119] In this method, whether to execute the user transaction request is determined based on the user's verification results, which can avoid the occurrence of duplicate transactions.

[0120] In one embodiment, to prevent excessive user transfer transaction requests from causing confusion in the first transaction server's processing, pending user transaction requests are retrieved from the message queue to ensure they are processed in order. The pending user transaction requests are sent by the first transaction system's data distribution center via the first transaction system's message cluster.

[0121] The following example illustrates a specific implementation: A user in the second trading system's location who wishes to conduct a financial transaction switches back to the first trading server of the first trading system to process the transaction request. The user sends the transaction request, which is received by the first trading system through the data distribution center. The data distribution center then sends the transaction request to a message cluster, such as a RocketMQ cluster. The message sent to the message cluster may include key transaction information such as the service ID (130001), scenario ID (001), customer number (59006319456), customer account number (K10000080000209), counterparty account number (108001012040020100000886), globally unique transaction serial number (1702201K102067000000000000021468), initiating channel code (WB), and transaction amount (30000). The first transaction server consumes messages in the message cluster according to the topic (service ID + scenario ID) registered in the message cluster. Before processing this transaction request, it first requests the disaster recovery server to check the user's transaction request. The request content includes: customer number (59006319456), customer account (K10000080000209), and request time (20190105145909).

[0122] In response to the verification request from the first transaction server, the disaster recovery server searches the graylist records in the disaster recovery database based on the customer number (59006319456) and customer account number (K10000080000209). ① If the graylist record contains the customer (59006319456), this indicates that the transaction data for this customer (59006319456) has not been fully synchronized to the first primary database after the switchover. The disaster recovery server returns a verification status code of 001 for this customer to the first transaction server. ② If the graylist record does not contain the customer (59006319456), this indicates that the transaction data for this customer has been fully synchronized to the first primary database after the switchover. The disaster recovery server returns a verification status code of 000 for this customer to the first transaction server.

[0123] The first transaction server receives the check status code returned by the disaster recovery server. ① If the returned check status code is 000, the transaction proceeds normally. ② If the returned check status code is 001, the first transaction server prompts the customer to try again later.

[0124] If the user's transaction request cannot be executed, the disaster recovery server can find out the transaction serial number, transaction amount, counterparty account number, initiating channel code and other information in the transaction data table of the first main database and the disaster recovery database based on the customer number (59006319456), and write them into transaction data set 1 and transaction data set 2 respectively; then the disaster recovery server will compare the data in set 1 and set 2 based on the transaction serial number, write the different transaction data (transaction serial number, transaction amount, counterparty account number, initiating channel code) into the first main database, and delete the customer (59006319456) from the gray list record of the disaster recovery database. When the customer (59006319456) initiates a business request again, the first transaction server can process the customer's transaction request normally.

[0125] See Figure 8 A schematic diagram of an application scenario for disaster recovery switching of transaction data provided in an embodiment of the present application includes: a first transaction system 1, a second transaction system 2, a first transaction server 11, a first primary database 12, a disaster recovery server 13, a disaster recovery database 14, a third message cluster 17, a first data distribution center 16, a second transaction server 21, a second primary database 22, and a second backup database 23, wherein the first transaction server 11, the first primary database 12, the disaster recovery server 13, the disaster recovery database 14, the third message cluster 17, and the first data distribution center 16 correspond to the first transaction system 1, and the second transaction server 21, the second primary database 22, the second backup database 23, and the second transaction system 2. The switching method of transaction data is similar to Figure 2B The application scenario shown is consistent with that shown in FIG. 1 , and will not be described in detail here. It is only explained that the first data distribution center 16 distributes the currently processed transaction data through the third message cluster 17 as follows:

[0126] After receiving a user transaction request, the first data distribution center 16 sends the message information of the user transaction request to the third message cluster 17, including key transaction information such as the service ID, scenario ID, customer account number, counterparty account number, globally unique transaction serial number, initiation channel code, and transaction amount. Based on this, the first transaction server consumes messages from the third message cluster 17 through the topic and processes the rejection message and sends it to the disaster recovery server 13 for message verification. If the disaster recovery server 13 determines that the gray list record of the disaster recovery database 14 contains the user identifier, it determines that the transaction data of the user in the first primary database 12 and the disaster recovery database 14 are inconsistent and refuses to execute the user's transaction. If the disaster recovery server 13 determines that the gray list record of the disaster recovery database 14 does not contain the user identifier, it executes the user's transaction.

[0127] Based on the same concept, the embodiment of the present application provides a transaction data disaster recovery switching device such as Figure 9As shown, the device is applicable to a disaster recovery server in a first transaction system that forms a disaster recovery backup relationship with a second transaction system, and includes: a receiving module 91 , a determining module 92 and a feedback module 93 .

[0128] The receiving module 91 is configured to receive a user verification request sent by the first transaction server in the first transaction system; the user verification request is determined by the first transaction server based on the user transaction request to be processed; and the user verification request carries the user identifier in the user transaction request.

[0129] Determination module 92 is used to determine the user verification result of the user verification request based on the first transaction record of the user identifier in the first primary database of the first transaction system and the second transaction record of the user identifier in the disaster recovery database of the first transaction system; the transaction records in the second primary database of the second transaction system are asynchronously backed up in the first primary database; the transaction records in the second primary database are consistent with the transaction records in the disaster recovery database.

[0130] The feedback module 93 is configured to feed back the user verification result to the first transaction server; the user verification result is used to indicate to the first transaction server whether to process the user transaction request.

[0131] In this way, when the transaction data is processed by the first transaction server, the disaster recovery server checks the data in the disaster recovery database and the first main database, and determines whether to execute the transaction request based on the user's verification results. This method avoids the occurrence of duplicate transactions while ensuring the economic interests of users.

[0132] In an optional embodiment, the determining module 92 is specifically configured to:

[0133] Determine whether the user identifier is included in the gray list record; the gray list record is obtained when the first transaction record and the second transaction record are inconsistent; when the user identifier is included in the gray list record, determine that the user verification result is verification failure, and the verification failure is used to instruct the first transaction server not to process the user transaction request; when the user identifier is not included in the gray list record, determine that the user verification result is verification success, and the verification success is used to instruct the first transaction server to process the user transaction request.

[0134] In this solution, whether to execute the user's transaction request is determined based on whether the user's identifier is in the gray list record. In this way, it is possible to accurately determine when to process the user's transaction request.

[0135] In an optional embodiment, the user verification result is used to instruct the first transaction server not to process the user transaction request; the device also includes: an update module, used to update the first transaction record according to the second transaction record, so that the transaction record of the user identifier in the disaster recovery database is consistent with the transaction record of the user identifier in the first master database.

[0136] In this solution, when the user verification result indicates that the user transaction request will not be processed, the first transaction record will be updated through the second transaction record so that the user transaction request can be executed.

[0137] In an optional embodiment, the apparatus further includes: a deletion module, configured to delete the user identifier from the grey list record.

[0138] When it is determined that the second transaction record corresponding to the user identifier has updated the first transaction record, the user identifier may be deleted to save storage resources.

[0139] The embodiment of the present application provides a transaction data disaster recovery switching device. Figure 10 The device is applicable to a first transaction server in a first transaction system that forms a disaster recovery backup relationship with a second transaction system, and includes:

[0140] The sending module 101 is configured to send a user verification request to the disaster recovery server after receiving a pending user transaction request; the user verification request carries the user identifier in the user transaction request.

[0141] Determination module 102 is used to receive the user verification result of the user verification request fed back by the disaster recovery server, and determine whether to process the user transaction request based on the user verification result; wherein, the user verification result is determined by the disaster recovery server in the first transaction system based on the first transaction record of the user identifier in the first primary database of the first transaction system and the second transaction record of the user identifier in the disaster recovery database of the first transaction system; the transaction records in the second primary database of the second transaction system are asynchronously backed up in the first primary database; the transaction records in the second primary database are consistent with the transaction records in the disaster recovery database.

[0142] In this way, when the transaction data is processed by the first transaction server, the disaster recovery server checks the data in the disaster recovery database and the first main database, and determines whether to execute the transaction request based on the user's verification results. This method avoids the occurrence of duplicate transactions while ensuring the economic interests of users.

[0143] In an optional embodiment, the device further includes: an acquisition module, configured to acquire the pending user transaction request from a message cluster; wherein the pending user transaction request is sent by the data distribution center of the first transaction system through the message cluster of the first transaction system.

[0144] This solution processes pending user transaction requests through message clustering, which allows user transaction requests to be consumed in sequence and avoids the situation where backup user transaction requests are confused when there are too many user transaction requests. This method can improve the processing efficiency of user transaction requests.

[0145] In an optional embodiment, the determination module 102 is specifically configured to: if the user verification result is a passed verification, the first transaction server processes the user transaction request; if the user verification result is a failed verification, the first transaction server stops processing the user transaction request.

[0146] In this method, whether to execute the user transaction request is determined based on the user's verification results, which can avoid the occurrence of duplicate transactions.

[0147] After introducing the transaction data disaster recovery switching method and apparatus in an exemplary embodiment of the present application, next, a computing device in another exemplary embodiment of the present application is introduced.

[0148] Those skilled in the art will appreciate that various aspects of the present application can be implemented as systems, methods, or program products. Therefore, various aspects of the present application can be specifically implemented in the following forms: a complete hardware implementation, a complete software implementation (including firmware, microcode, etc.), or an implementation that combines hardware and software aspects, which may be collectively referred to herein as a "circuit," "module," or "system."

[0149] In some possible implementations, the computing device according to the present application may include at least one processor and at least one memory. The memory stores a computer program, and when the computer program is executed by the processor, the processor executes the steps of the transaction data disaster recovery switching method according to various exemplary embodiments of the present application described above in this specification. For example, the processor may execute the following steps: Figure 6 Steps 601 to 603 shown in FIG. Figure 7 Steps 701 to 703 are shown.

[0150] Refer to the following Figure 11 hereinafter, a computing device 130 according to this embodiment of the present application is described. Figure 11 The computing device 130 shown is only an example and should not limit the functionality and scope of use of the embodiments of the present application. Figure 11As shown, the computing device 130 is in the form of a general-purpose intelligent terminal. Components of the computing device 130 may include, but are not limited to, the at least one processor 131, the at least one memory 132, and a bus 133 connecting different system components (including the memory 132 and the processor 131).

[0151] Bus 133 represents one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, a processor, or a local bus using any of a variety of bus architectures. Memory 132 may include readable media in the form of volatile memory, such as random access memory (RAM) 1321 and / or cache memory 1322, and may further include read-only memory (ROM) 1323. Memory 132 may also include programs / utilities 1325 having a set (at least one) of program modules 1324, such as, but not limited to, an operating system, one or more application programs, other program modules, and program data, each of which, or some combination thereof, may include an implementation of a network environment.

[0152] The computing device 130 may also communicate with one or more external devices 134 (e.g., a keyboard, pointing device, etc.), and / or any device that enables the computing device 130 to communicate with one or more other intelligent terminals (e.g., a router, modem, etc.). This communication may occur via an input / output (I / O) interface 135. Furthermore, the intelligent terminal 130 may also communicate with one or more networks (e.g., a local area network (LAN), a wide area network (WAN), and / or a public network, such as the Internet) via a network adapter 136. As shown, the network adapter 136 communicates with other modules of the computing device 130 via a bus 133. It should be understood that, although not shown, other hardware and / or software modules may be used in conjunction with the computing device 130, including but not limited to microcode, device drivers, redundant processors, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0153] In some possible implementations, various aspects of the transaction data backup method provided in this application may also be implemented in the form of a program product, which includes a computer program. When the program product is run on a computer device, the computer program is used to cause the computer device to execute the steps of the transaction data disaster recovery switching method according to various exemplary embodiments of the present application described above in this specification. For example, the processor may execute the following steps: Figure 6 Steps 601 to 603 shown in FIG. Figure 7 Steps 701 to 703 are shown.

[0154] The program product may employ any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. The readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or component, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection with one or more wires, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof.

[0155] The program product for three-dimensional visual relocalization according to an embodiment of the present application may be a portable compact disc read-only memory (CD-ROM) and include a computer program, and may be run on a smart terminal. However, the program product of the present application is not limited thereto. In this document, a readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0156] A readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying a readable computer program. This propagated data signal may take a variety of forms, including, but not limited to, electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium that can transmit, propagate, or transfer a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0157] It should be noted that although several units or subunits of the device are mentioned in the detailed description above, this division is merely exemplary and not mandatory. In fact, depending on the embodiment of the application, the features and functions of two or more units described above can be embodied in a single unit. Conversely, the features and functions of a single unit described above can be further divided and embodied by multiple units.

[0158] Furthermore, although the operations of the method of the present application are described in a particular order in the accompanying drawings, this does not require or imply that the operations must be performed in this particular order, or that all illustrated operations must be performed to achieve the desired results. Additionally or alternatively, some steps may be omitted, multiple steps may be combined into one step, and / or one step may be decomposed into multiple steps.

[0159] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the steps in the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0160] These computer program instructions may also be stored in a computer readable memory that can direct 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 comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0161] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0162] Although the preferred embodiments of the present application have been described, those skilled in the art may make additional changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the present application.

[0163] Obviously, those skilled in the art may make various changes and modifications to this application without departing from the spirit and scope of this application. Thus, if these modifications and variations of this application fall within the scope of the claims of this application and their equivalents, this application is intended to include these modifications and variations.

Claims

1. A transaction data disaster recovery switching method, characterized in that: The method is applicable to a disaster recovery server in a first trading system that forms a disaster recovery backup relationship with a second trading system, wherein the first trading system is configured to process transaction data at a location of the second trading system when a disaster occurs at the location of the second trading system, and includes: The disaster recovery server receives pending transaction data sent by the second transaction server in the second transaction system; if the pending transaction data is not successfully stored in the disaster recovery database in the first transaction system, the disaster recovery server sends a transaction failure message to the second transaction server, wherein the transaction failure message is used to instruct the second transaction server to roll back the pending transaction data; The disaster recovery server receives a user verification request sent by the first transaction server in the first transaction system; the user verification request is determined by the first transaction server according to the user transaction request to be processed; the user verification request carries the user identifier in the user transaction request; The disaster recovery server determines a user verification result of the user verification request based on a first transaction record of the user identifier in a first primary database of the first transaction system and a second transaction record of the user identifier in a disaster recovery database of the first transaction system; the transaction records in the second primary database of the second transaction system are asynchronously backed up in the first primary database; and the transaction records in the second primary database are consistent with the transaction records in the disaster recovery database; The disaster recovery server feeds back the user verification result to the first transaction server; the user verification result is used to indicate whether the first transaction server processes the user transaction request.

2. The method according to claim 1, characterized in that The disaster recovery server determines, based on a first transaction record of the user identifier in a first primary database of the first transaction system and a second transaction record of the user identifier in a disaster recovery database of the first transaction system, a user verification result of the user verification request, including: The disaster recovery server determines whether the gray list record contains the user identifier; the gray list record is obtained when the first transaction record and the second transaction record are inconsistent; When the gray list record contains the user identifier, the disaster recovery server determines that the user verification result is a verification failure, and the verification failure is used to instruct the first transaction server not to process the user transaction request; When the gray list record does not include the user identifier, the disaster recovery server determines that the user verification result is a passed verification, and the passed verification is used to instruct the first transaction server to process the user transaction request.

3. The method according to claim 1 or 2, characterized in that The user verification result is used to instruct the first transaction server not to process the user transaction request; the method further includes: The disaster recovery server updates the first transaction record according to the second transaction record, so that the transaction record of the user identifier in the disaster recovery database is consistent with the transaction record of the user identifier in the first primary database.

4. The method according to claim 3, characterized in that The method further comprises: The disaster recovery server deletes the user identifier from the grey list record.

5. A transaction data disaster recovery switching method, characterized in that: The method is applicable to a first transaction server in a first transaction system that forms a disaster recovery backup relationship with a second transaction system, wherein the first transaction system is configured to process transaction data at a location of the second transaction system when a disaster occurs at the location of the second transaction system, and includes: After receiving the user transaction request to be processed, the first transaction server sends a user verification request to the disaster recovery server; the user verification request carries the user identifier in the user transaction request; The first transaction server receives the user verification result of the user verification request fed back by the disaster recovery server, and determines whether to process the user transaction request based on the user verification result; wherein, the user verification result is determined by the disaster recovery server in the first transaction system based on the first transaction record of the user identifier in the first master database of the first transaction system and the second transaction record of the user identifier in the disaster recovery database of the first transaction system; the transaction records in the second master database of the second transaction system are asynchronously backed up in the first master database; the transaction records in the second master database are consistent with the transaction records in the disaster recovery database; the disaster recovery server is also used to receive the pending transaction data sent by the second transaction server in the second transaction system; if the pending transaction data is not successfully stored in the disaster recovery database in the first transaction system, the disaster recovery server is also used to send a transaction failure message to the second transaction server, and the transaction failure message is used to instruct the second transaction server to roll back the pending transaction data.

6. The method according to claim 5, characterized in that The method further comprises: The first transaction server obtains the pending user transaction request from the message cluster; wherein the pending user transaction request is sent by the data distribution center of the first transaction system through the message cluster of the first transaction system.

7. The method according to claim 5, characterized in that The determining whether to process the user transaction request according to the user verification result includes: If the user verification result is passed, the first transaction server processes the user transaction request; If the user verification result is failure, the first transaction server stops processing the user transaction request.

8. A transaction data disaster recovery switching device, characterized in that: The device is applicable to a disaster recovery server in a first trading system that forms a disaster recovery backup relationship with a second trading system. The first trading system is used to process transaction data at the location of the second trading system when a disaster occurs at the location of the second trading system. The device includes: a receiving module, configured to receive pending transaction data sent by a second transaction server in the second transaction system; if the pending transaction data is not successfully stored in the disaster recovery database in the first transaction system, the disaster recovery server sending a transaction failure message to the second transaction server, the transaction failure message being used to instruct the second transaction server to roll back the pending transaction data; The receiving module is configured to receive a user verification request sent by the first transaction server in the first transaction system; the user verification request is determined by the first transaction server based on the user transaction request to be processed; and the user verification request carries the user identifier in the user transaction request; a determination module, configured to determine a user verification result of the user verification request based on a first transaction record of the user identifier in a first primary database of the first transaction system and a second transaction record of the user identifier in a disaster recovery database of the first transaction system; the transaction records in the second primary database of the second transaction system are asynchronously backed up in the first primary database; and the transaction records in the second primary database are consistent with the transaction records in the disaster recovery database; A feedback module is used to feed back the user verification result to the first transaction server; the user verification result is used to indicate to the first transaction server whether to process the user transaction request.

9. A transaction data disaster recovery switching device, characterized in that: The device is applicable to a first transaction server in a first transaction system that forms a disaster recovery backup relationship with a second transaction system, wherein the first transaction system is configured to process transaction data at a location of the second transaction system when a disaster occurs at the location of the second transaction system, and includes: The sending module is used to send a user verification request to the disaster recovery server after receiving the user transaction request to be processed; the user verification request carries the user identifier in the user transaction request; A determination module is used to receive the user verification result of the user verification request fed back by the disaster recovery server, and determine whether to process the user transaction request based on the user verification result; wherein, the user verification result is determined by the disaster recovery server in the first transaction system based on the first transaction record of the user identifier in the first master database of the first transaction system and the second transaction record of the user identifier in the disaster recovery database of the first transaction system; the transaction records in the second master database of the second transaction system are asynchronously backed up in the first master database; the transaction records in the second master database are consistent with the transaction records in the disaster recovery database; the disaster recovery server is also used to receive the pending transaction data sent by the second transaction server in the second transaction system; if the pending transaction data is not successfully stored in the disaster recovery database in the first transaction system, the disaster recovery server is also used to send a transaction failure message to the second transaction server, and the transaction failure message is used to instruct the second transaction server to roll back the pending transaction data.

10. A computing device, characterized in that include: Memory and processor; a memory for storing program instructions; A processor is configured to call the program instructions stored in the memory and execute the method according to any one of claims 1 to 4 or 5 to 7 according to the obtained program.

11. A computer storage medium storing computer executable instructions, characterized in that: The computer executable instructions are used to execute the method according to any one of claims 1-4 or 5-7.

Images