Cross-cloud service disaster recovery method and device, storage medium and computer equipment

Abstract

According to the cross-cloud service disaster recovery method and device, the storage medium and the computer equipment, when it is detected that disaster recovery switching of the main cloud cluster is triggered, the current latest transaction snapshot file is loaded. The transaction snapshot file is used for recording global transaction summary information and unfinished transaction detail data, so that the defect that in an existing scheme, only final data of a database is synchronized, and a transaction intermediate state and a global context are lost is effectively overcome. Furthermore, by determining a snapshot time point and additionally recording incremental log data from the time point to a fault occurrence period, all the unfinished transactions are accurately and quickly identified, and then the latest state of each unfinished transaction is judged one by one. On the basis, a recovery instruction corresponding to the state of each uncompleted transaction is automatically executed, so that the original suspended intermediate data due to state loss can be re-associated to a correct transaction context, full-automatic second-level accurate recovery is realized, and the disaster recovery efficiency is improved.

Description

Technical Field

[0001] This application relates to the field of distributed technology, and in particular to a disaster recovery method, apparatus, storage medium and computer equipment for cross-cloud services. Background Technology

[0002] As businesses expand and globalization progresses, cross-cloud deployment has become the mainstream choice for microservice architectures. To avoid the risks of being tied to a single cloud vendor and to meet cross-regional business needs, enterprises generally distribute their services across multiple public or hybrid cloud platforms. While this architecture improves elasticity, it also presents significant challenges to cross-cloud high availability and data consistency.

[0003] However, existing standalone cross-cloud disaster recovery solutions struggle to guarantee transaction consistency. These solutions only synchronize the final database data and instance snapshots, losing the intermediate states and global context of distributed transactions. After a disaster recovery switchover, intermediate data from incomplete transactions remains suspended because their transaction states cannot be linked, resulting in low efficiency in disaster recovery. Summary of the Invention

[0004] The purpose of this application is to address at least one of the aforementioned technical shortcomings, particularly the existing technology that only synchronizes the final database data and instance snapshots, while losing the intermediate state and global context of distributed transactions. After disaster recovery failover, intermediate data of incomplete transactions remains suspended because their transaction states cannot be associated, resulting in low efficiency of disaster recovery.

[0005] Firstly, this application provides a disaster recovery method for cross-cloud services, the method comprising:

[0006] Disaster recovery trigger detection is performed on the main cloud cluster. When a disaster recovery switchover of the main cloud cluster is triggered, the latest transaction snapshot file is loaded from the preset transaction snapshot system. The transaction snapshot file is used to record global transaction summary information and details of incomplete transactions.

[0007] Determine the snapshot time of the transaction snapshot file, and obtain log data after the snapshot time from a preset log synchronization system;

[0008] Identify incomplete transactions in the transaction snapshot file and the log data;

[0009] For each incomplete transaction, determine the current transaction state of the incomplete transaction, and execute the corresponding recovery instruction according to the transaction state to update the transaction state of the incomplete transaction.

[0010] In one embodiment, the disaster recovery trigger detection of the main cloud cluster includes:

[0011] Monitor the heartbeat interruption time, transaction failure rate, and core service downtime rate of the main cloud cluster;

[0012] If the heartbeat interruption time exceeds the first preset threshold, the disaster recovery switch of the main cloud cluster is triggered.

[0013] If the transaction failure rate exceeds the second preset threshold, the disaster recovery switch of the main cloud cluster will be triggered.

[0014] If the downtime rate of the core services exceeds the third preset threshold, the disaster recovery switch of the main cloud cluster will be triggered.

[0015] In one embodiment, when the transaction status is pending rollback or pending commit, the step of executing the corresponding recovery instruction according to the transaction status to update the transaction status of the incomplete transaction includes:

[0016] Identify the service providers involved in the incomplete transaction;

[0017] If the transaction status is pending rollback, a rollback instruction indicating that the incomplete transaction is to be rolled back is sent to each participating service provider, and the transaction status of the incomplete transaction is updated to rolled back.

[0018] If the transaction status is pending, a commit instruction is sent to each participating service provider to indicate that the incomplete transaction is to be committed, and the transaction status of the incomplete transaction is updated to committed.

[0019] In one embodiment, when the transaction status is "ready," the step of executing the corresponding recovery instruction based on the transaction status to update the transaction status of the incomplete transaction includes:

[0020] Identify the participating service providers corresponding to the incomplete transaction and determine whether the incomplete transaction meets the commit conditions;

[0021] If the conditions are met, a commit instruction is sent to each participating service provider to indicate that the incomplete transaction is being committed, and the transaction status of the incomplete transaction is updated to committed.

[0022] If the conditions are not met, a rollback instruction indicating that the incomplete transaction has been rolled back is sent to each participating service provider, and the transaction status of the incomplete transaction is updated to "rolled back".

[0023] In one embodiment, when the transaction status is "to be prepared," the step of executing the corresponding recovery instruction based on the transaction status to update the transaction status of the incomplete transaction includes:

[0024] Identify the participating service providers corresponding to the incomplete transaction and send a preparation instruction to each participating service provider indicating that the incomplete transaction is ready;

[0025] Determine whether the incomplete transaction meets the commit conditions;

[0026] If the conditions are met, a commit instruction is sent to each participating service provider to indicate that the incomplete transaction is being committed, and the transaction status of the incomplete transaction is updated to committed.

[0027] If the conditions are not met, a rollback instruction indicating that the incomplete transaction has been rolled back is sent to each participating service provider, and the transaction status of the incomplete transaction is updated to "rolled back".

[0028] In one embodiment, the log synchronization process of the log synchronization system includes:

[0029] Retrieve unsynchronized main cloud transactions in the main cloud cluster;

