Transaction data backup method, device, computing equipment, and storage medium

Abstract

The present application discloses a transaction data backup method, apparatus, computing device, and storage medium, relating to the technical field of financial technology. The method is applicable to a disaster recovery server in a first transaction system that forms a disaster recovery backup relationship with a second transaction system, comprising: obtaining the current pending transaction data of the second transaction system; the second transaction system being configured to process the pending transaction data and store it in a second master database of the second transaction system; asynchronously backing up the transaction data in the second master database to the first master database of the first transaction system; storing the pending transaction data in the disaster recovery database of the first transaction system; and, if the pending transaction data is not successfully stored in the disaster recovery database, sending a transaction failure message to the second transaction system, the transaction failure message being configured to instruct the second transaction system to roll back the pending transaction data. The transaction data backed up in this manner is more accurate and reliable.

Description

Technical Field

[0001] The present application relates to the field of financial technology, and in particular to a transaction data backup method, apparatus, computing device, 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 databases 1 and 2 are used for illustrative purposes. Data in the backup database at location A is asynchronously replicated to the primary database at location B. Simultaneously, data in the primary database at location B is synchronized to the backup database at location B. Only when disaster recovery occurs at location A is the financial transaction system at location B activated to serve users. However, due to the long distance between locations A and B, low network bandwidth and high latency, and the heavy load on the backup database at location A, data synchronization is delayed.

[0004] In order to solve the problem of data synchronization, the present application provides a transaction data backup method to solve the above problem. Summary of the Invention

[0005] The present application provides a transaction data backup method, apparatus, computing device, and storage medium to solve the problem of delay in synchronization of transaction data in different locations, thereby improving the accuracy of transaction data backup.

[0006] In a first aspect, an embodiment of the present application provides a transaction data backup 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: obtaining the current pending transaction data of the second transaction server of the second transaction system; the second transaction server is used to process the pending transaction data and store it in the second main database of the second transaction system; the transaction data in the second main database is asynchronously backed up in the first main database of the first transaction system; the pending transaction data is stored in the disaster recovery database of the first transaction system; the disaster recovery database is used to update the first main database; 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, and the transaction failure message is used to instruct the second transaction server to roll back the pending transaction data.

[0007] In this solution, the disaster recovery server obtains the pending transaction data of the second transaction server, and when the disaster recovery server fails to successfully place 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 load capacity of the production environment backup database, making the synchronization of transaction data more accurate.

[0008] In an optional embodiment, obtaining the transaction data currently to be processed by the second transaction server of the second transaction system includes: obtaining the transaction data currently to be processed by the second transaction server through a first message cluster; the messages in the first message cluster are sent through a data distribution center of the second transaction system; and the data distribution center is further used to send the messages to the second message cluster of the second transaction system.

[0009] Consuming transaction data through message clusters allows transaction data to be consumed in sequence, avoiding the situation where backup transaction data becomes chaotic when there is too much transaction data. This method can improve the processing efficiency of transaction data.

[0010] In an optional embodiment, the method further includes: comparing 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, updating the transaction data in the first primary database based on the transaction data in the disaster recovery database.

[0011] In this way, the transaction data in the disaster recovery database is compared with the data in the first master database, and the data in the first master database is updated in this way so that when disaster recovery occurs, transactions can be processed according to the data in the first master database.

[0012] In a second aspect, an embodiment of the present application provides a transaction data backup method, including: the second transaction server of the second transaction system sends the transaction data currently to be processed by the second transaction server to the disaster recovery server of the first transaction system; the first transaction system and the second transaction system form a disaster recovery backup relationship; the transaction data to be processed is processed and stored in the second main database of the second transaction system; the transaction data in the second main database is asynchronously backed up in the first main database of the first transaction system; after receiving a transaction failure message sent by the disaster recovery server, the transaction data to be processed is rolled back; wherein, the transaction failure message is sent by the disaster recovery server to the second transaction server after the transaction data to be processed is not successfully stored in the disaster recovery database; the disaster recovery database is used to update the first main database.

