Business data disaster recovery method and device and business system

Abstract

The invention discloses a disaster recovery method and device for service data and a service system.The method can be applied to a standby node of the service system, a main node of the service system is used for conducting service processing according to a service request to obtain service data, and the method comprises the steps that before the main node conducts service processing according to the service request, the service data is obtained; backing up first data corresponding to the service request, the first data comprising data associated with the service processing logic and at least comprising a unique identifier of the service request; under the condition that the business processing is finished, backing up second data corresponding to the business request, the second data comprising the unique identifier and data determined according to the business processing; and in a data recovery stage, screening out target first data and target second data corresponding to the target data recovery time period, determining missing service data in the standby node according to the service processing logic, the target first data and the target second data, and recovering the missing service data. The method can avoid loss of service data.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a disaster recovery method, device and business system for business data. Background Art

[0002] In order to ensure uninterrupted processing of business, a backup node (or disaster recovery node, such as a backup computer room) with the same production environment as the main node is often deployed on the basis of the main node (such as the main computer room) so that when the main node fails, the business can be switched to the backup node for processing.

[0003] At present, in the business system of the master-slave node architecture, for performance reasons, the database in the standby node (standby database) uses asynchronous replication to synchronize data with the database in the master node (primary database). Therefore, when the master node fails and business processing switches to the standby node, the standby database data lags behind the primary database, resulting in data loss in the business.

[0004] However, in the core business system, business data loss is intolerable. For example, in the trading system, a user submits a transaction request and receives a successful response and completes the subsequent fund transfer. However, because the server loses the transaction data, the user's funds are lost. This is intolerable. Therefore, it is urgent to propose a disaster recovery solution that can avoid business data loss. Summary of the invention

[0005] The embodiments of the present application provide a disaster recovery method, device and business system for business data to avoid business data loss when a master node fails.

[0006] In a first aspect, an embodiment of the present application provides a disaster recovery method for business data, which is applied to a backup node of a business system, wherein the business system further includes a master node, and the master node is used to perform business processing according to a business request to obtain business data, and the method includes:

[0007] Before the master node performs service processing according to the service request, backing up first data corresponding to the service request, wherein the first data includes data associated with the service processing logic and at least includes a unique identifier of the service request;

[0008] When the business processing is completed, backing up second data corresponding to the business request, wherein the second data includes the unique identifier and data determined according to the business processing;

[0009] In the data recovery phase, the target first data and the target second data corresponding to the target data recovery period are screened out, the missing business data in the standby node is determined according to the business processing logic, the target first data and the target second data, and the missing business data is recovered.

[0010] In a second aspect, an embodiment of the present application also provides a disaster recovery device for business data, which is applied to a backup node of a business system, wherein the business system also includes a master node, and the master node is used to perform business processing according to a business request to obtain business data, and the device includes:

[0011] A first backup module, configured to back up first data corresponding to the service request before the master node performs service processing according to the service request, wherein the first data includes data associated with the service processing logic and at least includes a unique identifier of the service request;

[0012] A second backup module, configured to back up second data corresponding to the service request when the service processing is completed, wherein the second data includes the unique identifier and data determined according to the service processing;

[0013] The data recovery module is used to screen out the target first data and the target second data corresponding to the target data recovery period in the data recovery phase, determine the missing business data in the standby node according to the business processing logic, the target first data and the target second data, and recover the missing business data.

[0014] In a third aspect, an embodiment of the present application further provides a disaster recovery system for business data, wherein the business system comprises a master node and a backup node, wherein the master node is used to perform business processing according to business requests to obtain business data; and the backup node comprises the device as described in the second aspect.

[0015] At least one of the above-mentioned technical solutions adopted in the embodiments of the present application, in addition to the asynchronous replication method adopted by the relevant technology for synchronization, on the one hand, before the primary node performs business processing according to the business request, the first data containing data associated with the business processing logic and the unique identifier of the business request is backed up to the standby node; on the other hand, when the business processing is completed, the second data containing the unique identifier and the data determined according to the business processing is backed up to the standby node, rather than just performing asynchronous backup as described in the prior art. Therefore, in the data recovery stage, the target first data and the target second data corresponding to the target data recovery period can be screened out from the standby node, and the missing business data in the standby node can be determined according to the business processing logic, the target first data and the target second data, and the missing business data can be restored, thereby avoiding the loss of business data when the primary node fails. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0017] Figure 1 It is a schematic diagram of a deployment architecture of a business system provided in one embodiment of the present application.