[0030] Extract the core fields of the main cloud transaction to obtain a lightweight transaction, and compress the lightweight transaction to obtain a transaction log;

[0031] Based on the priority of the transaction logs to be synchronized, determine the bandwidth allocated to each transaction log to be synchronized, and synchronize each transaction log to be synchronized based on the bandwidth allocated to each transaction log to be synchronized.

[0032] In one embodiment, the process of generating snapshot files in the transaction snapshot system includes:

[0033] Get the current transaction concurrency of the main cloud cluster;

[0034] The snapshot period of the transaction snapshot system is dynamically adjusted according to the transaction concurrency.

[0035] At each snapshot interval, global transaction summary information and incomplete transaction details of the main cloud cluster are obtained, and a snapshot file is generated based on the global transaction summary information and the incomplete transaction details.

[0036] Record the snapshot time of the snapshot file and store the snapshot file and its snapshot time in the transactional snapshot system.

[0037] Secondly, this application provides a disaster recovery device for cross-cloud services, the device comprising:

[0038] The snapshot acquisition module is used to detect disaster recovery triggers in the main cloud cluster. When a disaster recovery switchover of the main cloud cluster is triggered, the latest transaction snapshot file is loaded from the preset transaction snapshot system. The transaction snapshot file is used to record global transaction summary information and details of incomplete transactions.

[0039] The log acquisition module is used to determine the snapshot time of the transaction snapshot file and acquire log data after the snapshot time from a preset log synchronization system.

[0040] The transaction identification module is used to identify incomplete transactions in the transaction snapshot file and the log data;

[0041] The disaster recovery module is used to determine the current transaction status of each incomplete transaction, execute corresponding recovery instructions based on the transaction status, and update the transaction status of the incomplete transaction.

[0042] Thirdly, this application provides a storage medium storing computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of the cross-cloud service disaster recovery method as described in any of the above embodiments.

[0043] Fourthly, this application provides a computer device, including: one or more processors, and a memory;

[0044] The memory stores computer-readable instructions, and when the one or more processors execute the computer-readable instructions, they perform the steps of the disaster recovery method for cross-cloud services as described in any of the above embodiments.

[0045] As can be seen from the above technical solutions, the embodiments of this application have the following advantages:

[0046] The disaster recovery method, apparatus, storage medium, and computer equipment provided in this application for cross-cloud services load the latest transaction snapshot file when a disaster recovery switchover of the main cloud cluster is detected. This transaction snapshot file records global transaction summary information and details of incomplete transactions, effectively compensating for the shortcomings of existing solutions that only synchronize the final database data and lose intermediate transaction states and global context. Furthermore, by determining the snapshot time point and supplementing incremental log data from that time to the fault occurrence, a mechanism combining transaction snapshots and incremental logs is introduced to accurately and quickly identify all incomplete transactions, and then determine the latest state of each incomplete transaction. Based on this, recovery instructions corresponding to the state are automatically executed for each incomplete transaction, allowing intermediate data that was previously suspended due to state loss to be re-associated with the correct transaction context. This not only fundamentally ensures transaction consistency but also transforms the disaster recovery process from the manual intervention and long waiting times required by traditional solutions into fully automated, second-level precise recovery, thereby improving the efficiency of disaster recovery. Attached Figure Description

[0047] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0048] Figure 1 A flowchart illustrating a cross-cloud service disaster recovery method provided in this application embodiment;

[0049] Figure 2 A flowchart illustrating the execution of corresponding recovery instructions based on transaction status, provided for embodiments of this application;

[0050] Figure 3 A flowchart illustrating the framework of a cross-cloud service disaster recovery method provided in this application embodiment;

[0051] Figure 4 A schematic diagram of a disaster recovery device for cross-cloud services provided in this application embodiment;

[0052] Figure 5 This is an internal structural diagram of a computer device provided in an embodiment of this application. Detailed Implementation

[0053] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0054] In one embodiment, this application provides a disaster recovery method across cloud services, and the following embodiments illustrate the application of this method to a disaster recovery cloud cluster. Figure 1 As shown, this application provides a disaster recovery method for cross-cloud services, the method comprising:

[0055] S101: Perform disaster recovery trigger detection on the main cloud cluster. When a disaster recovery switchover of the main cloud cluster is triggered, load the latest transaction snapshot file from the preset transaction snapshot system.

[0056] The main cloud cluster refers to the core component of a cloud computing infrastructure consisting of multiple server nodes, used to host major business applications and data processing tasks. The transaction snapshot system records an overview of all transactions in the main cloud cluster and detailed information about incomplete transactions at a specific point in time. A transaction snapshot file is a file consisting of an overview of all transactions in the main cloud cluster and detailed information about currently incomplete transactions.

[0057] In this step, when the main cloud cluster starts up, disaster recovery trigger detection is performed on the main cloud cluster in real time. That is, when a poor state or failure is detected in the main cloud cluster, the disaster recovery switchover process of the main cloud cluster is triggered, and the corresponding transaction snapshot system of the main cloud cluster is determined. The latest generated transaction snapshot file is loaded from that transaction snapshot system. Specifically, each generated transaction snapshot file records its corresponding snapshot time. Based on the snapshot times of each transaction snapshot file, the transaction snapshot file closest to the current time can be determined.

[0058] Furthermore, when performing disaster recovery trigger detection on the primary cloud cluster, the health status of the primary cloud cluster can be evaluated in real time using some pre-defined indicator parameters. When the health status meets the expectations, disaster recovery failover is not triggered. When the health status does not meet the expectations, disaster recovery failover is triggered, and the latest transaction snapshot file is obtained. Specifically, when evaluating the health status of the primary cloud cluster, performance indicators such as request response time and transaction success rate can be calculated, and the health status of the primary cloud cluster is comprehensively evaluated based on these indicators.