[0013] In this solution, the second transaction server sends the pending transaction data to the disaster recovery server, and when the disaster recovery server fails to successfully place 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 production environment backup database, making the synchronization of transaction data more accurate.

[0014] In an optional embodiment, sending the currently pending transaction data of the second transaction server to the disaster recovery server of the first transaction system includes: sending the currently pending transaction data to the first message cluster of the first transaction system through the data distribution center of the second transaction system so that the disaster recovery server obtains the pending transaction data from the first message cluster; wherein, the data distribution center is also used to send the pending transaction data to the second message cluster of the second transaction system.

[0015] Consuming transaction data through message clusters allows transaction data to be consumed in sequence, avoiding the situation where backup transaction data becomes chaotic when there is too much transaction data. This method can improve the processing efficiency of transaction data.

[0016] In a third aspect, an embodiment of the present application provides a transaction data backup device, 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:

[0017] an acquisition module, configured to acquire transaction data currently pending for processing by a second transaction server of the second transaction system; the second transaction system being configured to process the pending transaction data and store the data in a second primary database of the second transaction system; and the transaction data in the second primary database being asynchronously backed up in a first primary database of the first transaction system;

[0018] A storage module, configured to store the transaction data to be processed in a disaster recovery database of the first transaction system; the disaster recovery database is configured to update the first master database;

[0019] The transaction failure message sending module is used to send a transaction failure message to the second transaction server after the pending transaction data is not successfully stored in the disaster recovery database, wherein the transaction failure message is used to instruct the second transaction server to roll back the pending transaction data.

[0020] In this device, the to-be-processed transaction data of the second transaction server is obtained through the disaster recovery server, and when the disaster recovery server fails to successfully place the to-be-processed transaction data in the disaster recovery database, the second transaction server is instructed to roll back the to-be-processed transaction data, thereby realizing zero-delay synchronization of transaction data. The transaction data backed up in this way is not affected by distance, bandwidth delay and load capacity of the backup database in the production environment, making the synchronization of transaction data more accurate.

[0021] In an optional embodiment, the acquisition module is specifically configured to:

[0022] The transaction data currently to be processed by the second transaction server is obtained through the first message cluster; the messages in the first message cluster are sent through the data distribution center of the second transaction system; the data distribution center is also used to send messages to the second message cluster of the second transaction system.

[0023] Consuming transaction data through message clusters allows transaction data to be consumed in sequence, avoiding the situation where backup transaction data becomes chaotic when there is too much transaction data. This method can improve the processing efficiency of transaction data.

[0024] In an optional embodiment, the apparatus further comprises: a data comparison module, configured to compare the transaction data in the disaster recovery database with the transaction data in the first primary database;

[0025] 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.

[0026] The data comparison module compares the transaction data in the disaster recovery database with the data in the first master database, and updates the data in the first master database in this way so that when disaster recovery occurs, transactions can be processed based on the data in the first master database.

[0027] In a fourth aspect, an embodiment of the present application provides a transaction data backup device, comprising:

[0028] a data sending module, configured to send the transaction data currently to be processed by the second transaction server to the disaster recovery server of the first transaction system; the first transaction system and the second transaction system form a disaster recovery backup relationship;

[0029] a data processing module, configured to process the transaction data to be processed and store the processed transaction data 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;

[0030] A rollback module is used to roll back the pending transaction data after receiving a transaction failure message sent by the disaster recovery server; wherein, the transaction failure message is sent by the disaster recovery server to the second transaction system after the pending transaction data is not successfully stored in the disaster recovery database; the disaster recovery database is used to update the first master database.

[0031] In this device, the second transaction server sends the pending transaction data to the disaster recovery server, and when the disaster recovery server fails to successfully place 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 production environment backup database, making the synchronization of transaction data more accurate.