[0018] Figure 2 It is a flowchart of a disaster recovery method for business data provided by an embodiment of the present application.

[0019] Figure 3 It is a schematic diagram of the principle of a disaster recovery method for business data provided by an embodiment of the present application.

[0020] Figure 4 It is a schematic diagram of the principle of a disaster recovery method for business data provided by another embodiment of the present application.

[0021] Figure 5 It is a schematic diagram of the principle of a disaster recovery method for business data provided by another embodiment of the present application.

[0022] Figure 6 It is a schematic diagram of the principle of using a search tree to determine the processing order and processing status corresponding to business data in backup data provided by an embodiment of the present application.

[0023] Figure 7 It is a structural diagram of a disaster recovery device for business data provided by an embodiment of the present application. DETAILED DESCRIPTION

[0024] In order to make the purpose, technical solution and advantages of the present application clearer, the technical solution of the present application will be clearly and completely described below in combination with the specific embodiments of the present application and the corresponding drawings. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present application.

[0025] In order to avoid business data loss when a master node fails, the embodiments of the present application provide a disaster recovery method and a business system for business data, which will be described below respectively.

[0026] It should be noted that the business described in the embodiments of the present application may be any business that requires writing data to a database, such as settlement transactions of customers on the UnionPay platform, order transactions on the e-commerce platform, and inventory deductions, etc. For the sake of convenience, the following mainly takes the settlement transactions of customers on the UnionPay platform (hereinafter referred to as transactions) as an example for introduction. The corresponding business request is referred to as a transaction request, and the corresponding business data is referred to as transaction data.

[0027] The following first describes a deployment architecture of a business system provided in an embodiment of the present application.

[0028] In an embodiment of the present application, the business system includes two types of nodes, or the business system can be carried by at least two types of nodes. The two types of nodes can be located in different regions. When one of the two types of nodes is a primary node, the other node is a backup node.

[0029] In an example, if the two types of nodes each correspond to a computer room, the master node is the main computer room, and the backup node is the backup computer room.

[0030] In a specific embodiment of the present application, a server, a database and a backup data source may be deployed in the primary node and the backup node respectively, wherein the database deployed in the primary node may be referred to as a primary database, and the database deployed in the backup node may be referred to as a backup database.

[0031] Figure 1 FIG. 1 shows a deployment diagram of a business system provided by an embodiment of the present application. Figure 1 As shown, the business system may include a master node 11 and a standby node 12 , wherein the master node 11 is deployed with a server 111 , a database 112 and a backup data source 113 , and the standby node 12 is deployed with a server 121 , a database 122 and a backup data source 132 .

[0032] The backup data source deployed in the master node 11 and the backup node 12 can be any carrier that can store business data, such as any of the carriers such as file system, database, message queue, log, etc. The way to back up data to the backup data source can include but is not limited to http call, rpc call and sending message, etc.

[0033] The servers deployed in the master node 11 and the standby node 12 may be in the form of a single server, a server cluster, a cloud server, or the like.

[0034] The database deployed in the master node 11 and the standby node 12 may include but is not limited to a relational database.

[0035] Based on the above business system, the embodiment of the present application also provides a disaster recovery method for business data, which is described below.

[0036] like Figure 2 As shown, an embodiment of the present application provides a disaster recovery method for business data, which can be applied to a backup node of a business system, wherein the business system also includes a master node, and the master node is used to perform business processing according to a business request to obtain business data; the method may include:

[0037] Step 201: Before the master node performs service processing according to the service request, back up first data corresponding to the service request, wherein the first data includes data associated with the service processing logic and at least includes a unique identifier of the service request.

[0038] The master node may receive a service request submitted by a user through its server, and send the first data generated in the master node to the standby node, so that the standby node backs up the first data.

[0039] For example, Figure 3 As shown, the service request submitted by the user can be received by the server 111 of the main node 11, and the unique identifier of the service request and the service data (first data) generated before the service request is processed are sent to the backup data source 123 in the backup node 12 for backup through the server 111. Among them, the unique identifier of the service request refers to the identifier that can uniquely determine the service request, which is generally determined according to the unique identifier of the party submitting the service request (user) and the serial number of the service request, and can also be determined according to other methods. The embodiment of the present application does not limit this; the data associated with the service processing logic may include the service data generated before the service request is processed, and the data may include but is not limited to all or part of the data carried in the service request and all or part of the data generated during the preprocessing of the service request. The preprocessing of the service request may include one or more of the processes such as the legitimacy check of the service request and the determination of the service type. The preprocessing of the service request is relative to the formal processing of the service request, and the processing before the formal processing can be called preprocessing.