[0059] S102: Determine the snapshot time of the transaction snapshot file and obtain log data after the snapshot time from the preset log synchronization system.

[0060] The snapshot time refers to the specific point in time when the transaction snapshot file was generated. The log synchronization system is used to record and synchronize transaction operations of the main cloud cluster. Log data refers to the data composed of log records recorded in the log synchronization system after the snapshot time.

[0061] In this step, after loading the newly generated transaction snapshot file, the snapshot time of the transaction snapshot file is determined, and logs recorded after the snapshot time are obtained from the preset log synchronization system to form log data.

[0062] Understandably, log synchronization systems record every transaction operation of the main cloud cluster at every moment. If disaster recovery relies solely on log data, it would require replaying each log line by line from the earliest record. This process is time-consuming and inefficient in cross-cloud scenarios (where log volumes can reach millions). Therefore, this solution only requires acquiring log data generated after the snapshot time. Data before the snapshot time is recovered using incomplete transactions recorded in the transaction snapshot file. This combination ensures both the accuracy and reliability of disaster recovery while improving its efficiency.

[0063] S103: Identify incomplete transactions in transaction snapshot files and log data.

[0064] Incomplete transactions refer to transaction operations in the main cloud cluster that failed to be completed normally due to faults or other abnormal situations.

[0065] In this step, the transaction snapshot file and log data are analyzed. By extracting the transaction status from the transaction snapshot file, incomplete transactions are identified. Then, transactions marked "uncommitted" or "not rolled back" are searched in the log data to determine incomplete transactions within the log data. Finally, the incomplete transactions in the transaction snapshot file and log data are obtained.

[0066] S104: For each incomplete transaction, determine the current transaction state of the incomplete transaction, and execute the corresponding recovery instruction according to the transaction state to update the transaction state of the incomplete transaction.

[0067] Transaction status refers to the specific stage a transaction is in during execution. Examples include: pending preparation, pending rollback, rolled back, pending commit, and committed. Transaction snapshot files are used to record global transaction summary information and details of incomplete transactions.

[0068] In this step, for each incomplete transaction, its current transaction state can first be determined. This can be achieved by analyzing relevant information in the transaction snapshot file and log data. When the transaction state of the incomplete transaction is determined, the corresponding recovery instructions will be executed according to the transaction state. For example, if the transaction is in a "pending commit" state, it may be possible to recommit the transaction to complete its operation, or roll back the transaction and re-execute it to complete its operation.

[0069] Furthermore, after executing the corresponding recovery instructions and updating the transaction status of each incomplete transaction, this method also includes a verification process. Specifically, it retrieves the list of recovered transactions from the disaster recovery cloud cluster and sends data verification requests to each participating service provider. For example, it requests the payment service whether the deduction amount for transaction ID=xxx is 100 yuan and the inventory service whether the deduction inventory for transaction ID=xxx is 1 item. The data returned by each participating service provider is compared with the expected transaction result. If they match, the verification passes, and the transaction result is pushed to the downstream business system. If the verification fails, a compensation transaction is automatically triggered, and the commit instruction is resent. If the verification fails after three compensation instructions, the operations and maintenance personnel are notified to intervene and ensure data consistency. In addition, after the disaster recovery switchover, the IP address needs to be resolved from the primary cloud cluster to the disaster recovery cloud cluster. This process can be achieved through DNS resolution services.

[0070] In this embodiment, when a disaster recovery switchover of the main cloud cluster is triggered, the latest transaction snapshot file is loaded. This transaction snapshot file records global transaction summary information and details of incomplete transactions, effectively compensating for the shortcomings of existing solutions that only synchronize the final database data and lose intermediate transaction states and global context. Furthermore, by determining the snapshot time point and supplementing incremental log data from that time to the fault occurrence, a mechanism combining transaction snapshots and incremental logs is introduced to accurately and quickly identify all incomplete transactions, and then determine the latest state of each incomplete transaction one by one. Based on this, recovery instructions corresponding to the state are automatically executed for each incomplete transaction, allowing intermediate data that was previously suspended due to state loss to be re-associated with the correct transaction context. This not only fundamentally ensures transaction consistency but also transforms the disaster recovery process from the manual intervention and long waiting time required by traditional solutions into a fully automated, second-level precise recovery, thereby improving the efficiency of disaster recovery.

[0071] In one embodiment, disaster recovery trigger detection is performed on the main cloud cluster, including:

[0072] S1: Monitor the heartbeat interruption time, transaction failure rate, and core service downtime rate of the main cloud cluster.

[0073] S2: If the heartbeat interruption time exceeds the first preset threshold, the disaster recovery switch of the main cloud cluster will be triggered.

[0074] S3: If the transaction failure rate exceeds the second preset threshold, the disaster recovery switch of the main cloud cluster will be triggered.

[0075] S4: If the failure rate of core services exceeds the third preset threshold, the disaster recovery switch of the main cloud cluster will be triggered.

[0076] The heartbeat interruption time refers to the time since the last heartbeat packet was sent to the disaster recovery coordinator. The first, second, and third preset thresholds are empirical values ​​and can be adjusted according to actual conditions. In one example, the first preset threshold can be set to 3 seconds, the second preset threshold to 5%, and the third preset threshold to 50%.

[0077] In this embodiment, the heartbeat interruption time, transaction failure rate, and core service downtime ratio of the main cloud cluster are monitored in real time. The performance of the main cloud cluster is then evaluated from these three aspects. If any one of these aspects fails to meet the requirements, the performance of the main cloud cluster is considered insufficient to support the current business needs, and disaster recovery failover of the main cloud cluster is triggered. This automatically triggers disaster recovery failover when the main cloud cluster fails or its health status is poor, quickly restoring normal business processing.