[0032] In an optional embodiment, the data sending module is specifically configured to:

[0033] The current transaction data to be processed is sent to the first message cluster of the first transaction system through the data distribution center of the second transaction system so that the disaster recovery server obtains the transaction data to be processed from the first message cluster; wherein, the data distribution center is also used to send the transaction data to be processed to the second message cluster of the second transaction system.

[0034] Consuming transaction data through message clusters allows transaction data to be consumed in sequence, avoiding the situation where backup transaction data becomes chaotic when there is too much transaction data. This method can improve the processing efficiency of transaction data.

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

[0036] Memory and processor;

[0037] a memory for storing program instructions;

[0038] The processor is configured to call the program instructions stored in the memory and execute the transaction data backup method according to any one of the first aspect or the second aspect according to the obtained program instructions.

[0039] 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 backup method in the embodiment of the present application.

[0040] 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

[0041] 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.

[0042] Figure 1 A schematic diagram of a scenario for transaction data backup in this related technology;

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

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

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

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

[0047] Figure 6 A schematic diagram of the structure of a transaction data backup device provided in an embodiment of the present application;

[0048] Figure 7A schematic diagram of the structure of a transaction data backup device provided in an embodiment of the present application;

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

[0050] 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.

[0051] 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.

[0052] As described in the background, in order to back up data at location A, the data needs to be asynchronously transferred from the backup database at location A to the master database at location B. If the distance between locations A and B is long and the network bandwidth latency is high, if a disaster occurs at location A (i.e., a natural disaster such as a typhoon, earthquake, mudslide, or heavy rain prevents normal transaction services at location A), the master database at location B needs to be called to process the data to handle transactions at location A. However, if the data in location B's master database does not fully back up the transaction data at location A, directly processing transactions at location A may result in financial losses. For example, if user A conducts a transaction at location A and transfers 1 million yuan, with an account balance of 500,000 yuan, and the transaction record is not synchronized to the master database at location B, and a disaster occurs at location A, user A transfers another 1 million yuan. However, user A's actual account balance is less than 1 million yuan, but the master database at location B records user A as having 1.5 million yuan. Directly executing the transfer transaction will inevitably result in financial losses for the financial institution. Therefore, it is important to back up the transaction data at location A to location B. Based on this, an embodiment of the present application provides a method for backing up transaction data.

[0053] 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.

[0054] 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.

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

[0056] 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.

[0057] 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.

[0058] 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.

[0059] 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.

[0060] 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.

[0061] Figure 2 The figure shows a schematic diagram of an application scenario of transaction data backup provided by an embodiment of the present application, which can be used for daily backup of transaction data, and can also be used to back up transaction data in advance when a disaster recovery may occur in a certain place. All scenarios that meet the transaction data backup requirements of the present application are applicable to the solution of the present application. 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 a backup database, which is 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.

[0062] In actual application, multiple backups can be made for the transaction data currently being processed by the second transaction server 21. This application only illustrates one backup. For example, if the second transaction system 2 is located at location A, the transaction data currently being processed at location A can be backed up at multiple locations, such as location B, location C, and location D. This application does not specify the specific number of backups or the specific geographical locations at which the backups are made. All transaction data backup methods implemented in this application are applicable. Specifically, the first transaction server 11, the first primary database 12, the disaster recovery server 13, and the disaster recovery database 14 correspond to the first transaction system 1, and the second transaction server 21, the second primary database 22, and the second backup database 23 correspond to the second transaction system 2. Users conduct financial transactions through the second transaction server 21. The second transaction server 21 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.

[0063] At the same time, the second transaction system 2 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.

[0064] 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.

[0065] In this way, when the second primary database and the disaster recovery database fail to store transaction data, the second transaction system rolls back the pending transaction data, thereby achieving synchronization of transaction data. The data backed up in this way is more reliable.