[0040] Taking the business request as a transaction request as an example, the server 111 can send the transaction unique identifier and the transaction data generated before the transaction request is processed to the backup data source 123, so that the backup data source 123 in the backup node 12 can be backed up. Among them, the unique identifier of the transaction request refers to the identifier that can uniquely identify the transaction, which is generally the unique identifier of the party submitting the business request (user) and the serial number of the transaction request, which is specifically determined according to the settings of the business system; the transaction data generated before the transaction request is processed (pre-transaction data) includes but is not limited to all or part of the data carried in the transaction request and all or part of the data generated during the pre-processing of the transaction request, for example, including but not limited to the user account submitting the transaction request, the transaction amount, the payment direction (collection or payment) and the transaction type, etc.

[0041] Step 202: When the business processing is completed, back up second data corresponding to the business request, wherein the second data includes the unique identifier and data determined according to the business processing.

[0042] In one embodiment, step 202 may include: when the master node generates the second data, backing up the second data. Specifically, the service request may be processed by the server of the master node, and before returning the service processing result to the user, the second data may be sent to the backup data source in the standby node, so that the standby node backs up the second data. Of course, the first data and the second data may also be saved in the database of the master node.

[0043] For example, Figure 3 As shown, the service request submitted by the user is processed by the server 111 of the master node 11, and before returning the service processing result to the user, the unique identifier of the service request and the service data (second data) generated after the service request is processed are sent to the backup data source 123 in the standby node 12 through the server 111, so that the backup data source 123 can be backed up, and the above-mentioned first data and second data can also be saved in the database 112 of the master node 11, that is, the flow of processing the service request is written into the database 112 of the master node 11. Among them, the data determined according to the service processing can be the service data generated after the service request is processed, specifically referring to the data that can only be known after the service system processes the service request, and these data include but are not limited to the database auto-increment ID of the service flow and the service processing status, etc. The service processing status can be one of the states of success and failure.

[0044] Still taking the business request as a transaction request as an example, the server 111 can send the transaction unique identifier and the transaction data generated after the transaction request is processed to the backup data source 123 for backup. Among them, the transaction data (post-transaction data) generated after the transaction request is processed is data that can only be known after the business system processes the transaction request. These data include but are not limited to the database auto-increment ID of the transaction flow, transaction status, account balance and other data. The transaction status can be one of success and failure.

[0045] It is understandable that for transactions, after a transaction is completed, in addition to saving the transaction flow and transaction status to the database, it is also possible to adjust the balance of the user's account based on the transaction results to facilitate the smooth progress of subsequent transactions.

[0046] It can also be understood that before returning the service request processing result to the user, the service data is written to the database of the primary node and the service data is simultaneously backed up to the backup node, thereby avoiding irreversible data loss caused by failure of the primary node.

[0047] In another implementation, step 202 may include: when the master node determines the business data corresponding to the query request, backing up second data corresponding to the business request.

[0048] Specifically, a processing status query request for the target business can be received through the server of the master node, and second data can be queried from the database of the master node, wherein the second data includes business data generated after the target business is processed and the processing status of the target business.

[0049] For example, Figure 5 As shown, after receiving the processing status query request for the target business submitted by the user, the server 111 of the master node 11 will query from the database 112 of the master node 11 to obtain the business data (second data) generated after the target business is processed, which includes the processing status of the target business, and then back up the unique identifier of the target business and the corresponding third data to the backup data source 123 of the standby node 12.

[0050] It can be seen that through the above steps 201 and 202, the business data saved in the database of the primary node can be synchronously backed up to the backup data source of the standby node. In this way, when the primary node fails, before the standby node is enabled, the missing data in the database of the standby node can be restored based on the backup data in the backup data source of the standby node, without causing loss of business data.

[0051] During the execution of step 201, step 202 and any of the following step 203, if an exception occurs (such as database read timeout, failure to call an external interface, etc.), the process is terminated and feedback that the business processing status is unknown is returned to the user.

[0052] It should be noted that the business data backed up to the backup data source of the standby node through the backup solution provided in the embodiment of the present application may have the following two characteristics:

[0053] (1) At any time, the amount of data contained in the backup data source of the standby node is greater than the amount of data stored on the user side, and the amount of data contained in the backup data source of the standby node is less than the amount of data contained in the database of the primary node, that is:

[0054] The amount of data contained in the database of the primary node ≥ the amount of data contained in the backup data source of the standby node ≥ the amount of data saved on the user side.

[0055] (2) The processing order of the business data stored in the backup data source of the standby node may be inconsistent with the processing order of the business data stored in the database of the primary node.

[0056] According to the first feature mentioned above, the following two meanings can be reflected: First, when the database of the primary node goes down, when the backup data source of the standby node is used to restore the database of the standby node, since the amount of data stored in the backup data source of the standby node is more than the amount of data stored on the user side, the database of the standby node can be restored using the data extracted from the backup data source of the standby node, ensuring that the user's data is not lost; second, since the data stored in the backup data source in the standby node is less than the data stored in the database in the primary node, when restoring some incomplete business data, some methods are needed to infer the processing status of these business data. In addition, the second feature mentioned above will also have an impact on the recovery of missing data in the database of the standby node. Therefore, after extracting the target backup data from the backup data source of the standby node, it is necessary to determine the business processing status and business processing order in the target backup data so that the missing data in the database of the standby node can be correctly restored, which will be described in detail below.

[0057] Step 203: In the data recovery phase, the target first data and the target second data corresponding to the target data recovery period are screened out, the missing business data in the standby node is determined according to the business processing logic, the target first data and the target second data, and the missing business data is recovered.

[0058] Generally, after the main node fails and before the standby node is enabled, the target backup data (target first data and target second data corresponding to the target data recovery period) is filtered from the backup data source of the standby node through the server of the standby node, and the missing business data in the database of the standby node is restored based on the business processing logic and the target backup data.

[0059] For example, Figure 4 As shown, after the main node 11 fails and in the fault recovery stage before the standby node 12 is enabled, the target backup data can be extracted from the backup data source 123 of the standby node 12 by the server 121 in the standby node 12, and then the missing business data in the database 122 of the standby node 12 can be restored based on the business processing logic and the extracted target backup data.

[0060] In one embodiment, the target data recovery period is determined based on the time when the primary node fails, and specifically can be a time period within a preset time before the primary node fails (e.g., within 30 minutes before the failure). Optionally, the target data recovery period includes the primary node's failure start time. Optionally, the target data recovery period can also include a period of time within a preset time after the primary node's failure start time (e.g., 30 minutes before the failure to 10 minutes after the failure), so as to perform a more comprehensive recovery of the missing data in the backup node's database.

[0061] In another embodiment, the target data recovery period is determined based on the time when the data recorded in the database of the standby node lags behind the data recorded in the database of the primary node. For example, the last storage time of the database of the primary node is 12:00 on October 2, 2021, and the last storage time of the database of the standby node is 11:59 on October 2, 2021. Then, the target data recovery period is: the period between 11:59 on October 2, 2021 and -12:00 on October 2, 2021. It can be understood that the last storage time of the database of the standby node is actually the time when the database of the standby node asynchronously copied data from the database of the primary node for the last time.

[0062] Of course, the methods for determining the target data recovery period are not limited to the above two. It can be determined according to actual needs during specific implementation, so that the target data recovery period for extracting data from the backup data source can cover the lost data in the standby node database, thereby making the data stored in the standby node database consistent (synchronized) with the data stored in the primary node database.

[0063] The following is a detailed description of the process of determining the missing service data in the standby node according to the service processing logic, the target first data and the target second data in the above step 203, and restoring the missing service data.

[0064] Since there may be duplicate backup data in the target first data and the target second data extracted from the backup data source of the standby node, the target first data and the target second data can be merged based on the unique identifier of the business request to remove duplicate data and obtain merged backup data, thereby reducing the amount of data that needs to be restored to the database of the standby node and improving subsequent recovery efficiency.

[0065] Optionally, the first data and the second data are backed up synchronously; the standby node is also used to asynchronously back up the business data of the primary node.

[0066] There is also a situation where part of the business data in the target first data and the target second data extracted from the backup data source of the standby node may have been written into the database of the standby node. Therefore, the merged backup data may also be compared with the business data that has been backed up in the standby node, and the part of the merged backup data corresponding to the business data that has been backed up may be discarded to further reduce the amount of data that needs to be restored to the database of the standby node, thereby further improving the subsequent recovery efficiency.