[0078] Specifically, before implementing monitoring of the main cloud cluster's heartbeat interruption time, transaction failure rate, and core service downtime ratio, a monitoring system can be deployed within the main cloud cluster. This monitoring system collects data such as heartbeat signals, transaction processing status, and service operation status in real time by installing sensors and agents on various nodes and core services. The heartbeat signal is used to detect whether the communication between the main cloud cluster and the disaster recovery coordinator is normal; the transaction failure rate measures the stability of the main cloud cluster by statistically analyzing the ratio of successful to failed transactions; and the core service downtime ratio assesses the overall health of the main cloud cluster by monitoring the operational status of critical services.

[0079] In one embodiment, when the transaction status is pending rollback or pending commit, the corresponding recovery instruction is executed according to the transaction status to update the transaction status of the incomplete transaction, including:

[0080] S1: Determine the service providers involved in the incomplete transaction.

[0081] S2: If the transaction status is pending rollback, send a rollback instruction to each participating service provider indicating that the incomplete transaction has been rolled back, and update the transaction status of the incomplete transaction to rolled back.

[0082] S3: If the transaction status is pending, send a commit instruction to each participating service provider to indicate that the incomplete transaction has been committed, and update the transaction status of the incomplete transaction to committed.

[0083] In one embodiment, when the transaction status is "ready," the corresponding recovery instruction is executed according to the transaction status to update the transaction status of the incomplete transaction, including:

[0084] S1: Determine the participating service provider corresponding to the incomplete transaction and determine whether the incomplete transaction meets the commit conditions.

[0085] S2: If satisfied, send a commit instruction to each participating service provider indicating that the incomplete transaction is being committed, and update the transaction status of the incomplete transaction to committed.

[0086] S3: If not satisfied, send a rollback instruction to each participating service provider indicating that the incomplete transaction has been rolled back, and update the transaction status of the incomplete transaction to rolled back.

[0087] In one embodiment, when the transaction status is "pending preparation," a corresponding recovery instruction is executed according to the transaction status to update the transaction status of the incomplete transaction, including:

[0088] S1: Determine the participating service providers corresponding to the incomplete transaction and send a preparation instruction to each participating service provider indicating that the incomplete transaction is ready.

[0089] S2: Determine whether the incomplete transaction meets the commit conditions.

[0090] S3: If satisfied, send a commit instruction to each participating service provider indicating that the incomplete transaction is being committed, and update the transaction status of the incomplete transaction to committed.

[0091] S4: If not satisfied, send a rollback instruction to each participating service provider indicating that the incomplete transaction has been rolled back, and update the transaction status of the incomplete transaction to rolled back.

[0092] Among them, participating service providers refer to the service nodes in the disaster recovery cloud cluster that are involved in the incomplete transaction. For example, when the incomplete transaction is placing an order for a product, participating service providers may include order services, payment services, inventory services, etc.

[0093] In the above embodiments, the participating service providers corresponding to the incomplete transaction can first be determined, specifically based on the configuration information of the incomplete transaction. Then, the service instances corresponding to each participating service provider in the disaster recovery cloud cluster are started. Next, different recovery commands are sent to these service instances according to their current transaction states. Finally, the transaction state of the incomplete transaction is updated. This mechanism effectively avoids data redundancy, loss, or errors caused by incomplete transactions, thereby improving the reliability and stability after disaster recovery failover.

[0094] Specifically, the main content of the preparation phase for the incomplete transaction is to register the transaction and call the interfaces of each participating service provider. When determining whether the incomplete transaction meets the commit conditions, the coordinator can summarize the status of each participating service provider. If the status of each participating service provider is that the commit instruction has been successfully sent, the incomplete transaction is considered to meet the commit conditions; otherwise, the incomplete transaction is considered to not meet the commit conditions.

[0095] In one embodiment, such as Figure 2 As shown, Figure 2 This is a flowchart illustrating the execution of corresponding recovery instructions based on the transaction status, provided as an embodiment of this application. Figure 2 In this context, "participant" refers to the service provider, "transaction state snapshot" refers to the transaction snapshot file, and "current transaction stage" refers to the current transaction state. The "Rollback" command indicates a rollback instruction, and the "Commit" command indicates a commit instruction.

[0096] In one embodiment, the log synchronization process of the log synchronization system includes:

[0097] S1: Retrieve unsynchronized main cloud transactions in the main cloud cluster.

[0098] S2: Extract the core fields of the main cloud transaction to obtain the lightweight transaction, and compress the lightweight transaction to obtain the transaction log.

[0099] S3: Determine the bandwidth allocated to each transaction log to be synchronized based on the priority of the current transaction log to be synchronized, and synchronize each transaction log to be synchronized based on the bandwidth allocated to each transaction log to be synchronized.

[0100] Among them, core fields refer to those that play a crucial role in the execution and recovery of transactions within the main cloud. Priority is used to quantify the business importance corresponding to the transaction log.

[0101] In this embodiment, core fields of the main cloud transaction are extracted to obtain a lightweight transaction. The extraction process involves parsing and filtering transaction data, retaining key information and removing redundant data. Next, the lightweight transaction is compressed to obtain a transaction log. The compression process can employ standard compression algorithms to further reduce data transmission volume and improve synchronization efficiency. Finally, the bandwidth allocated to each transaction log to be synchronized is determined based on its priority. Priority determination can be based on transaction type, urgency, or business importance. Based on the allocated bandwidth, synchronization is performed on each transaction log to be synchronized. This ensures that high-priority transactions are processed first, optimizing resource utilization.

[0102] In one embodiment, the structure of the log synchronization system is shown in the table below, where the field names are the core fields:

[0103]