[0066] Next, we will introduce the transaction data backup method from the perspective of disaster recovery server. Figure 3 In the flowchart shown, the disaster recovery server may first execute step 301 to obtain the transaction data currently to be processed by the second transaction server of the second transaction system; wherein the second transaction server is used to process the transaction data to be processed and store it in the 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.

[0067] It should be noted that if it is anticipated that a disaster recovery may occur in a certain place (i.e., natural disasters such as typhoons, earthquakes, mudslides, heavy rains, etc.), or if it is manually set to start transaction data backup, then the transaction data backup plan of this application can be executed. For example: if it is predicted that a typhoon may occur in place A, and the disaster recovery site of place A is place B, then the plan of this application can be started at place B. Or if the user wants to back up the transaction data of place C at place D, then the plan of this application can be directly started at place D.

[0068] 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.

[0069] 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.

[0070] 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.

[0071] 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 system. The transaction failure message is used to instruct the second transaction server to roll back the pending transaction data.

[0072] Accordingly, the second transaction server of the second transaction system may refer to Figure 4 Flowchart, executing step 401, 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.

[0073] 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.

[0074] 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.

[0075] 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.

[0076] 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.

[0077] 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.

[0078] 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.

[0079] For the application scenario diagram of consuming the currently pending transaction data based on the message cluster, please refer to Figure 5 , Figure 5It 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 2 The application scenario shown is consistent with that shown in the figure, so I will not elaborate on it here. I will only explain that the data distribution center distributes the currently processed transaction data through the message cluster as follows:

[0080] 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.

[0081] Based on the same concept, the transaction data backup device provided in the embodiment of the present application is as follows Figure 6 As 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: an acquisition module 61 , a storage module 62 and a transaction failure message sending module 63 .

[0082] Among them, the acquisition module 61 is used to obtain the transaction data currently to be processed by the second transaction server of the second transaction system; the second transaction server is used to process the transaction data to be processed and store it in the second main database of the second transaction system; the transaction data in the second main database is asynchronously backed up in the first main database of the first transaction system.

[0083] The storage module 62 is configured to store the transaction data to be processed into a disaster recovery database of the first transaction system; the disaster recovery database is configured to update the first master database.

[0084] The transaction failure message sending module 63 is configured to send a transaction failure message to the second transaction server after the pending transaction data is not successfully stored in the disaster recovery database. The transaction failure message is configured to instruct the second transaction server to roll back the pending transaction data.

[0085] In this device, the to-be-processed transaction data of the second transaction server is obtained through the disaster recovery server, and when the disaster recovery server fails to successfully place the to-be-processed transaction data in the disaster recovery database, the second transaction server is instructed to roll back the to-be-processed transaction data, thereby realizing zero-delay synchronization of transaction data. The transaction data backed up in this way is not affected by distance, bandwidth delay and load capacity of the backup database in the production environment, making the synchronization of transaction data more accurate.

[0086] In an optional embodiment, the acquisition module 61 is specifically configured to:

[0087] The transaction data currently to be processed by the second transaction server is obtained through the first message cluster; the messages in the first message cluster are sent through the data distribution center of the second transaction system; the data distribution center is also used to send messages to the second message cluster of the second transaction system.

[0088] In an optional embodiment, the apparatus further comprises: a data comparison module, configured to compare the transaction data in the disaster recovery database with the transaction data in the first primary database;

[0089] 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.

[0090] The transaction data backup device provided in the embodiment of the present application is as follows: Figure 7 As shown, the device includes: a data sending module 71, a data processing module 72 and a rollback module 73.

[0091] The data sending module 71 is used to send 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; the first transaction system and the second transaction system form a disaster recovery backup relationship.

[0092] The data processing module 72 is used to process the transaction data to be processed and store it in the second main database of the second transaction system; the transaction data in the second main database is asynchronously backed up in the first main database of the first transaction system.

[0093] The rollback module 73 is used to roll back the pending transaction data after receiving the transaction failure message sent by the disaster recovery server; 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 master database.