[0067] Furthermore, since the processing order of the business data stored in the backup data source of the standby node may be inconsistent with the processing order of the business data stored in the database of the primary node, and the processing status of the business data stored in the backup data source of the standby node may be unknown, the merged backup data can be first arranged according to the business processing logic; and the business data missing in the standby node is generated based on the arranged merged backup data.

[0068] The arranging the merged backup data according to the business processing logic includes: determining a business processing sequence of business requests corresponding to the merged backup data, and / or completing incomplete data in the merged backup data.

[0069] As an example, determining the service processing sequence of the service request corresponding to the merged backup data includes: searching for a service processing sequence that meets the service constraint condition from possible service processing sequences based on a preset search algorithm.

[0070] Specifically, based on a preset search algorithm, one processing sequence that meets the preset constraint condition among all possible processing sequences of the business data in the backup data can be determined as the processing sequence corresponding to the business data in the merged backup data.

[0071] As an example, the completion of the incomplete data in the merged backup data includes: based on a preset search algorithm, searching for business information that meets the business constraint conditions from possible business information as the completion information. The completion information includes the business processing status, and optionally, when the business is a transaction business, the completion information may also include a fund amount, etc.

[0072] The preset search algorithm may include but is not limited to one of an enumeration algorithm, a depth-first search, a breadth-first search, an A* algorithm, a backtracking algorithm, a Monte Carlo tree search, and a hash function.

[0073] Taking the preset search algorithm as a depth-first search as an example, the method of determining, based on the preset search algorithm, one processing state that meets the preset constraint condition among all possible processing states of the business data in the backup data as the processing state corresponding to the business data in the merged backup data may include: establishing a list of arranged business data, a list of business data to be arranged, and a search tree, and cyclically executing specified steps until the list of business data to be arranged is empty, wherein before cyclically executing the specified steps, the list of arranged business data is empty, and the list of business data to be arranged stores at least part of the business data in the merged backup data;

[0074] Wherein, the specifying step includes:

[0075] Take out a business data from the list of business data to be arranged, and select a possible business processing state for the business data;

[0076] Adding the service data and the service processing status corresponding to the service data to the end of the arranged service data list;

[0077] Determine whether all the service data in the compiled service data list meet the preset constraint conditions;

[0078] If satisfied, return to the step of taking out a service data from the list of service data to be arranged until the list of service data to be arranged is empty;

[0079] If not satisfied, the arranged service data list is rolled back one level (i.e. the service data just added to the end of the arranged service data list and its processing status are deleted), and the step of taking out a service data from the service data list to be arranged is returned to be executed.

[0080] It is equivalent to building a search tree based on all the business data in the list of business data to be arranged. The root node of the search tree is empty. One business data in the list of business data to be arranged corresponds to a leaf node in the search tree. When the list of business data to be arranged is empty, it reaches the bottom of the search tree and completes the determination of the processing order and processing status of the business data.

[0081] Taking transaction data as an example, the backup transaction data may contain incomplete transactions (only containing pre-transaction data), and the transaction order is inconsistent with the data of the primary node. Directly restoring the backup transaction data to the database of the backup node may break the system constraints (preset constraints) due to the correlation between transactions (correlation between account limits), such as the scenarios shown in Table 1 or Table 2.

[0082] Table 1

[0083]

[0084] As shown in Table 1, since the backup data source of the standby node lacks the transaction status of the first transaction (the transaction with sequence 2 in Table 1), the final balance of the database of the restored standby node is negative (-20), breaking the constraint that the account system balance cannot be 0, and ultimately leading to recovery failure.

[0085] Table 2

[0086]

[0087] As shown in Table 2, since the order of the first transaction (sequence 2) and the second transaction (sequence 3) in the backup data source of the standby node is chaotic, although the final balance in the database of the restored standby node is 0, which is consistent with that in the database of the primary node, a negative balance (-20) still occurs during the recovery process, which still breaks the constraint that the balance cannot be negative.

[0088] Since "the amount of data contained in the database of the primary node ≥ the amount of data contained in the backup data source of the standby node ≥ the amount of data saved on the user side", the database of the standby node cannot be restored to the original state of the database of the primary node, but the transaction data missing from the database of the standby node (transaction sequence and transaction status) is limited. It can be fully searched through a preset search algorithm to infer a reasonable sequence and status, and then restored to the database of the standby node. The algorithm that determines the transaction sequence and transaction status through search can be called an orchestration algorithm.