[0104] By storing transaction operations in the above structure, eliminating redundant fields, and reducing the size of individual log entries, lightweight transactions are obtained. Then, the Snappy compression algorithm can be used to compress the lightweight transactions to obtain the transaction log. Furthermore, during log synchronization, traditional HTTP / HTTPS is abandoned in favor of the QUIC protocol (a reliable transport protocol based on UDP). Its advantages include: firstly, 0-RTT connection establishment (50% reduction in initial connection latency, with no latency in subsequent connections); secondly, robustness against packet loss (a 5% packet loss rate increases transmission latency by only 10%, compared to 80% for HTTP); and thirdly, multiplexing (transmitting multiple transaction logs over a single connection, reducing connection overhead).

[0105] In addition, during the log synchronization process, a "synchronization + retry" mode is used for core transactions (such as payments and transactions) to ensure that logs are delivered. The retry interval is 10ms and a maximum of 3 retries are made. For non-core transactions (such as log statistics), an "asynchronous batch" mode is used (100 logs are synchronized in batches to reduce the number of connections).

[0106] Specifically, the priority of the transaction log can be set according to the importance of the transaction. For example, the transaction log can be divided into 3 levels, with the priority from high to low as follows:

[0107] 1. P0 (Core Transactions): Payment, transaction, account change (requires second-level synchronization, bandwidth is prioritized).

[0108] 2. P1 (Important Transaction): Order status update, inventory adjustment (must be synchronized within 5 seconds).

[0109] 3. P2 (Non-core transactions): Log statistics, user behavior analysis (can be synchronized within 10 seconds).

[0110] When determining the bandwidth allocated to each transaction log to be synchronized based on its priority, using the example above, core transactions are allocated 60% of the bandwidth, important transactions are allocated 30%, and non-core transactions are allocated 10%. For instance, in a cross-cloud payment scenario for e-commerce, 1000 P0 payment transactions are generated per second. Each lightweight transaction is 50 bytes. The synchronization bandwidth requirement is 1000 × 50 bytes = 50 KB / s = 0.4 Mbps, which only accounts for 6.7% of the allocated P0 bandwidth (6 Mbps), fully meeting the requirement.

[0111] In one embodiment, the process of generating snapshot files in a transactional snapshot system includes:

[0112] S1: Get the current transaction concurrency of the main cloud cluster.

[0113] S2: Dynamically adjust the snapshot period of the transaction snapshot system based on the transaction concurrency.

[0114] S3: At each snapshot period, obtain the global transaction summary information and incomplete transaction details of the main cloud cluster, and generate a snapshot file based on the global transaction summary information and incomplete transaction details.

[0115] S4: Record the snapshot time of the snapshot file and store the snapshot file and its snapshot time in the transactional snapshot system.

[0116] Transaction concurrency refers to the number of transactions running simultaneously in the main cloud cluster at a given moment. Snapshot period refers to the time interval at which transaction snapshot files are generated.

[0117] In this embodiment, the current transaction concurrency of the main cloud cluster can be obtained through a monitoring system. Then, based on the transaction concurrency level, the snapshot period of the transaction snapshot system is dynamically adjusted. When the concurrency is high, the snapshot period is shortened to save the state of the main cloud cluster more frequently, ensuring rapid recovery in the event of a failure and reducing the risk of data loss. When the concurrency is low, the snapshot period is extended to save resources. At each snapshot interval, global transaction summary information and incomplete transaction details of the main cloud cluster are obtained. The global transaction summary information can be obtained by statistically analyzing the status of all current transactions, while the incomplete transaction details are obtained by identifying incomplete transactions and obtaining their detailed information. Based on this information, a transaction snapshot file is generated, and the snapshot time of the transaction snapshot file is recorded. Finally, the transaction snapshot file and its snapshot time are stored in the transaction snapshot system for recovery operations when needed.

[0118] Specifically, the global transaction summary information is used to count the number of transactions in each transaction status, for example, "Prepared: 100, Pending Commit: 20, Pending Rollback: 5," which allows for a quick overview of the overall transaction status. Incomplete transaction details include transactions in the pending, prepared, pending commit, or pending rollback status, along with their detailed information. Each detail entry includes the global transaction ID, a list of service participants, participant status, and the current transaction status. It's important to note that completed transactions (committed or rolled back) are not included in the transaction snapshot file to reduce snapshot size.

[0119] Furthermore, when dynamically adjusting the snapshot period of the transaction snapshot system based on transaction concurrency, the snapshot period corresponding to a certain transaction concurrency can be determined according to pre-set mapping rules. For example, when the transaction concurrency is no more than 1,000 transactions, the snapshot period can be set to 1 second; when the transaction concurrency is between 1,000 and 5,000 transactions, the snapshot period can be set to 500 milliseconds; and when the transaction concurrency is greater than 5,000 transactions, the snapshot period can be set to 200 milliseconds.

[0120] In addition, after the main cloud coordinator generates a snapshot, the transactional snapshot system can synchronize to the disaster recovery coordinator via the QUIC protocol. The disaster recovery coordinator preloads the snapshot file into memory to avoid disk I / O latency during recovery. At the same time, the disaster recovery coordinator compares the snapshot with the main cloud snapshot periodically (every 10 seconds) and updates the snapshot data in memory to ensure data consistency.