[0094] In this device, the second transaction server sends the pending transaction data to the disaster recovery server, and when the disaster recovery server fails to successfully place 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 production environment backup database, making the synchronization of transaction data more accurate.

[0095] In an optional embodiment, the data sending module 71 is specifically configured to:

[0096] The current transaction data to be processed is sent to the first message cluster of the first transaction system through the data distribution center of the second transaction system so that the disaster recovery server obtains the transaction data to be processed from the first message cluster; wherein, the data distribution center is also used to send the transaction data to be processed to the second message cluster of the second transaction system.

[0097] After introducing the transaction data backup method and apparatus in the exemplary embodiment of the present application, next, a computing device in another exemplary embodiment of the present application is introduced.

[0098] 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."

[0099] 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 backup 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 3 Steps 301 to 303 shown in FIG. Figure 4 Steps 401 to 403 are shown.

[0100] Refer to the following Figure 8hereinafter, a computing device 130 according to this embodiment of the present application is described. Figure 8 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 8 As 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).

[0101] 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.

[0102] 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.

[0103] In some possible implementations, various aspects of the transaction data backup method provided by the present 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 backup 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 3Steps 301 to 303 shown in FIG. Figure 4 Steps 401 to 403 are shown.

[0104] 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.

[0105] 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.

[0106] 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.

[0107] 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.

[0108] 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.

[0109] 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.

[0110] 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.

[0111] 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 The steps for the function specified in one or more boxes.

[0112] 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.

[0113] 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 backup 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 second trading system is an operating system that processes transaction data before disaster recovery, and the second trading system is used to process transaction services; the first trading system is a trading system that forms a disaster recovery backup relationship with the second trading system, and is located in a different geographical location from the second trading system, and the second trading system is also used to process transaction services; when a disaster occurs at the location of the second trading system, the first trading server is started; the disaster recovery server is a server located at the location of the first trading system, and is used to synchronize transaction data currently being processed by the second trading system in real time, and is a disaster recovery server in the first trading system that forms a disaster recovery backup relationship with the second trading system; the method comprises: Obtaining transaction data currently pending for processing by a second transaction server of the second transaction system; the second transaction server being configured to process the pending transaction data and store the data in a second primary database of the second transaction system; and asynchronously backing up the transaction data in the second primary database in the first primary database of the first transaction system. The disaster recovery server stores the transaction data to be processed in a disaster recovery database of the first transaction system; the disaster recovery database is used to update the first master database; After the pending transaction data is not successfully stored in the disaster recovery database, the disaster recovery server sends a transaction failure message to the second transaction server, where the transaction failure message is used to instruct the second transaction server to roll back the pending transaction data.

2. The method according to claim 1, characterized in that The acquiring the transaction data currently to be processed by the second transaction server of the second transaction system includes: The disaster recovery server obtains the transaction data currently to be processed by the second transaction server through the first message cluster; the messages in the first message cluster are sent through the data distribution center of the second transaction system; the data distribution center is also used to send messages to the second message cluster of the second transaction system.

3. The method according to claim 1 or 2, characterized in that The method further comprises: The disaster recovery server compares the transaction data in the disaster recovery database with the transaction data in the first primary database; If the disaster recovery server determines 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.

4. A transaction data backup method, characterized in that: include: The second transaction server of the second transaction system sends the transaction data currently to be processed by the second transaction server to the disaster recovery server of the first transaction system; The first trading system and the second trading system form a disaster recovery backup relationship; The second transaction server processes the transaction data to be processed and stores the data in a second main database of the second transaction system; The transaction data in the second main database is asynchronously backed up in the first main database of the first transaction system; The second transaction server rolls back the pending transaction data after receiving the transaction failure message sent by the disaster recovery server; 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; The second trading system is an operating system for processing trading data before disaster recovery, and the second trading system is used to process trading services; the first trading system and the second trading system are not in the same geographical location, and the second trading system is also used to process trading services. When a disaster occurs at the location of the second trading system, the first trading server is started; the disaster recovery server is a server located at the location of the first trading system, and is used to synchronize the transaction data currently processed by the second trading system in real time. It is a disaster recovery server in the first trading system that forms a disaster recovery backup relationship with the second trading system.