[0089] For an application scenario where the merged backup data is transaction data, the process of using a depth-first search algorithm to determine the transaction order and transaction status of the transaction data in the merged backup data may include:

[0090] (1) Building a search tree: querying the current account limit of the database of the standby node; establishing a list of scheduled transactions, which is initially empty; and establishing a list of transactions to be scheduled, which initially contains all transaction data in the merged backup data.

[0091] (2) Select a transaction from the list of transactions to be scheduled, then select a state from all possible transaction states of the transaction, and then add it to the end of the list of scheduled transactions.

[0092] It should be noted that if the transaction is a complete transaction, the transaction status is certain; if the transaction is an incomplete transaction, the transaction status may be success or failure.

[0093] (3) After adding a transaction to the end of the scheduled transaction list, based on the current account balance, the transactions in the scheduled transaction list are calculated in turn to see if they meet the preset constraints. The specific rules are as follows:

[0094] If the trial calculation result after the newly added transaction is that the account balance is negative or exceeds the limit (preset constraint condition), the trial calculation fails;

[0095] If the trial calculation result after the newly added transaction is that the account balance is inconsistent with the post-transaction balance of the backup transaction (another preset constraint condition), the trial calculation fails;

[0096] Other transaction continuity checks set by the business system. If the check fails, the trial calculation fails, etc.

[0097] (4) Proceed to the next step based on the calculation results

[0098] If all transactions in the arranged transaction list are successfully calculated, the search continues to the next level according to (2);

[0099] If the trial calculation fails and the current layer still has other options according to the algorithm (2), then replace it with another option for trial calculation;

[0100] If the trial fails and the current layer has no other options according to the algorithm (2), then return to the previous layer.

[0101] (5) When the list of transactions to be arranged is empty, the bottom of the search tree is reached, and the arrangement of the processing order and processing status of the merged backup data (transaction data) is completed.

[0102] The following is a specific example to illustrate the process of using the above-mentioned depth-first search algorithm to determine the processing order and processing status of backup transaction data.

[0103] Assume that the current account balance stored in the database of the standby node is 100, and the preset constraint is that the balance cannot be less than 0. The backup transaction data merged to remove duplicate data is shown in Table 3 (only the transaction amount and transaction status are shown here).

[0104] Table 3

[0105] Timing Transaction amount Transaction Status Balance after transaction 1 +10 ？ ？ 2 +20 success 120 3 -30 success 100

[0106] The results of searching by constructing a search tree based on the depth-first search algorithm are as follows Figure 6 As shown. Figure 6 In the figure, the branch with a cross under the leaf node indicates the search branch that does not meet the preset constraints, and the branch with a check mark under the leaf node indicates the search branch that meets the preset constraints, and this branch is the transaction order and transaction status result finally determined for the backup transaction data.

[0107] pass Figure 6 It can be seen that for the backup transaction data shown in Table 3, the transaction order and transaction status results determined by the depth-first search algorithm can be shown in Table 4.

[0108] Table 4

[0109] Timing Transaction amount Transaction Status Balance after transaction 2 +20 success 120 1 +10 success 110 3 -30 success 100

[0110] It can be understood that after determining the transaction sequence and transaction status as shown in Table 4, the backup transaction data can be correctly restored to the database of the standby node according to the transaction sequence and transaction status in Table 4.

[0111] Figure 2 The embodiment shown provides a disaster recovery method for business data. In addition to the asynchronous replication method adopted in the related art for synchronization, on the one hand, before the primary node performs business processing according to the business request, the first data containing data associated with the business processing logic and the unique identifier of the business request is backed up to the standby node; on the other hand, when the business processing is completed, the second data containing the unique identifier and the data determined according to the business processing is backed up to the standby node, rather than just performing asynchronous backup as described in the prior art. Therefore, in the data recovery stage, the target first data and the target second data corresponding to the target data recovery period can be screened out from the standby node, and the missing business data in the standby node can be determined according to the business processing logic, the target first data and the target second data, and the missing business data can be restored, thereby avoiding the loss of business data when the primary node fails.

[0112] Corresponding to the above method embodiment, the embodiment of the present application also provides a disaster recovery device for business data, which is applied to a backup node of a business system. The business system also includes a master node, which is used to perform business processing according to a business request to obtain business data, such as Figure 7 As shown, the device may include: a first backup module 701 , a second backup module 702 and a data recovery module 703 .