[0121] In one embodiment, such as Figure 3 As shown, Figure 3 This is a flowchart illustrating the framework of a cross-cloud service disaster recovery method provided in an embodiment of this application. Figure 3 In this system, the cross-cloud transaction layer is responsible for executing cross-cloud distributed transactions, including the transaction initiator (the core service that triggers the transaction), transaction participants (other services participating in the transaction), and the global transaction coordinator (the master node, which uniformly schedules transaction preparation / commit / rollback). The lightweight log synchronization layer compresses the transaction logs of the main cloud and synchronizes them to the coordinator (disaster recovery node) of the disaster recovery cloud through a low-latency protocol, reducing bandwidth consumption. The transaction state snapshot layer periodically generates a "global state snapshot" of the main cloud transactions and preloads it to the disaster recovery coordinator, shortening the disaster recovery recovery time. The disaster recovery collaborative recovery layer triggers disaster recovery switchover when the main cloud is abnormal, automatically recovers incomplete transactions based on synchronized logs and snapshots, and starts disaster recovery service instances. The result verification layer verifies the consistency of transaction data after disaster recovery, ensures no duplicate commits / rollbacks, and pushes the correct results to downstream business systems.

[0122] In one embodiment, to better understand the technical solution of this application, taking the cross-cloud payment scenario of e-commerce as an example, specifically the scenario of "cross-cloud ordering, payment, and inventory deduction in e-commerce", the following provides an example of the disaster recovery process for this scenario (AWS represents cloud services):

[0123] 1. Normal transaction execution (main cloud cluster):

[0124] (1) When a user places an order in the APP, the order service (main cloud cluster) generates a global transaction ID=ALI-20241001120000-12345 and calls the main cloud coordinator to register the transaction.

[0125] (2) The main cloud coordinator sends a Try instruction to the payment service (AWS), the payment service freezes 100 yuan and returns "success"; it sends a Try instruction to the inventory service (private cloud), the inventory service locks 1 item and returns "success".

[0126] (3) The main cloud coordinator generates a lightweight log (content: ALI-20241001120000-12345, Try, PAY-AWS, STOCK-PRIVATE, 1, 1, 1696132800000, 0x12345678), which is synchronized to the disaster recovery coordinator (disaster recovery cloud cluster) via the QUIC protocol.

[0127] (4) The main cloud coordinator sends a Commit instruction to all participants, deducts 100 yuan from the payment service and 1 item from the inventory service, and returns "success"; generates a lightweight log of the Commit phase and synchronizes it to the disaster recovery coordinator.

[0128] (5) The main cloud coordinator generates a transaction snapshot every 500ms, which includes the transaction (status = committed), synchronizes it to the disaster recovery coordinator and preloads it into memory.

[0129] 2. Switchover triggered by main cloud anomaly:

[0130] (1) The main cloud cluster crashes due to network failure, the main cloud coordinator heartbeat is interrupted for 3 seconds, and the disaster recovery coordinator triggers disaster recovery switchover.

[0131] 3. Disaster recovery and collaborative restoration:

[0132] (1) The disaster recovery coordinator loads the snapshot in memory and finds an incomplete transaction ID=ALI-20241001120001-67890 (status=ready, all participants tried successfully).

[0133] (2) The disaster recovery coordinator starts the disaster recovery order service (AWS) and payment service (AWS) instances and configures automatic loading (CPU=2 cores, memory=4GB).

[0134] (3) The disaster recovery coordinator sends a Commit command to the payment service (AWS) and the inventory service (private cloud), and the results are returned after both are executed successfully.

[0135] (4) The result verification layer requests “Transaction 67890 Deduct Amount” from the payment service (returns 100 yuan) and “Deduct Inventory” from the inventory service (returns 1 item), and the verification passes.

[0136] (5) DNS resolves order.xxx.com to the disaster recovery order service IP, and the user's APP continues to place orders. The switch is seamless and the recovery time is about 450ms.

[0137] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0138] The disaster recovery apparatus for cross-cloud services provided in the embodiments of this application is described below. The disaster recovery apparatus for cross-cloud services described below can be referred to in correspondence with the disaster recovery method for cross-cloud services described above.

[0139] like Figure 4 As shown, this application provides a disaster recovery device 200 for cross-cloud services, the device comprising:

[0140] The snapshot acquisition module 201 is used to detect disaster recovery triggers in the main cloud cluster. When a disaster recovery switchover of the main cloud cluster is triggered, the latest transaction snapshot file is loaded from the preset transaction snapshot system. The transaction snapshot file is used to record global transaction summary information and details of incomplete transactions.

[0141] The log acquisition module 202 is used to determine the snapshot time of the transaction snapshot file and obtain log data after the snapshot time from the preset log synchronization system;

[0142] Transaction identification module 203 is used to identify incomplete transactions in transaction snapshot files and log data;

[0143] The disaster recovery module 204 is used to determine the current transaction status of each incomplete transaction, and execute corresponding recovery instructions based on the transaction status to update the transaction status of the incomplete transaction.

[0144] In this embodiment, when a disaster recovery switchover of the main cloud cluster is triggered, the latest transaction snapshot file is loaded. This transaction snapshot file records global transaction summary information and details of incomplete transactions, effectively compensating for the shortcomings of existing solutions that only synchronize the final database data and lose intermediate transaction states and global context. Furthermore, by determining the snapshot time point and supplementing incremental log data from that time to the fault occurrence, a mechanism combining transaction snapshots and incremental logs is introduced to accurately and quickly identify all incomplete transactions, and then determine the latest state of each incomplete transaction one by one. Based on this, recovery instructions corresponding to the state are automatically executed for each incomplete transaction, allowing intermediate data that was previously suspended due to state loss to be re-associated with the correct transaction context. This not only fundamentally ensures transaction consistency but also transforms the disaster recovery process from the manual intervention and long waiting time required by traditional solutions into a fully automated, second-level precise recovery, thereby improving the efficiency of disaster recovery.

[0145] In one embodiment, the snapshot acquisition module includes:

[0146] The cluster monitoring submodule is used to monitor the heartbeat interruption time, transaction failure rate, and core service downtime ratio of the main cloud cluster.