5. The method according to claim 4, characterized in that The sending of the transaction data currently to be processed by the second transaction server to the disaster recovery server of the first transaction system includes: The current transaction data to be processed is sent to the first message cluster of the first transaction system through the data distribution center of the second transaction system so that the disaster recovery server obtains the transaction data to be processed from the first message cluster; wherein, the data distribution center is also used to send the transaction data to be processed to the second message cluster of the second transaction system.

6. A transaction data backup 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, wherein the second trading system is an operating system that processes transaction data before disaster recovery, and the second trading system is used to process transaction services; 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, and the second trading system is also used to process transaction services, and the first trading server is only started when a disaster occurs at the location of the second trading system; the disaster recovery server is a server located at the location of the first trading system, and is used to synchronize transaction data currently being processed by the second trading system in real time, and is a disaster recovery server in the first trading system that forms a disaster recovery backup relationship with the second trading system; and comprises: an acquisition module, configured to acquire transaction data currently pending for processing by a second transaction server of the second transaction system; the second transaction server being configured to process the pending transaction data and store the data in a second primary database of the second transaction system; and the transaction data in the second primary database being asynchronously backed up in the first primary database of the first transaction system; A storage module, configured to store the transaction data to be processed in a disaster recovery database of the first transaction system; the disaster recovery database is configured to update the first master database; The transaction failure message sending module is used to send a transaction failure message to the second transaction server after the pending transaction data is not successfully stored in the disaster recovery database, wherein the transaction failure message is used to instruct the second transaction server to roll back the pending transaction data.

7. The device according to claim 6, characterized in that The acquisition module is specifically used to: The transaction data currently to be processed by the second transaction server is obtained through the first message cluster; the messages in the first message cluster are sent through the data distribution center of the second transaction system; the data distribution center is also used to send messages to the second message cluster of the second transaction system.

8. The device according to claim 6 or 7, characterized in that The apparatus further comprises: a data comparison module for comparing 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.

9. A transaction data backup device, characterized in that: include: A data sending module, configured to send the transaction data currently to be processed by the second transaction server to the disaster recovery server of the first transaction system; The first trading system and the second trading system form a disaster recovery backup relationship; a data processing module, configured to process the transaction data to be processed and store the processed transaction data in a second main database of the second transaction system; The transaction data in the second main database is asynchronously backed up in the first main database of the first transaction system; a rollback module configured to roll back the pending transaction data upon receiving a transaction failure message sent by the disaster recovery server; 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; The second trading system is an operating system for processing trading data before disaster recovery, and the second trading system is used to process trading services; the first trading system and the second trading system are not in the same geographical location, and the second trading system is also used to process trading services. When a disaster occurs at the location of the second trading system, the first trading server is started; the disaster recovery server is a server located at the location of the first trading system, and is used to synchronize the transaction data currently processed by the second trading system in real time. It is a disaster recovery server in the first trading system that forms a disaster recovery backup relationship with the second trading system.

10. The device according to claim 9, characterized in that The data sending module is specifically used to: The current transaction data to be processed is sent to the first message cluster of the first transaction system through the data distribution center of the second transaction system so that the disaster recovery server obtains the transaction data to be processed from the first message cluster; wherein, the data distribution center is also used to send the transaction data to be processed to the second message cluster of the second transaction system.

11. 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 steps of the method according to any one of claims 1 to 5 according to the obtained program.

12. A computer storage medium storing computer executable instructions, characterized in that: The computer executable instructions are used to execute the steps of the method according to any one of claims 1 to 5.

Images