[0113] The first backup module 701 is used to back up first data corresponding to the business request before the master node performs business processing according to the business request, wherein the first data includes data associated with the business processing logic and at least includes a unique identifier of the business request.

[0114] The second backup module 702 is used to back up second data corresponding to the business request when the business processing is completed, wherein the second data includes the unique identifier and data determined according to the business processing.

[0115] In one embodiment, the second backup module 702 can be used to back up the second data when the master node generates the second data. Specifically, the service request can be processed by the server of the master node, and before the service processing result is returned to the user, the second data can be sent to the backup data source in the standby node, so that the standby node backs up the second data. Of course, the first data and the second data can also be saved in the database of the master node.

[0116] In another embodiment, the second backup module 702 can be used to: when the master node determines the business data corresponding to the query request, back up the second data corresponding to the business request. Specifically, the processing status query request of the target business can be received by the server of the master node, and the second data can be queried from the database of the master node, wherein the second data includes the business data generated after the target business is processed and the processing status of the target business.

[0117] The data recovery module 703 is used to filter out the target first data and the target second data corresponding to the target data recovery period during the data recovery phase, determine the missing business data in the standby node according to the business processing logic, the target first data and the target second data, and recover the missing business data.

[0118] In one embodiment, the target data recovery period is determined based on the time when the primary node fails, and specifically can be a time period within a preset time before the primary node fails (e.g., within 30 minutes before the failure). Optionally, the target data recovery period includes the primary node's failure start time. Optionally, the target data recovery period can also include a period of time within a preset time after the primary node's failure start time (e.g., 30 minutes before the failure to 10 minutes after the failure), so as to perform a more comprehensive recovery of the missing data in the backup node's database.

[0119] In another embodiment, the target data recovery period is determined according to the time when the data recorded in the database of the standby node lags behind the data recorded in the database of the primary node.

[0120] Since there may be duplicate backup data in the target first data and the target second data extracted from the backup data source of the standby node, the data recovery module 703 can first merge the target first data and the target second data based on the unique identifier of the business request to remove duplicate data and obtain merged backup data, thereby reducing the amount of data that needs to be restored to the database of the standby node and improving subsequent recovery efficiency.

[0121] Optionally, the first data and the second data are backed up synchronously; the standby node is also used to asynchronously back up the business data of the primary node.

[0122] There is also a situation where part of the business data in the target first data and the target second data extracted from the backup data source of the standby node may have been written into the database of the standby node. Therefore, the data recovery module 703 can also compare the merged backup data with the backed-up business data in the standby node, and discard the part of the merged backup data corresponding to the backed-up business data, so as to further reduce the amount of data that needs to be restored to the database of the standby node, thereby further improving the subsequent recovery efficiency.

[0123] Furthermore, since the processing order of the business data stored in the backup data source of the standby node may be inconsistent with the processing order of the business data stored in the database of the primary node, and the processing status of the business data stored in the backup data source of the standby node may be unknown, the data recovery module 703 can first arrange the merged backup data according to the business processing logic; and generate the missing business data in the standby node based on the arranged merged backup data.

[0124] The arranging the merged backup data according to the business processing logic includes: determining a business processing sequence of business requests corresponding to the merged backup data, and / or completing incomplete data in the merged backup data.

[0125] As an example, determining the service processing sequence of the service request corresponding to the merged backup data includes: searching for a service processing sequence that meets the service constraint condition from possible service processing sequences based on a preset search algorithm.

[0126] Specifically, based on a preset search algorithm, one processing sequence that meets the preset constraint condition among all possible processing sequences of the business data in the backup data can be determined as the processing sequence corresponding to the business data in the merged backup data.

[0127] As an example, the completion of the incomplete data in the merged backup data includes: based on a preset search algorithm, searching for business information that meets the business constraint conditions from possible business information as the completion information. The completion information includes the business processing status, and optionally, when the business is a transaction business, the completion information may also include a fund amount, etc.

[0128] The preset search algorithm may include but is not limited to one of an enumeration algorithm, a depth-first search, a breadth-first search, an A* algorithm, a backtracking algorithm, a Monte Carlo tree search, and a hash function.

[0129] Figure 7 The ambition shown can be achieved Figure 2 The method shown in the figure can achieve the same technical effect, so this specification is Figure 7 The device shown is described briefly. For details, please refer to the above description of Figure 2 Description of the illustrated method embodiment.