[0147] The first triggering submodule is used to trigger the disaster recovery switch of the main cloud cluster if the heartbeat interruption time exceeds the first preset threshold.

[0148] The second triggering submodule is used to trigger the disaster recovery switch of the main cloud cluster if the transaction failure rate exceeds the second preset threshold.

[0149] The third triggering submodule is used to trigger the disaster recovery switch of the main cloud cluster if the core service downtime ratio exceeds the third preset threshold.

[0150] In one embodiment, when the transaction status is pending rollback or pending commit, the disaster recovery module includes:

[0151] The service determination submodule is used to determine the service participants corresponding to the incomplete transaction;

[0152] The transaction rollback submodule is used to send a rollback instruction to each participating service provider if the transaction status is pending rollback, indicating that the incomplete transaction is to be rolled back, and to update the transaction status of the incomplete transaction to be rolled back.

[0153] The transaction commit submodule is used to send a commit instruction to each participating service provider if the transaction status is pending, indicating that the incomplete transaction is to be committed, and to update the transaction status of the incomplete transaction to committed.

[0154] In one embodiment, when the transaction status is ready, the disaster recovery module includes:

[0155] The condition judgment submodule is used to determine the participating service provider corresponding to the incomplete transaction and to determine whether the incomplete transaction meets the commit conditions.

[0156] The transaction commit submodule is used to send a commit instruction to each participating service provider, indicating that the incomplete transaction is being committed, and to update the transaction status of the incomplete transaction to committed if the conditions are met.

[0157] The transaction rollback submodule is used to send a rollback instruction to each participating service provider if the conditions are not met, indicating that the incomplete transaction should be rolled back, and to update the transaction status of the incomplete transaction to be rolled back.

[0158] In one embodiment, when the transaction status is "pending preparation," the disaster recovery module includes:

[0159] The transaction preparation submodule is used to determine the participating service providers corresponding to the incomplete transaction and send a preparation instruction to each participating service provider indicating that the incomplete transaction is ready.

[0160] The judgment submodule is used to determine whether the incomplete transaction meets the commit conditions;

[0161] The transaction commit submodule is used to send a commit instruction to each participating service provider, indicating that the incomplete transaction is being committed, and to update the transaction status of the incomplete transaction to committed if the conditions are met.

[0162] The transaction rollback submodule is used to send a rollback instruction to each participating service provider if the conditions are not met, indicating that the incomplete transaction should be rolled back, and to update the transaction status of the incomplete transaction to be rolled back.

[0163] In one embodiment, the log acquisition module includes:

[0164] The transaction acquisition submodule is used to acquire unsynchronized main cloud transactions in the main cloud cluster;

[0165] The transaction processing submodule is used to extract the core fields of the main cloud transaction, obtain the lightweight transaction, and compress the lightweight transaction to obtain the transaction log;

[0166] The transaction synchronization submodule is used to determine the bandwidth allocated to each transaction log to be synchronized based on the priority of the current transaction log to be synchronized, and to synchronize each transaction log to be synchronized based on the bandwidth allocated to each transaction log to be synchronized.

[0167] In one embodiment, the snapshot acquisition module includes:

[0168] The concurrency acquisition submodule is used to obtain the current transaction concurrency of the main cloud cluster;

[0169] The period adjustment submodule is used to dynamically adjust the snapshot period of the transaction snapshot system based on the transaction concurrency.

[0170] The snapshot generation submodule is used to obtain global transaction summary information and incomplete transaction details data of the main cloud cluster at each snapshot period, and generate snapshot files based on the global transaction summary information and incomplete transaction details data;

[0171] The snapshot storage submodule is used to record the snapshot time of snapshot files and store the snapshot files and their snapshot times in the transactional snapshot system.

[0172] The division of modules in the aforementioned cross-cloud service disaster recovery device is merely illustrative. In other embodiments, the cross-cloud service disaster recovery device can be divided into different modules as needed to complete all or part of its functions. Each module in the aforementioned cross-cloud service disaster recovery device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the computer device in hardware form, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0173] In one embodiment, this application also provides a storage medium storing computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of the cross-cloud service disaster recovery method as described in any of the above embodiments.

[0174] In one embodiment, this application also provides a computer device storing computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of the disaster recovery method for cross-cloud services as described in any of the above embodiments.

[0175] Indicatively, such as Figure 5 As shown, Figure 5 This is a schematic diagram of the internal structure of a computer device 300 provided in an embodiment of this application. The computer device 300 can be provided as a server. (Refer to...) Figure 5 The computer device 300 includes a processing component 302, which further includes one or more processors, and memory resources represented by memory 301 for storing instructions, such as applications, that can be executed by the processing component 302. The applications stored in memory 301 may include one or more modules, each corresponding to a set of instructions. Furthermore, the processing component 302 is configured to execute instructions to perform the disaster recovery method for cross-cloud services described in any of the above embodiments.

[0176] The computer device 300 may also include a power supply component 303 configured to perform power management of the computer device 300, a wired or wireless network interface 304 configured to connect the computer device 300 to a network, and an input / output (I / O) interface 305. The computer device 300 may operate on an operating system stored in memory 301, such as Windows Server™, Mac OS X™, Unix™, Linux™, Free BSD™, or similar.

[0177] Those skilled in the art will understand that Figure 5 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0178] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising a…" does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element. In this document, the singular forms "a," "an," and "the" may also include the plural forms unless the context clearly indicates otherwise. It should also be understood that the terms “comprising / including” or “having” specify the presence of the stated features, wholes, steps, operations, components, parts or combinations thereof, but do not exclude the possibility of the presence or addition of one or more other features, wholes, steps, operations, components, parts or combinations thereof. Meanwhile, the term “and / or” as used in this specification includes any and all combinations of the associated listed items.

[0179] The various embodiments in this specification are described in a progressive manner. Each embodiment focuses on the differences from other embodiments. The various embodiments can be combined as needed, and the same or similar parts can be referred to each other.

[0180] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A disaster recovery method for cross-cloud services, characterized in that, The method includes: Disaster recovery trigger detection is performed on the main cloud cluster. When a disaster recovery switchover of the main cloud cluster is triggered, the latest transaction snapshot file is loaded from the preset transaction snapshot system. The transaction snapshot file is used to record global transaction summary information and details of incomplete transactions. Determine the snapshot time of the transaction snapshot file, and obtain log data after the snapshot time from a preset log synchronization system; Identify incomplete transactions in the transaction snapshot file and the log data; For each incomplete transaction, determine the current transaction state of the incomplete transaction, and execute the corresponding recovery instruction according to the transaction state to update the transaction state of the incomplete transaction.

2. The disaster recovery method for cross-cloud services according to claim 1, characterized in that, The disaster recovery trigger detection for the main cloud cluster includes: Monitor the heartbeat interruption time, transaction failure rate, and core service downtime rate of the main cloud cluster; If the heartbeat interruption time exceeds the first preset threshold, the disaster recovery switch of the main cloud cluster is triggered. If the transaction failure rate exceeds the second preset threshold, the disaster recovery switch of the main cloud cluster will be triggered. If the downtime rate of the core services exceeds the third preset threshold, the disaster recovery switch of the main cloud cluster will be triggered.

3. The disaster recovery method for cross-cloud services according to claim 1, characterized in that, When the transaction status is pending rollback or pending commit, the step of executing the corresponding recovery instruction according to the transaction status and updating the transaction status of the incomplete transaction includes: Identify the service providers involved in the incomplete transaction; If the transaction status is pending rollback, a rollback instruction indicating that the incomplete transaction is to be rolled back is sent to each participating service provider, and the transaction status of the incomplete transaction is updated to rolled back. If the transaction status is pending, a commit instruction is sent to each participating service provider to indicate that the incomplete transaction is to be committed, and the transaction status of the incomplete transaction is updated to committed.

4. The disaster recovery method for cross-cloud services according to claim 1, characterized in that, When the transaction status is "ready," the step of executing the corresponding recovery instruction based on the transaction status to update the transaction status of the incomplete transaction includes: Identify the participating service providers corresponding to the incomplete transaction and determine whether the incomplete transaction meets the commit conditions; If the conditions are met, a commit instruction is sent to each participating service provider to indicate that the incomplete transaction is being committed, and the transaction status of the incomplete transaction is updated to committed. If the conditions are not met, a rollback instruction indicating that the incomplete transaction has been rolled back is sent to each participating service provider, and the transaction status of the incomplete transaction is updated to "rolled back".

5. The disaster recovery method for cross-cloud services according to claim 1, characterized in that, When the transaction status is "pending preparation," the step of executing the corresponding recovery instruction based on the transaction status to update the transaction status of the incomplete transaction includes: Identify the participating service providers corresponding to the incomplete transaction and send a preparation instruction to each participating service provider indicating that the incomplete transaction is ready; Determine whether the incomplete transaction meets the commit conditions; If the conditions are met, a commit instruction is sent to each participating service provider to indicate that the incomplete transaction is being committed, and the transaction status of the incomplete transaction is updated to committed. If the conditions are not met, a rollback instruction indicating that the incomplete transaction has been rolled back is sent to each participating service provider, and the transaction status of the incomplete transaction is updated to "rolled back".

6. The disaster recovery method for cross-cloud services according to any one of claims 1 to 5, characterized in that, The log synchronization process of the log synchronization system includes: Retrieve unsynchronized main cloud transactions in the main cloud cluster; Extract the core fields of the main cloud transaction to obtain a lightweight transaction, and compress the lightweight transaction to obtain a transaction log; Based on the priority of the transaction logs to be synchronized, determine the bandwidth allocated to each transaction log to be synchronized, and synchronize each transaction log to be synchronized based on the bandwidth allocated to each transaction log to be synchronized.

7. The disaster recovery method for cross-cloud services according to any one of claims 1 to 5, characterized in that, The process of generating snapshot files in the transaction snapshot system includes: Get the current transaction concurrency of the main cloud cluster; The snapshot period of the transaction snapshot system is dynamically adjusted according to the transaction concurrency. At each snapshot interval, global transaction summary information and incomplete transaction details of the main cloud cluster are obtained, and a snapshot file is generated based on the global transaction summary information and the incomplete transaction details. Record the snapshot time of the snapshot file and store the snapshot file and its snapshot time in the transactional snapshot system.

8. A disaster recovery device for cross-cloud services, characterized in that, The device includes: The snapshot acquisition module is used to detect disaster recovery triggers in the main cloud cluster. When a disaster recovery switchover of the main cloud cluster is triggered, the latest transaction snapshot file is loaded from the preset transaction snapshot system. The transaction snapshot file is used to record global transaction summary information and details of incomplete transactions. The log acquisition module is used to determine the snapshot time of the transaction snapshot file and acquire log data after the snapshot time from a preset log synchronization system. The transaction identification module is used to identify incomplete transactions in the transaction snapshot file and the log data; The disaster recovery module is used to determine the current transaction status of each incomplete transaction, execute corresponding recovery instructions based on the transaction status, and update the transaction status of the incomplete transaction.

9. A storage medium, characterized in that: The storage medium stores computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of the disaster recovery method for cross-cloud services as described in any one of claims 1 to 7.

10. A computer device, characterized in that, include: One or more processors, and memory; The memory stores computer-readable instructions that, when executed by the one or more processors, perform the steps of the disaster recovery method for cross-cloud services as described in any one of claims 1 to 7.

Images