[0130] The embodiment of the present application also provides a business system, which may include a master node and a standby node, wherein the master node is used to perform business processing according to a business request to obtain business data; the standby node includes Figure 7 The device shown.

[0131] The present application provides a business system that can realize Figure 2 The disaster recovery method for business data shown in the figure can achieve the same technical effect and will not be repeated here.

[0132] It should be noted that since the content executed by the business system embodiment is similar to that of the method embodiment, the description of the business system embodiment in this document is relatively brief, and please refer to the method embodiment for relevant details.

[0133] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application may adopt the form of a computer program product implemented in one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that include computer-usable program code.

[0134] 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 generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. 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.

[0135] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate 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 A function specified in one or more boxes.

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

[0137] It should be noted that the various embodiments in this application are described in a related manner, and the same or similar parts between the various embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0138] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of more restrictions, the elements defined by the sentence "comprises a ..." do not exclude the existence of other identical elements in the process, method, commodity or device including the elements.

[0139] The above are only embodiments of the present application and are not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included within the scope of the claims of the present application.

Claims

1. A disaster recovery method for business data, applied to a backup node of a business system, wherein the business system further comprises a master node, and the master node is used to perform business processing according to a business request to obtain business data; characterized in that: The method comprises: Before the master node performs service processing according to the service request, backing up first data corresponding to the service request, wherein the first data includes data associated with the service processing logic and at least includes a unique identifier of the service request; When the business processing is completed, backing up second data corresponding to the business request, wherein the second data includes the unique identifier and data determined according to the business processing; In the data recovery phase, the target first data and the target second data corresponding to the target data recovery period are screened out, the missing business data in the standby node is determined according to the business processing logic, the target first data and the target second data, and the missing business data is recovered.

2. The method according to claim 1, characterized in that: When the business processing is completed, backing up the second data corresponding to the business request includes: When the master node generates the second data, backing up the second data; and / or, When the master node determines the service data corresponding to the query request, the second data corresponding to the service request is backed up.

3. The method according to claim 1, characterized in that The determining the missing service data in the standby node according to the service processing logic, the target first data and the target second data includes: Based on the unique identifier of the business request, the target first data and the target second data are merged to obtain merged backup data; Arranging the merged backup data according to the business processing logic; The business data missing in the standby node is generated based on the arranged merged backup data.

4. The method according to claim 3, characterized in that The method of backing up the first data and the second data is synchronous backup; the standby node is also used to asynchronously back up the business data of the primary node. Before arranging the merged backup data according to the business processing logic, the method also includes: The merged backup data is compared with the backed-up business data in the standby node, and a portion of the merged backup data corresponding to the backed-up business data is discarded.

5. The method according to claim 3, characterized in that: The arranging the merged backup data according to the business processing logic includes: Determine a service processing order of service requests corresponding to the merged backup data, and / or complete incomplete data in the merged backup data.

6. The method according to claim 5, characterized in that The determining of the business processing order of the business requests corresponding to the merged backup data includes: Based on a preset search algorithm, search for a business processing sequence that meets the business constraint conditions from possible business processing sequences; The completing the incomplete data in the merged backup data includes: Based on a preset search algorithm, business information that meets the business constraints is searched from possible business information as completion information.

7. The method according to claim 6, characterized in that The preset search algorithm includes one of an enumeration algorithm, a depth-first search, a breadth-first search, an A* algorithm, a backtracking algorithm, a Monte Carlo tree search, and a hash function.

8. The method according to any one of claims 1 to 7, characterized in that: The business request is a transaction request; The second data includes transaction amount, payment direction, transaction status and account balance.

9. A disaster recovery device for business data, applied to a backup node of a business system, wherein the business system further comprises a master node, and the master node is used to perform business processing according to a business request to obtain business data, characterized in that: The device comprises: A first backup module, configured to back up first data corresponding to the service request before the master node performs service processing according to the service request, wherein the first data includes data associated with the service processing logic and at least includes a unique identifier of the service request; A second backup module, configured to back up second data corresponding to the service request when the service processing is completed, wherein the second data includes the unique identifier and data determined according to the service processing; The data recovery module is used to screen out the target first data and the target second data corresponding to the target data recovery period in the data recovery phase, determine the missing business data in the standby node according to the business processing logic, the target first data and the target second data, and recover the missing business data.

10. A business system, characterized in that: The business system includes a master node and a standby node, wherein the master node is used to perform business processing according to the business request and obtain business data; The standby node comprises the apparatus according to claim 9.

Images