An AI computing power load management method and system for a disaster recovery center

Abstract

The application relates to a method and system for AI computing power load management of a disaster recovery center, and relates to the field of electric digital data processing.In the method, a logical dependence topology diagram of a business system and real-time load data and a ready state of each node are acquired, and then a blocked node existing load but not ready and a target recovery node pointed by the blocked node are screened out.The load of the blocked node is reversely mapped into a computing power compensation weight of the target recovery node by using a preset function, and the computing power compensation weight is combined with real-time load of the target node to generate a target scheduling feature.The feature is input into a pre-trained AI computing power distribution model to generate a strategy, and computing power resources are directionally distributed to the target node.When it is monitored that the target node turns into a ready state, the reverse mapping is stopped and normal computing power distribution of the blocked node is restored.The application is used for improving computing power resource utilization efficiency of the disaster recovery center in a business takeover process.

Description

Technical Field

[0001] This application belongs to the field of electronic digital data processing, and in particular relates to a method and system for managing the computing power load of AI in a disaster recovery center. Background Technology

[0002] With the rapid development of information technology, disaster recovery centers play a crucial role in ensuring enterprise data security and business continuity. When the primary data center fails, the disaster recovery center needs to quickly take over operations and manage computing load. Traditional computing load management typically uses static resource allocation or simple scheduling rules based on fixed thresholds. When faced with sudden increases in computing demand during disaster recovery switchover, it is difficult to achieve dynamic adaptive adjustment of resources, which can easily lead to reduced computing resource utilization and decreased business recovery efficiency.

[0003] To address the issue of reduced resource utilization caused by static allocation, a data center resource scheduling method based on deep reinforcement learning has been disclosed in related technologies. By deploying a deep reinforcement learning model in the data center, the load status data of each computing node is collected in real time. The artificial intelligence model outputs a dynamic computing resource scheduling strategy based on the current load status, thereby realizing the automatic allocation of computing resources according to real-time business load and improving the dynamic adaptability of computing load management.

[0004] When the primary data center goes down due to a sudden failure, the disaster recovery center needs to take over the complex business system, which includes a multi-layered architecture encompassing the core database, middleware, and front-end application layers. When user traffic is redirected to the disaster recovery center, the relevant technologies detect the increased load on the front-end application layer nodes and prioritize computing resources for these nodes. However, the front-end application layer can only effectively process business requests after the underlying database has completed incremental data synchronization and state recovery. This results in the front-end application layer occupying waiting computing resources before the underlying database has completed its recovery logic, causing a mismatch between computing resource allocation and the actual logical readiness of the business nodes. This reduces the efficiency of computing resource utilization by the disaster recovery center during the business takeover process. Summary of the Invention

[0005] This application provides a method and system for managing the computing power load of AI in a disaster recovery center, which can improve the utilization efficiency of computing resources in the disaster recovery center during the business takeover process.

[0006] In the first aspect, this application provides a method for managing the computing power load of AI in a disaster recovery center, which obtains the logical dependency topology diagram of the disaster recovery takeover business system, and collects the real-time load data and ready status identifier of each business node in the logical dependency topology diagram. The ready status identifier is used to characterize whether the corresponding business node has the data support conditions to process business requests. Based on the logical dependency topology and the ready status identifier of each business node, the blocked nodes that are not ready and have real-time load data are selected from each business node, as well as the target recovery node that the blocked node points to in the logical dependency topology. By using a preset load conversion function, the real-time load data of the blocked node is reverse-mapped along the logical dependency topology to obtain the computing power compensation weight of the target recovery node. The real-time load data of the target recovery node is combined with the computing power compensation weight to generate the target scheduling characteristics; The target scheduling features are input into a pre-trained AI computing power allocation model to obtain a computing power allocation strategy for the target recovery node; Allocate computing resources to the target recovery node according to the computing power allocation strategy; When the ready status flag of the target recovery node is updated to the ready status, the reverse mapping of the real-time load data of the blocked node is stopped, and the computing resource allocation of the blocked node based on the real-time load data is restored.

[0007] By acquiring the logical dependency topology and real-time load and readiness status of nodes in the disaster recovery takeover system, blocked nodes with real-time load but lacking data support and thus in a non-ready state are identified, along with their target recovery nodes. A load transformation function reverse-maps the backlogged load data of blocked nodes, converting it into computing power compensation weights for the target recovery nodes. This weight is then combined with the real-time load of the target recovery nodes to generate target scheduling features. This allows the AI ​​model to comprehensively consider the load pressure transmitted from upstream nodes when allocating computing power, preferentially allocating resources to the target recovery nodes. With sufficient computing power, the target recovery nodes can accelerate their business processing capabilities, thereby prompting blocked nodes to meet readiness conditions more quickly. Once ready, the reverse mapping stops and normal allocation resumes. Dynamically concentrating computing resources on the true bottleneck nodes for business recovery reduces the latency of business requests waiting at blocked nodes, improving the system's computing resource utilization efficiency and overall business link recovery speed during disaster recovery takeover.

[0008] In conjunction with some implementation methods of the first aspect, in some implementation methods, a preset load transformation function is used to reverse map the real-time load data of the blocked node along the logical dependency topology to obtain the computing power compensation weight of the target recovery node, specifically including: Extract the request retry frequency and concurrent queuing depth from the real-time load data of the blocked nodes; Calculate the load effectiveness attenuation coefficient based on the frequency of request retry; The effective load pressure value of the blocked node is obtained by multiplying the concurrent queuing depth by the load effectiveness attenuation coefficient. Traverse the logically dependent topology graph to determine the topological path distance between the blocked node and the target recovery node; The effective load pressure value and topology path distance are input into a preset load conversion function to calculate the distance attenuation and obtain the computing power compensation weight of the target recovery node.

[0009] By extracting the request retry frequency and concurrent queuing depth from the real-time load of blocked nodes, and calculating the load effectiveness attenuation coefficient based on the request retry frequency, and then multiplying it by the concurrent queuing depth, false high load phenomena caused by network fluctuations or frequent invalid retries are filtered out, obtaining an effective load pressure value that truly reflects the degree of node backlog. Further, the logical dependency topology graph is traversed to determine the topological path distance between nodes. The effective load pressure value and the topological path distance are combined for distance attenuation calculation, taking into account the objective fact that the greater the distance in complex dependency links, the weaker the actual computing power compensation demand for the target node. This scheme makes the calculated computing power compensation weight more accurately quantify the real urgency of the blocked node's need for the target recovery node, improves the accuracy of computing power compensation weight calculation, and reduces unnecessary computing power waste caused by load distortion or large topological distances.

[0010] In conjunction with some implementation methods of the first aspect, in some implementation methods, the real-time load data of the target recovery node is combined with the computing power compensation weight to generate target scheduling features, specifically including: Extract real-time load data of the target recovery node and its resource utilization in the computing, storage, and network dimensions; Compare resource utilization across computing, storage, and network dimensions to identify the bottleneck resource dimension of the target recovery node; By pre-setting a cross-node resource mapping matrix, the computing power compensation weight is projected onto the bottleneck resource dimension, so as to convert the scalar computing power compensation weight into a multi-dimensional resource demand compensation vector. The multi-dimensional resource demand compensation vector is concatenated with the real-time load data of the target recovery node using tensor feature vectors to obtain the concatenated feature matrix. The concatenated feature matrix is ​​normalized to generate target scheduling features.

[0011] By employing the aforementioned technical solution, the resource utilization rates of the target recovery node in the computing, storage, and network dimensions were extracted and compared to identify the bottleneck resource dimensions currently hindering business processing. Using a pre-defined cross-node resource mapping matrix, the originally single scalar form of computing power compensation weight was redirected and projected onto the corresponding bottleneck resource dimension, transforming it into a multi-dimensional resource demand compensation vector. This allows computing power compensation to specifically address the node's weakest resource shortcomings. Subsequently, this resource demand compensation vector was concatenated with real-time load data as a tensor feature vector and normalized to generate a target scheduling feature that integrates multi-dimensional load and targeted compensation information. This improves the accuracy of the scheduling feature in representing the true resource scarcity status of each node dimension, thereby enhancing the granularity of resource allocation across different dimensions during subsequent computing power scheduling by the AI ​​model and reducing the risk of ineffective resource hoarding in non-bottleneck dimensions.

[0012] In conjunction with some implementation methods of the first aspect, in some implementation methods, the backlog of historical service requests in the blocked nodes is extracted, and the service operation type carried by each historical service request is parsed. Historical business requests are classified according to their business operation type, and a preset number of business requests are extracted from each category to construct a real business probe set corresponding to the blocking node. The computing resources of blocked nodes are divided into basic computing power for detection and computing power for unlocking services; By probing the basic computing power, requests from the real business probe set are sent to the target recovery node, and the success rate feedback of the target recovery node for processing requests of different business operation types is monitored. By comparing the processing success rate feedback of each business operation type with the preset health baseline, the restricted business types that are in an abnormal micro-state and the available business types that are in a normal micro-state are identified. Suspend the allocation of service unlocking computing power to the backlog of requests belonging to restricted service types in the blocked nodes; Based on the amount of backlogged requests belonging to the available service type, the corresponding service unlocking computing power is allocated to the blocked nodes.

[0013] By extracting and categorizing historical business requests backlogged from blocked nodes, a business probe set is constructed from real requests. Computing power is divided into basic probe computing power and business unlocking computing power. Using a small amount of basic computing power, real business probe requests are sent to accurately test the actual processing capacity of target recovery nodes for specific business types without triggering large-scale invalid calls. By monitoring the processing success rate of different business operation types and comparing it with a health baseline, restricted and available business types are distinguished at a micro level. The allocation of business unlocking computing power to restricted types of requests is suspended, preventing continuous processing failures and resource waste caused by blindly issuing requests. Simultaneously, unlocking computing power is precisely allocated based on the backlog of available types to ensure the smooth execution of available services. This improves the granularity of computing power scheduling in the disaster recovery system during periods of node instability, reduces the invalid computing power loss rate caused by blind allocation, and improves the actual processing efficiency of available business requests.

[0014] In conjunction with some implementation methods of the first aspect, in some implementation methods, requests from the real business probe set are sent to the target recovery node by probing the basic computing power, and the success rate feedback of the target recovery node for processing requests of different business operation types is monitored, specifically including: The real business probe set corresponding to the current business operation type is divided into a preheating probe subset and a verification probe subset; Based on the basic computing power of the probe, a preheating probe subset is sent to the target recovery node to trigger a cold start of the dependency link for the current business operation type, and the initial response status data returned by the target recovery node for the preheating probe subset is discarded. After a preset buffer delay, a verification probe subset is sent to the target recovery node based on the basic computing power of the probe; The system collects the service response status codes returned by the target recovery node for the verification probe subset, and calculates the processing success rate feedback of the service operation type based on the service response status codes.

[0015] By dividing the real business probe set into a pre-warm-up probe subset and a verification probe subset, the pre-warm-up probe subset is used to trigger a cold start of the target recovery node for the current business operation type's dependent links, and its initial response status data is actively discarded. This eliminates abnormal fluctuations in data interference caused by nodes waking up from dormant or cold standby states when resources are not yet fully ready. After a preset buffer delay allows the business links to enter a stable operating state, the verification probe subset is then sent based on the probe's basic computing power, and the processing success rate feedback for the business operation type is calculated accordingly. This avoids the miscalculation of brief processing failures caused by link cold starts as the node's actual business processing capability, improves the accuracy of node business processing success rate assessment, and reduces the misjudgment rate of business readiness status caused by initial instability.

[0016] In conjunction with some implementations of the first aspect, in some implementations, after allocating the corresponding service unlocking computing power to the blocked nodes based on the amount of backlogged requests belonging to the available service type, the method further includes: Analyze the business execution topology of restricted business types and extract the set of underlying dependent components corresponding to the restricted business types on the target recovery node side; While the blocked node continuously sends backlog requests corresponding to available service types to the target recovery node using the business unlocking computing power, the system bypasses the monitoring of the internal component call trajectory and corresponding component running status feedback generated by the target recovery node for each available service type. By performing cross-dimensional mapping and comparison between the underlying dependent component set and the collected internal component call trajectories, components with overlapping calls between restricted business types and available business types are selected. If it is determined that each intersection component completely covers the set of underlying dependent components, and each intersection component shows a normal response status in the component running status feedback, it is determined that the micro-running environment of the restricted business type has been implicitly restored and is ready. Convert the status flag of a restricted service type that is implicitly ready for recovery to an available service type; Allocate corresponding service unlocking computing power to the backlog of available service types to lift the suspension of computing power allocation for restricted service types.

[0017] By analyzing the execution topology of restricted service types, the underlying dependency component set is extracted. During the continuous sending of available service requests, the internal component call trajectory and component running status of the target recovery node are monitored. Cross-dimensional mapping and comparison are used to filter out the intersection components where available and restricted services call each other. When the intersection components completely cover the underlying dependencies of the restricted service and all show a normal response status, it is directly determined that the micro-operational environment of the restricted service type has implicitly recovered and is ready. Utilizing the underlying component status feedback generated by available services in actual operation indirectly verifies the underlying operating environment of the restricted service, avoiding repeated active probing of the restricted service, reducing the additional computing power overhead and network occupation during service status probing, improving the system's agility in perceiving the recovery readiness status of restricted services, and thus shortening the service backlog time for restricted services.

[0018] In conjunction with some implementation methods of the first aspect, in some implementation methods, a cross-dimensional mapping comparison is performed between the set of underlying dependent components and the collected call trajectories of various internal components to filter out the intersection components where there is overlapping call between restricted business types and available business types, specifically including: Analyze the call attributes of each underlying dependent component in the underlying dependent component set, extract the business operation permission requirements of each underlying dependent component for restricted business types, and construct a component requirement matrix that includes component identifier dimension and permission requirement dimension; From the collected internal component call trajectories, extract the actual execution operation types of the available business types for each called component; Based on the component identifier dimension, the called component is aligned with the component requirement matrix to identify target components with shared entities; The actual operation type corresponding to the target component is compared with the business operation permission requirements. If the permission level of the actual operation type is greater than or equal to the business operation permission requirements, the target component is determined to be an intersection component that meets the requirements of the deep runtime environment.

[0019] By analyzing the business operation permission requirements of restricted business types for underlying dependent components, a component requirement matrix is ​​constructed. The actual execution operation types are extracted from the internal component call trajectories of available business types, and target components shared by entities are identified based on this. Furthermore, the permission level of the actual execution operation type corresponding to the target component is compared with the business operation permission requirements of the restricted business. Only when the actual execution permission level is greater than or equal to the required permission level is the target component determined to be an intersection component meeting the requirements of the deep runtime environment. This solution fully considers the differences in operation permissions of different businesses for the same underlying component, avoiding the situation where a high-level permission dependency environment is mistakenly judged to be ready because an available business has only successfully executed a low-level permission call. This improves the rigor of the determination of intersection components and micro-running environments, and reduces the risk of secondary processing failures caused by prematurely lifting the computing power allocation pause due to the underlying permission environment not meeting the requirements.

[0020] Secondly, embodiments of this application provide a computing load management system for AI used in disaster recovery centers. The computing load management system for AI used in disaster recovery centers includes: one or more processors and a memory; the memory is coupled to one or more processors, and the memory is used to store computer program code, the computer program code including computer instructions, and one or more processors call the computer instructions to cause the system to perform the method described in the first aspect and any possible implementation of the first aspect.

[0021] Thirdly, embodiments of this application provide a computer-readable storage medium including instructions that, when executed on a system, cause the system to perform the method described in the first aspect and any possible implementation thereof.

[0022] Fourthly, embodiments of this application provide a computer program product that, when run on a system, causes the system to execute the method described in any possible implementation of the first aspect.

[0023] One or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages: 1. This application provides a method for AI-based computing power load management in disaster recovery centers. By acquiring the logical dependency topology and real-time load and readiness status of nodes in the disaster recovery takeover business system, it identifies blocked nodes that have real-time load but are in a non-ready state due to lack of data support, and the target recovery node they point to. A load transformation function reverse-maps the backlogged load data of blocked nodes, transforming it into computing power compensation weights for the target recovery node. This weight is then combined with the real-time load of the target recovery node to generate target scheduling features. This allows the AI ​​model to comprehensively consider the load pressure transmitted from upstream nodes when allocating computing power, allocating resources preferentially to the target recovery node. With more sufficient computing power, the target recovery node can accelerate its business processing capabilities, thereby prompting blocked nodes to meet readiness conditions more quickly. Once ready, the reverse mapping stops and normal allocation resumes. Dynamically concentrating computing resources on the true bottleneck nodes of business recovery reduces the latency of business request waiting at blocked nodes, improving the system's computing power utilization efficiency and overall business link recovery speed during disaster recovery takeover.

[0024] 2. This application provides a method for AI-based computing power load management in disaster recovery centers. It extracts and categorizes backlogged historical business requests from blocked nodes, extracts real requests to construct a business probe set, and divides computing power into basic probe computing power and business unlocking computing power. Using a small amount of basic computing power, it sends real business probe requests to accurately probe the actual processing capabilities of target recovery nodes for specific business types without triggering large-scale invalid calls. By monitoring the processing success rate of different business operation types and comparing it with a health baseline, it distinguishes between restricted and available business types at a micro-level. It suspends the allocation of business unlocking computing power to restricted type requests, preventing continuous processing failures and resource waste caused by blindly issuing requests. Simultaneously, it accurately allocates unlocking computing power based on the backlog of available types to ensure the smooth execution of available services. This improves the granularity of computing power scheduling in disaster recovery systems during periods of node instability, reduces the invalid computing power loss rate caused by blind allocation, and improves the actual processing efficiency of available business requests.

[0025] 3. This application provides a method for managing the computing load of AI in a disaster recovery center. It extracts the underlying dependency component set by analyzing the business execution topology of restricted business types. While the system continuously sends requests for available services, it indirectly monitors the internal component call trajectory and component running status of the target recovery node. Through cross-dimensional mapping and comparison, it filters out the intersection components where available and restricted services call each other. When the intersection components completely cover the underlying dependencies of the restricted service and all show a normal response status, it directly determines that the micro-operating environment of the restricted business type has implicitly recovered and is ready. By utilizing the underlying component status feedback generated by available services in actual operation, it indirectly verifies the underlying operating environment of the restricted service, avoiding repeated active probing of the restricted service, reducing the additional computing power overhead and network occupation during the service status probing process, improving the system's agility in perceiving the recovery readiness status of restricted services, and thus shortening the service backlog time of restricted services. Attached Figure Description

[0026] Figure 1 This is a flowchart illustrating a method for managing the computing load of an AI-based disaster recovery center, as described in an embodiment of this application.

[0027] Figure 2 This is another flowchart illustrating a method for managing the computing load of an AI-based disaster recovery center, as described in an embodiment of this application.

[0028] Figure 3 This is another flowchart illustrating a method for managing the computing load of AI in a disaster recovery center, as described in this application.

[0029] Figure 4 This is a schematic diagram of the physical device structure of an AI-based computing load management system for disaster recovery centers, provided in an embodiment of this application. Detailed Implementation

[0030] The terminology used in the following embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. As used in the specification and appended claims of this application, the singular expressions “a,” “an,” “the,” “the,” “the,” and “this” are intended to include the plural expressions as well, unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in this application refers to any or all possible combinations including one or more of the listed items.

[0031] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature, and in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0032] The following example is used in conjunction with Figure 1 This application describes a method for managing the computing load of an AI-based disaster recovery center, as exemplified in one of its embodiments: Please see Figure 1 This is a flowchart illustrating a method for managing the computing load of an AI-based disaster recovery center, as described in an embodiment of this application.

[0033] S101. Obtain the logical dependency topology diagram of the disaster recovery takeover business system, and collect the real-time load data and ready status indicators of each business node in the logical dependency topology diagram. The system acquires the logical dependency topology of the disaster recovery takeover business system and collects real-time load data and ready status identifiers for each business node in the topology. The ready status identifier indicates whether the corresponding business node has the data support conditions to process business requests. The disaster recovery takeover business system refers to a backup computing environment used to take over business processing from the primary system when the primary data center fails or becomes paralyzed, such as a geographically distributed disaster recovery cluster or a dual-active data center backup link. The logical dependency topology is a directed acyclic graph or network structure representing the mutual calls and data dependencies between various microservices, components, or applications in the business system. A business node is the basic execution unit in the topology and can represent a physical server, virtual machine, or containerized microservice instance. Real-time load data refers to the business pressure indicators that a node is currently experiencing, including but not limited to CPU utilization, memory usage, disk I / O operations per second, and concurrent connections. The ready status identifier is a discrete state parameter, such as a Boolean value or a specific status code, used to explicitly indicate whether the corresponding node has completed key data support condition preparation work such as cache warm-up, database connection pool initialization, and underlying state data synchronization.

[0034] The system can acquire the aforementioned data by deploying a lightweight proxy daemon process within the operating system running on each business node. This proxy daemon process periodically reads the operating system kernel's resource monitoring interface at a preset fixed frequency to collect real-time load data. Simultaneously, the process listens to health check endpoints exposed by business applications within the node, reading return values ​​representing ready status indicators. The proxy process encapsulates the load data, status indicators, and the node's own network address information into data packets according to a unified protocol format and continuously pushes them to the centralized monitoring console at the system backend via a message middleware. Upon receiving the data, the console, combined with the service discovery list in the statically configured microservice registry, dynamically assembles and renders the entire logical dependency topology graph using a graph building algorithm.

[0035] The system can also acquire data by deploying traffic mirroring and deep packet inspection bypass devices at the virtual network boundary of the disaster recovery takeover business system. The bypass devices capture network communication data packets between business nodes in real time. By parsing the link tracing identifier and source / destination addresses in the application layer protocol header, and using association rule mining algorithms, the logical call relationships between nodes are deduced in reverse, thereby generating a logical dependency topology graph. For real-time load data and readiness status indicators, the system directly calls the aggregated resource query interface provided by the cloud-native orchestration platform (such as the Kubernetes application programming interface server). The orchestration platform's built-in resource measurement pipeline provides real-time resource consumption information for each node, and its internal readiness probe status is directly mapped to readiness status indicators. The system then binds this retrieved information to the topology graph through node mapping.

[0036] S102. Based on the logical dependency topology diagram and the ready status identifier of each business node, filter out the blocked nodes that are not ready and have real-time load data in each business node, as well as the target recovery node pointed to by the blocked node in the logical dependency topology diagram. A blocking node in the logical dependency topology graph refers to a business unit that, although receiving business requests from the frontend or upstream, generating a certain real-time load, is marked as "not ready" due to its own or its dependent conditions not being met, causing requests to accumulate and preventing normal processing. A target recovery node refers to a downstream critical dependency unit that is directly or indirectly called by the blocking node along the call chain of the logical dependency topology graph, and whose own state directly determines whether the blocking node can successfully process the business. Both terms are dynamic entity concepts defined based on the topology structure and the literal characteristics of node states. Being in a "not ready" state indicates that the system has not yet completed takeover preparations, while the presence of real-time load data indicates that business traffic has already been switched over.

[0037] The system can utilize a depth-first search algorithm from graph theory for filtering. First, the system loads the acquired logical dependency topology graph into memory, constructing an adjacency list data structure consisting of nodes and directed edges. Then, the system traverses each node in the graph, reading its ready status flag and real-time load data. If a node is flagged as not ready and its real-time load data shows a concurrent request count greater than zero, the system instantiates it and marks it as a blocked node. Next, starting from this blocked node, the system performs a depth-first recursive tracing along the directed edges in the adjacency list, searching for downstream nodes at the bottom of the call chain that provide core data support or are also in an abnormal state. The system extracts their location coordinates and flags, marking them as target recovery nodes.

[0038] The system can also implement filtering operations by constructing a state matrix and performing vector operations. The system transforms the logical dependency topology graph into a Boolean topological adjacency matrix to represent the connectivity between nodes. Simultaneously, the system extracts the ready state flags (mapping 0 for ready and 1 for not ready) and real-time load data for all nodes (normalizing and converting them into binary vectors, 1 for load and 0 for no load). The system performs an element-wise logical AND operation between the not-ready state vector and the real-time load vector; the index of a value of 1 in the resulting vector corresponds to the blocked node. After identifying the blocked node, the system performs continuous matrix multiplication operations between the one-hot encoded vector containing the blocked node's location flag and the topological adjacency matrix. By truncating the result with a set path length threshold, the system identifies the nodes corresponding to non-zero elements in the result as the target recovery nodes.

[0039] S103. By using a preset load conversion function, the real-time load data of the blocked node is reverse-mapped along the logical dependency topology to obtain the computing power compensation weight of the target recovery node. The system uses a preset load transformation function to reverse-map the real-time load data of blocked nodes along the logical dependency topology graph to obtain the computing power compensation weight for the target recovery node, specifically including: Extract the request retry frequency and concurrent queuing depth from the real-time load data of the blocked node; calculate the load effectiveness attenuation coefficient based on the request retry frequency; multiply the concurrent queuing depth and the load effectiveness attenuation coefficient to obtain the effective load pressure value of the blocked node; traverse the logical dependency topology graph to determine the topological path distance between the blocked node and the target recovery node; input the effective load pressure value and the topological path distance into a preset load transformation function for distance attenuation calculation to obtain the computing power compensation weight of the target recovery node. The preset load transformation function is:

[0040] in, The computing power compensation weight for the target recovery node is a dimensionless pure number that will be used as a multiplier coefficient for subsequent resource allocation. The effective load pressure value is obtained by multiplying the concurrent queuing depth by the load effectiveness attenuation coefficient. The preset baseline load capacity is a constant, which represents the threshold of standard service request backlog that a node can handle per unit time or a single time slice in a normal ready state. This represents the topological path distance. This is the preset attenuation control constant.

[0041] Request retry frequency refers to the number of times the same business request is re-initiated due to a lack of correct response per unit time, characterizing the congestion and retransmission situation of the network or node. Concurrency queuing depth refers to the total number of business requests waiting to be processed in the request queue within a blocked node within a specific time slice. The load effectiveness attenuation coefficient is a dimensionless multiplier with a value between 0 and 1, calculated as a negative power of the natural constant e, where the exponent is the product of the request retry frequency and a preset constant; the higher the retry frequency, the closer the coefficient is to zero. The effective load pressure value reflects the actual request backlog after excluding invalid retries. Topology path distance refers to the number of hops or the sum of weighted edge lengths of directed edges traversed between a blocked node and a target recovery node in a logical dependency topology graph. The preset load transformation function is a mathematical expression that spatially attenuates the effective pressure; for example, its functional form is the effective load pressure value divided by (a constant 1 plus the product of the distance scaling factor and the topology path distance). The computing power compensation weight is a dimensionless scalar value used as a multiplier for subsequent adjustments to the computing power allocation base.

[0042] The system can utilize application performance management tools to directly capture the method call stack context from the Java Virtual Machine or runtime environment of blocked nodes. From this, it can parse the retry count field of the network layer to extract the request retry frequency and read the task queue length of the thread pool to extract the concurrent queuing depth. Subsequently, the system runs a pre-defined exponential decay script in its built-in computing engine, substituting the retry frequency into the load effectiveness decay coefficient. Then, it multiplies the queuing depth by this coefficient using a floating-point multiplier to obtain the effective load pressure value. Next, the system calls the shortest path algorithm from the graph computing library, calculating the topology path distance with hop count as the weight. Finally, the system executes a pre-written decay transformation algebraic function, taking the effective load pressure value and the topology path distance as input, and calculates and outputs the computing power compensation weight for the target recovery node.

[0043] The system can also extract various data by parsing the access logs generated by the proxy gateway nodes. The system uses a log parsing component to perform regular expression matching on the access logs of blocked nodes, calculates the request retry frequency based on the frequency of identical request IDs using unique tracking identifiers, and calculates the concurrent queuing depth based on request arrival and response times in the logs. Utilizing a pre-built data stream processing framework, the system uses a mathematical function module in the real-time stream computing node to calculate the load effectiveness attenuation coefficient and multiplies it with the queuing depth to generate an effective load pressure value. For topological path distance, the system uses the graph database's built-in query language to directly return the hierarchical interval between two nodes using a breadth-first traversal syntax. Finally, the system feeds these two values ​​into a custom transformation function execution unit deployed in the rule engine to calculate the computing power compensation weight.

[0044] S104. Combine the real-time load data of the target recovery node with the computing power compensation weight to generate the target scheduling characteristics; The system combines the real-time load data of the target recovery node with the computing power compensation weight to generate target scheduling features, specifically including: Extract the resource utilization rates of the target recovery node's real-time load data across the computation, storage, and network dimensions; compare the resource utilization rates across these dimensions to determine the bottleneck resource dimension of the target recovery node; project the computational compensation weights onto the bottleneck resource dimension using a pre-defined cross-node resource mapping matrix to convert the scalar computational compensation weights into a multi-dimensional resource demand compensation vector; concatenate the multi-dimensional resource demand compensation vector with the real-time load data of the target recovery node using tensor feature vectors to obtain a concatenated feature matrix; normalize the concatenated feature matrix to generate the target scheduling feature.

[0045] The computational, storage, and network dimensions refer to the resource classifications of a node at three core physical levels: data processing (e.g., CPU utilization, GPU memory usage), data persistence and retrieval (e.g., disk I / O operations per second, memory usage), and data transmission (e.g., network card throughput, network bandwidth utilization). Resource utilization rate refers to the percentage ratio of currently consumed resources to the maximum available resources in that dimension. The bottleneck resource dimension refers to the dimension with the highest utilization rate or closest to the physical extreme value among these three dimensions. The preset cross-node resource mapping matrix is ​​a two-dimensional matrix containing multiple hardware configuration transformation parameters, used to implement the algebraic projection of dimensionless scalars to vectors of specific hardware units. The resource demand compensation vector is a one-dimensional array representing the absolute amount of additional resources required for a specific dimension. The concatenated feature matrix is ​​a high-dimensional tensor formed by concatenating the resource demand compensation vector and the original real-time load data matrix along a specified dimension. Normalization refers to the process of scaling each element in the concatenated feature matrix to a preset standard range (e.g., 0 to 1) according to a certain mathematical rule (e.g., maximum-minimum mapping or zero-mean normalization). The target scheduling features are the high-dimensional data structures that are ultimately input into the artificial intelligence model.

[0046] The system can invoke the operating system's underlying performance monitoring command-line tools to collect the CPU idle time, memory usage percentage, and network interface card (NIC) transmit / receive bytes of the target recovery node, converting these into resource utilization metrics across three dimensions. The system uses conditional logic to sort these three utilization values, extracting the dimension with the highest value and identifying it as the bottleneck resource dimension. Subsequently, using a tensor computation graph framework, the system performs a dot product operation between the computing power compensation weight scalar and the column vector corresponding to the bottleneck dimension in a preset cross-node resource mapping matrix, generating a resource demand compensation vector. Next, the system calls the array processing library's concatenation function to concatenate this vector with the original feature array of real-time load data along the column direction, forming a concatenated feature matrix. Finally, the system uses a range standardization formula to map all values ​​in the feature matrix to the range of 0 to 1, outputting the target scheduling feature.

[0047] The system can also utilize a distributed resource telemetry system deployed on the host machine to obtain resource utilization data across three dimensions by pulling exposed indicator endpoints. The system calculates the deviation of each dimension's resource utilization from a preset safety threshold, selecting the dimension with the largest deviation as the bottleneck resource dimension. During the matrix projection stage, the system calls a parallel computing module deployed on the graphics processing unit to project and transform the computing power compensation weights into a multi-dimensional resource demand compensation vector via a matrix multiplication interface. Subsequently, the system uses the tensor operation application programming interface in the deep learning framework to perform tensor dimension alignment and concatenation operations to construct a concatenated feature matrix. Next, the system performs Z-score standardization on this concatenated feature matrix, subtracting the mean and dividing by the standard deviation to generate target scheduling features that eliminate dimensional differences.

[0048] S105. Input the target scheduling features into the pre-trained AI computing power allocation model to obtain the computing power allocation strategy for the target recovery node; The AI ​​computing power allocation model is a complex computational graph model based on deep reinforcement learning or deep neural network architectures, specifically designed to solve for optimal resource allocation actions in a multi-dimensional state space. The computing power allocation strategy refers to the structured dataset output by the model, containing specific adjustment instructions and allocation amounts for various resources of the target recovery node (such as specific increments in the number of CPU cores, memory allocation in megabytes, and network bandwidth rate limits). This model is a pre-trained static weight model deployed on the system's inference server endpoint.

[0049] The system can employ an AI computing power allocation model based on a deep reinforcement learning architecture (such as a deep deterministic policy gradient architecture). The underlying structure of this model includes an Actor network and a Critic network, both constructed using multi-layer fully connected feedforward neural networks, with linear rectified functions used as activation functions between layers. The training set is constructed from environmental state features and corresponding expert optimal intervention strategies recorded in previous disaster recovery drills and real-world takeover failures. The test set consists of independent event data randomly extracted from historical data that are not used in training. The input data is strictly defined as the normalized target scheduling features generated in the previous stage. After forward propagation through the Actor network, the output data is strictly a continuous-value computing power allocation strategy for the target recovery node, including floating-point adjustments to the quotas for various resources.

[0050] The system can also employ an AI computing power allocation model based on the Transformer encoder architecture. This model's underlying structure consists of alternating layers of multi-head attention mechanisms and feedforward neural networks, effectively capturing global dependencies between features. The training set is generated by injecting a large amount of random load into a sandbox environment and recording the trajectory data of resource allocation required for the system to reach a stable state, along with recovery time stamps. The test set uses blind test data from a specific regional disaster recovery cluster. In use, the system inputs the flattened target scheduling features with added dimensionality and location encoding into the model. After attention weight calculation and linear mapping decoding, the model outputs a discretized computing power allocation strategy for the target recovery node, such as a specific resource expansion package tier or adjustment level.

[0051] In some embodiments, to ensure that the pre-trained AI computing power allocation model can output accurate computing power allocation strategies, the method further includes a training process for the AI ​​computing power allocation model before inputting the target scheduling features into the model. Specifically, the system acquires a large amount of node operation data from historical business takeover drills or historical real-world fault handling processes and constructs it into a training sample set. Each training sample includes historical scheduling features (as model input data) and the expert-optimal allocation strategy that achieves the fastest business takeover recovery speed under these features (as label / label data). The system uses mean squared error (MSE) or cross-entropy as a loss function to calculate the difference between the predicted allocation strategy currently output by the model and the corresponding label data. The network parameters of the AI ​​computing power allocation model are continuously updated through backpropagation algorithm and gradient descent optimizer (such as Adam optimizer) until the model's loss function value converges to below a preset threshold, thereby obtaining the pre-trained AI computing power allocation model. This training process enables the model to fully learn the complex mapping relationship between node load characteristics and underlying computing power requirements, ensuring the accuracy and effectiveness of computing power allocation.

[0052] S106. Allocate computing resources to the target recovery node according to the computing power allocation strategy; Computing resources refer to the total hardware and software processing power required to support the operation of a computer system. In cloud or containerized environments, this is typically quantified as specific quotas such as CPU cycles or core share, memory capacity, disk I / O bandwidth, and network port data throughput limits. Allocating computing resources refers to the process of dynamically modifying the resource quota limit occupied by a target recovery node or directly allocating more underlying hardware computing pools to it by calling the underlying infrastructure management interface.

[0053] The system can allocate computing resources by interacting with a container orchestration platform. The system parses the received computing resource allocation policy into patch files conforming to declarative configuration syntax. Subsequently, the system calls the application programming interface of the container cluster management master node to send a resource update patch request to the application container group corresponding to the target recovery node. Upon receiving the request, the cluster's resource scheduler dynamically modifies the compute request and limit parameters of the container group in the resource inventory. Based on the updated parameters, the underlying container runtime engine modifies the control group configuration in the Linux system, relaxing the hard limits on CPU core usage and physical memory consumption of the target recovery node in real time, thereby completing the dynamic allocation of computing resources.

[0054] The system can also perform allocation operations by directly calling the control interface of the underlying virtualization management program. The system parses the computing power allocation strategy, extracting the required increase in virtual CPU cores and virtual memory expansion for the target recovery node. Next, the system sends a hot-plug command to the virtual machine management and control center in the data center. After confirming that the host machine of the target recovery node has sufficient idle physical resources, the management and control center uses underlying virtualization technology to dynamically mount additional virtual processor devices and map new memory page tables to the virtual machine corresponding to the target recovery node without interrupting the operating system. The operating system within the target node detects the hardware hot-plugging through advanced configuration and power interface events, automatically loads the drivers, and activates the newly allocated computing power resources.

[0055] S107. When the ready status identifier of the target recovery node is updated to the ready status, stop the reverse mapping of the real-time load data of the blocked node and restore the computing power resource allocation of the blocked node based on the real-time load data.

[0056] The ready state is a discrete state parameter corresponding to the not-ready state in step S101. It indicates that the target recovery node is not only running normally at the process level, but also that its required basic data support conditions (such as database table structure synchronization, memory cache loading, and necessary external dependency interface connectivity) have been fully met, giving it the comprehensive ability to process upstream business requests normally and without omission. Reverse mapping refers to the process of calculating compensation weights using the load transformation function in the previous steps. Stopping mapping and restoring resource allocation means that the system breaks the original scheduling intervention that forcibly tilts resources towards the target recovery node from the blocked node, allowing the blocked node to apply for and obtain computing resources again based on its own real-time concurrency queuing depth and other local indicators.

[0057] The system can utilize an event-driven message callback mechanism to implement state monitoring and scheduling strategy switching. A state listening hook program is deployed within the target recovery node. When the node's internal startup script completes execution and the data support service returns a normal status code, the hook program proactively sends a callback data packet containing a ready status identifier to the system's backend event gateway. Upon receiving this callback event, the system immediately unregisters the execution thread of the preset load transformation function for that node's call chain in memory, thereby stopping the reverse mapping process of the blocked node's real-time load data. Simultaneously, the system resets the blocked node's scheduling controller configuration, triggering its native horizontal automatic scaling mechanism based on its own CPU utilization metrics, restoring the blocked node's computing resource allocation based on its own real-time load data.

[0058] The system can also implement this function by combining timed polling with state machine transitions. A polling daemon runs in the background, continuously querying the health check status word of the target recovery node in the service registry at specific time intervals. Once the polling process reads that the status word has changed from not ready to ready, it triggers a state transition instruction in the system's internal state machine. This instruction directly blocks the path from the blocked node's queuing depth data flow to the load transformation function by cutting off the computational branch in the data flow graph, stopping the numerical calculation of the reverse mapping. Subsequently, the system sends a configuration update signaling to the host controller where the blocked node resides, unbinding the target node's constraint rules on the blocked node's computing power quota, allowing the blocked node to independently re-initiate a computing power resource allocation request from the resource pool based on the backlogged real-time load data.

[0059] In the above embodiments, by acquiring the logical dependency topology and real-time load and readiness status of nodes in the disaster recovery takeover system, blocked nodes with real-time load but in a non-ready state due to lack of data support, and the target recovery nodes they point to, are identified. The load data backlogged by the blocked nodes is reverse-mapped using a load transformation function, transforming it into a computing power compensation weight for the target recovery node. This weight is then combined with the real-time load of the target recovery node to generate target scheduling features. This allows the AI ​​model to comprehensively consider the load pressure transmitted from upstream nodes when allocating computing power, allocating resources preferentially to the target recovery node. With more sufficient computing power, the target recovery node can accelerate its business processing capabilities, thereby prompting the blocked nodes to meet the readiness conditions more quickly. Once ready, the reverse mapping stops and normal allocation resumes. Dynamically concentrating computing resources on the true bottleneck nodes of business recovery reduces the business request waiting latency of blocked nodes, improving the system's computing resource utilization efficiency and overall business link recovery speed during the disaster recovery takeover process.

[0060] In the above embodiments, the system performs dynamic scheduling and allocation of computing power at the macro level of nodes to accelerate the readiness of the target recovery node. However, during the transition period of the target recovery node's state recovery, blocked nodes often have a backlog of a large number of historical business requests of different types. If these backlogged requests are allocated indiscriminately or waited for blindly, it is easy to waste computing power and cause some available services to be blocked as well. Therefore, how to delve into the micro-level of business and accurately detect and classify different business requests within the blocked node to maximize the use of limited computing resources to ensure the operation of some services first is the key to further improving overall processing efficiency. Based on this, this application embodiment further provides another method for computing power load management using AI in disaster recovery centers. The following combines... Figure 2 Another method for managing the computing load of AI in a disaster recovery center, as described in the embodiments of this application, is as follows: Please see Figure 2 This is another flowchart illustrating a method for managing the computing load of an AI-based disaster recovery center, as described in this application.

[0061] S201. Extract the backlog of historical service requests from the blocked nodes and parse the service operation type carried by each historical service request. Historical business requests refer to business data packets that, during disaster recovery takeover, are temporarily residing in the request queue or persistent storage of a blocked node and have not yet been processed because the target recovery node is not yet fully ready. Business operation type refers to the specific business function category indicated by the historical business request, such as data query operations, data insertion operations, transaction commit operations, and file upload operations. Parsing refers to the process of extracting key fields that characterize the business attributes of a request data packet by disassembling its protocol header or payload.

[0062] The system can extract and parse requests by reading the in-memory message queue of the blocked node. The system calls the client application interface of the message middleware to connect to the message broker process inside the blocked node, and reads all historical business request messages backlogged in the in-memory queue using a cursor traversal. Subsequently, the system uses a JSON parsing library to deserialize the payload of each request message and extract specific fields. The system maps the values ​​of these fields to standard business operation type strings and associates the parsing results with the unique identifier of the original request message for later processing.

[0063] The system can also perform this step by analyzing the request logs persisted on the local disk of the blocked node. The system uses a log collection agent component to read the request temporary log files appended chronologically by the blocked node in the local file system, identifying each line of text data as a historical business request. Next, the system uses a regular expression matching engine to perform deep pattern matching on each line of log text, extracting specific business path segments from the Uniform Resource Identifier (URI) path or custom business type tags from the Hypertext Transfer Protocol (HTTP) header. Based on a pre-configured path-to-business operation type mapping table, the system converts the extracted feature strings into the corresponding business operation types, completing the parsing process.

[0064] S202. Classify historical business requests according to business operation type, and extract a preset number of business requests from each category to construct a real business probe set corresponding to the blocking node. Classification refers to the process of dividing a large number of unordered historical business requests into different logical sets based on the extracted business operation types. The preset quantity refers to the threshold number of request samples to be extracted from each business operation type set when constructing the probe set. This threshold is derived from historical performance testing experience data and aims to achieve statistically reliable probing results with a minimal request scale. The real business probe set is a data set composed of these request samples sampled from the actual backlog of requests. It is specifically used as a probe to send to downstream nodes in subsequent steps to verify the actual processing capabilities of the downstream nodes.

[0065] The system can construct the data using an in-memory hash table grouping and random sampling algorithm. First, the system initializes a hash map in memory, with business operation types as keys and lists of request message objects as values. The system iterates through the parsed historical business requests, inserting the request objects into the corresponding key-value lists based on their business operation types, thus completing the classification. Next, for each list in the hash table, the system calls a pseudo-random number generator to generate a corresponding number of random indices, and retrieves a preset number of business requests from the lists based on these random indices. Finally, the system adds all the extracted requests to another independent data structure, thereby constructing the real business probe set corresponding to the blocked nodes.

[0066] The system can also leverage the aggregation query and restricted sampling capabilities of relational databases. The system batch inserts all historical business requests and their parsed business operation types into a local lightweight relational database table. The system logically groups the data in the table according to the business operation type column by executing the grouping clause of a structured query language. Then, for each group, the system uses nested query statements containing clauses for random sorting and limiting the number of rows returned to directly and randomly select a preset number of request records at the database engine level. The system exports and serializes all the returned record rows, integrating them into a real business probe set for subsequent probing tasks.

[0067] S203. Divide the computing power resources of the blocked node into basic detection computing power and business unlocking computing power; The probing base computing power refers to a small portion of the resource quota specifically allocated from the total available computing power pool of the blocked node. This may include a small number of CPU time slices or a limited number of concurrent threads. It is used solely to support sending a small number of requests within the actual business probe set and processing the returned status data, thus avoiding excessive impact on the overall system resources. The business unlocking computing power refers to the vast majority of the remaining computing power resource quota, used to process and distribute the corresponding historical business requests on a large scale after the probe results confirm availability. These two portions of computing power are mutually exclusive, and their sum equals the total computing power currently allowed for use by the blocked node.

[0068] The system can allocate computing resources by configuring the Linux kernel's control group mechanism. Within the operating system's control group file system, the system creates two sub-level control group directories for the original resource process groups of blocked nodes, named the probe group and the service group, respectively. The system modifies the resource configuration file in the probe group directory, assigning it a smaller weight value and memory limit, defining it as the basic probe computing power. Simultaneously, the system allocates the remaining weight and memory quota to the service group directory, defining it as the service unlock computing power. The system uses process identifiers to bind the thread responsible for probe sending to the probe group and the main service processing thread to the service group, thereby achieving physical isolation and allocation of computing power.

[0069] The system can also utilize application-layer thread pool management mechanisms to implement computing power allocation at the software level. Within the business application process of the blocked node, the system instantiates two independent thread pools by modifying application configuration parameters. One thread pool has its core and maximum thread counts set to small, fixed values, specifically for handling the sending and callback listening of real business probe sets; this thread pool represents the basic computing power for probing. The other thread pool is configured with a larger, dynamically scalable scale based on the remaining available concurrent connections and memory capacity of the current system, for processing subsequent large-scale backlog requests; this thread pool carries the computing power for business unlocking.

[0070] S204. By probing the basic computing power, send the requests from the real business probe set to the target recovery node, and monitor the success rate feedback of the target recovery node for different types of business operation requests. The system sends requests from the real business probe set to the target recovery node by probing the basic computing power, and monitors the success rate feedback of the target recovery node for different types of business operation requests, specifically including: The real business probe set corresponding to the current business operation type is divided into a preheating probe subset and a verification probe subset. Based on the basic computing power of the probe, the preheating probe subset is sent to the target recovery node to trigger a cold start of the dependency link for the current business operation type, and the initial response status data returned by the target recovery node for the preheating probe subset is discarded. After a preset buffer delay, the verification probe subset is sent to the target recovery node based on the basic computing power of the probe. The business response status code returned by the target recovery node for the verification probe subset is collected, and the processing success rate feedback of the business operation type is calculated based on the business response status code.

[0071] The pre-warm-up probe subset refers to a portion of request samples separated from the actual business probe set. It is used to wake up dormant components, establish network connections, and populate caches before the formal probe. The verification probe subset consists of the remaining request samples from the actual business probe set, used to obtain accurate processing results after the system stabilizes. Dependency link cold start refers to the high-latency preparation process, such as resource allocation and database connection pool initialization, required when the target recovery node receives a request for the first time after a long period of no traffic. Initial response status data refers to unstable feedback returned by the target recovery node during cold start, such as timeout errors and connection rejections. Preset buffer delay refers to the time threshold for the system to wait for the cold start to complete, derived from the 95th percentile of historical cold start time statistics. Business response status codes are standardized processing result identifiers returned by the target node, such as the 200 and 500 status codes in the Hypertext Transfer Protocol. Processing success rate feedback is the ratio of the number of successfully processed requests to the total number of requests in the verification probe subset.

[0072] The system can implement this refined scheme using an asynchronous non-blocking network communication framework. In memory, the system proportionally divides the real business probe set belonging to a certain business operation type into two lists, serving as a pre-warm-up probe subset and a verification probe subset, respectively. Utilizing the thread pool corresponding to the probe's underlying computing power, the system calls the interface of the asynchronous communication framework to encapsulate the pre-warm-up probe subset into network data packets and send them to the target recovery node. In the callback function, all returned response message objects are directly discarded. The system uses a scheduler to set a countdown task with a preset buffer delay. When the countdown ends, the task triggers the sending of the verification probe subset. The system collects all returned response status codes, counts the number of successful status codes, and divides this by the total number of verification subsets to obtain the processing success rate feedback.

[0073] The system can also implement this refined scheme through message queue decoupling and a timed triggering mechanism. The system pushes the preheating probe subset and the verification probe subset to two different distributed message queue topics. The system starts a lightweight consumer process that uses the basic probing computing power to subscribe to the preheating topic, reads requests, and sends them to the target recovery node via a remote procedure call framework. The received initial response status data is directly garbage collected. Simultaneously, the system starts a scheduled task with a preset delay time. After the delay, another consumer process is triggered to subscribe to the verification topic and send a request. This process writes the business response status code returned by the target recovery node into a cache. The system then reads the cached data and calculates the success rate feedback for the current business operation type through aggregation.

[0074] S205. Compare the processing success rate feedback of each business operation type with the preset health baseline to determine the restricted business types that are in an abnormal micro-state and the available business types that are in a normal micro-state. The preset health baseline refers to the minimum success rate threshold that the system uses to determine whether a certain type of business operation has normal processing capabilities. This baseline is usually derived from the service level agreement (SLA) value of the business system. Micro-state anomalies refer to a specific business operation type whose processing success rate is lower than the preset health baseline because the corresponding underlying components (such as specific database table locks or specific microservice interfaces) of the target recovery node are not yet ready. Restricted business types are those whose processing success rates do not meet the standards. Available business types are those whose processing success rates are greater than or equal to the preset health baseline, indicating that their corresponding underlying links are fully operational and can normally process backlogged requests.

[0075] The system can compare and determine states through a rule engine and conditional judgment logic. The system loads the processing success rate feedback values ​​for each business operation type into an in-memory dictionary. The system calls the pre-deployed rule engine, inputting the data from the in-memory dictionary as fact objects into the rule's working memory. The rule engine defines a simple comparison rule script, which sequentially extracts the processing success rate for each business operation type and compares it with a preset health baseline floating-point value configured in the configuration center using relational operators. If the success rate is less than the baseline, the rule engine tags the business operation type string with a restricted label and outputs it as a restricted business type; if it is greater than or equal to the baseline, it tags it with an available label and outputs it as an available business type.

[0076] The system can also perform this process using a custom script calculation task. The system writes the success rate feedback data to a local temporary file. The system then executes a program using a scripting environment. This program uses a parsing library to read the file content and retrieves the preset health baseline value set in the environment variables. The program iterates through all business operation types and their corresponding success rates using a loop structure. Within the loop, conditional branching statements are used to perform numerical comparisons. Business operation types judged as abnormal are appended to the restricted type list file, while those judged as normal are appended to the available type list file. Finally, the system's main control process reads these two list files to complete the final determination of micro-level abnormal and normal business types.

[0077] S206. Suspend the allocation of service unlocking computing power to the backlog of requests belonging to restricted service types in the blocked nodes; Pausing allocation refers to the action of temporarily cutting off or preventing certain types of requests from acquiring additional computing resources at the system scheduling level. Service unlocking computing power refers to the resource quota mentioned earlier used for large-scale processing of backlogged requests. Pausing the allocation of service unlocking computing power to backlogged requests of restricted service types aims to avoid blindly issuing requests when the underlying environment is known to lack processing capabilities, leading to resource waste and network congestion.

[0078] The system can pause allocation by modifying the filtering rules of the request distribution router. The system sends control signaling to the request distribution router deployed inside the blocking node, containing a list of identifiers for restricted service types. Upon receiving the signaling, the distribution router dynamically updates its in-memory routing table rules, adding a drop or block policy. When the router scans the backlog of requests and prepares to unlock the corresponding thread for processing the service it's bound to, if the service operation type of the matched request belongs to a restricted service type, the blocking policy is triggered, skipping the request and not allocating any computing resources from the service group control group or service thread pool to it, thus pausing allocation.

[0079] The system can also achieve this through semaphore control and thread blocking mechanisms. In the memory of the blocking node, the system instantiates a semaphore object with an initial value of zero for each restricted business type. When the processing thread pool attempts to retrieve a request belonging to a restricted business type from the backlog queue, the system forces the thread to acquire the corresponding semaphore first. Since the semaphore's value is zero, the thread attempting to acquire the semaphore is suspended by the operating system kernel and placed in a waiting queue, thus preventing the execution of subsequent processing logic for that request. In this way, the system effectively freezes the process of unlocking computing power allocation for restricted business types without modifying the original backlog queue structure.

[0080] S207. Based on the amount of backlogged requests belonging to the available service type, allocate the corresponding service unlocking computing power to the blocked node.

[0081] Data volume refers to the total number of backlog requests belonging to a specific available service type in the queue or the total number of bytes of storage space occupied. Allocating the corresponding service unlocking computing power to the blocked node means dynamically mapping and activating the service unlocking computing power quota to the execution entity of the blocked node as needed, based on the actual load scale of the available services, in order to process these backlog requests that have been confirmed as available.

[0082] The system can dynamically adjust thread pool parameters to allocate computing power based on data volume. The system reads the backlogged request queue and counts the total number of requests for each available business type, i.e., the data volume. The system multiplies the data volume by a preset single-request processing resource consumption coefficient to calculate the required theoretical concurrency. Subsequently, the system calls the dynamic configuration interface of the business application's internal thread pool, passing the calculated concurrency as the target core thread count parameter. If the target value does not exceed the maximum thread count allowed by the business's unlocked computing power, the thread pool will automatically create and wake up the corresponding number of worker threads based on the passed parameters. These threads then directly pull requests of available business types from the queue for processing, completing the computing power allocation.

[0083] The system can also achieve this through dynamic reconfiguration of container resource request values. The system uses a monitoring component to query the queue length of backlogged available service type requests in the blocked node as a data volume indicator. This indicator is then passed to a custom elastic scaling controller deployed in the cluster. Internally, the controller runs a simple linear mapping function that converts the queue length into specific CPU and memory requirements. The controller submits a request to the management server to modify the container group resources of the blocked node, using the total amount of computing power unlocked by the service to increase the container's resource limits and request parameters. Upon receiving the configuration update, the underlying container runtime immediately allocates more hardware time slices to the container, enabling the application within the container to process the backlog of available service requests.

[0084] In the above embodiments, historical business requests backlogged from blocked nodes are extracted and categorized. Real requests are extracted to construct a business probe set. Computing power is divided into basic probe computing power and business unlocking computing power. A small amount of basic computing power is used to send real business probe requests. Without triggering large-scale invalid calls, the actual processing capability of the target recovery node for specific business types is accurately tested. By monitoring the processing success rate of different business operation types and comparing it with a health baseline, restricted business types and available business types are distinguished at a micro level. The allocation of business unlocking computing power to restricted type requests is suspended, preventing continuous processing failures and resource waste caused by blindly issuing requests. Simultaneously, unlocking computing power is accurately allocated based on the backlog of available types to ensure the smooth execution of available services. This improves the granularity of computing power scheduling in the disaster recovery system during periods of node instability, reduces the invalid computing power loss rate caused by blind allocation, and improves the actual processing efficiency of available business requests.

[0085] In the above embodiments, the system effectively distinguishes between restricted service types in a micro-state of abnormality and normal available service types through active detection, and selectively suspends the computing power allocation for restricted services to avoid resource waste. However, restricted services cannot be permanently suspended; the system must promptly detect the recovery status of their operating environment to reallocate computing power. Continuously relying on frequent active detection to confirm the status of restricted services will inevitably increase additional computing power overhead and crowd out network resources for normal services. Therefore, how to cleverly utilize the underlying feedback generated by the continuous operation of available services to implicitly and agilely detect whether the restricted service environment has recovered and is ready, without increasing the burden of active detection, becomes another important aspect of optimizing computing power management. To this end, this application embodiment further provides another method for computing power load management using AI in disaster recovery centers. The following combines... Figure 3 This application describes yet another method for managing the computing load of a disaster recovery center using AI, as described in its embodiments: Please see Figure 3 This is another flowchart illustrating a method for managing the computing load of AI in a disaster recovery center, as described in this application.

[0086] S301. Analyze the business execution topology of restricted business types and extract the set of underlying dependent components corresponding to the restricted business type on the target recovery node side; Business execution topology refers to the logical call relationship diagram between various software modules or data processing units that a specific business operation type traverses sequentially when executed within the system. The underlying dependency component set refers to the list of specific entities within the target recovery node that provide basic service support for the business, such as specific database instances, cache cluster nodes, message middleware topics, or third-party application programming interface endpoints. Extraction refers to the operation of identifying and separating the aforementioned specific entity identifiers from the data carrier describing the topology.

[0087] The system can achieve this step by parsing the static configuration file of the microservice registry. The system calls the application programming interface of the configuration management module to retrieve the list of pre-declared dependency configurations for the restricted business type in the microservice framework. The system uses the document object model parser to read the list content, and by traversing specific dependency injection tags, extracts all service interface names and database connection strings on the target recovery node side declared and called by the restricted business type. These extracted string identifiers are stored in a one-dimensional array, thereby constructing the underlying set of dependency components.

[0088] The system can also achieve this by mining historical data from the distributed tracing system. The system connects to the time-series database of the tracing backend, inputs the restricted business type as the query keyword, and extracts complete call chain data from successful executions of that business over a historical period. The system writes scripts to filter out span records belonging to the blocking node itself or other irrelevant nodes in the call chain, retaining only span records within the target recovery node's network domain. Subsequently, the system extracts the network address and port number of the actually accessed component from the tag fields of these span records, performs deduplication, and generates the final set of underlying dependent components.

[0089] S302. During the process of the blocked node continuously sending backlog requests corresponding to the available service type to the target recovery node using the service unlocking computing power, bypass listening to the internal component call trajectory and corresponding component running status feedback generated by the target recovery node for each available service type. Bypass monitoring refers to the act of acquiring real-time data interaction information within a node through side paths or mirroring without altering the original business request master data flow or interfering with normal business processing logic. Internal component call traces refer to the sequence record of method call order, input parameters, and return values ​​of the underlying dependent components triggered sequentially when the target recovery node processes a specific available business type request. Component runtime status feedback refers to the specific response results returned by each called component after execution, reflecting its health status, such as specific success status codes or execution time metrics.

[0090] The system can utilize aspect-oriented programming (AOP) techniques to deploy non-intrusive probes within the target recovery node for bypass monitoring. The probes intercept method call points of critical components within the target recovery node using bytecode enhancement technology. When available business requests flow in and trigger component calls, the probes automatically capture the method call stack sequence, generate internal component call traces, and record the return values ​​and exception information at the end of method execution as feedback on the component's runtime status. The probes then use a separate, low-priority background thread to serialize this data and asynchronously send it to the system's log collection endpoint.

[0091] The system can also utilize extended Berkeley packet filtering technology at the operating system kernel level. A specific filter program is injected into the host kernel of the target recovery node and mounted onto kernel probe points related to the network protocol stack and file system. When application processes interact with underlying components via the network or perform file read / write operations, the filter program captures the kernel-level system call process in real time, reconstructs it into the internal component call trajectory of the application layer, obtains status codes by parsing the response headers of network packets, forms component runtime status feedback, and finally passes it to the upper-layer system through the shared memory mapping area between kernel space and user space.

[0092] S303. Perform cross-dimensional mapping and comparison between the set of underlying dependent components and the collected call trajectories of various internal components to filter out the components with overlapping calls between restricted business types and available business types. The system performs a cross-dimensional mapping and comparison between the underlying dependency component set and the collected internal component call trajectories, filtering out components with overlapping calls between restricted and available business types. Specifically, these include: The process involves parsing the call attributes of each underlying dependent component in the underlying dependent component set, extracting the business operation permission requirements of restricted business types for each underlying dependent component, and constructing a component requirement matrix that includes component identifier dimensions and permission requirement dimensions. From the collected internal component call trajectories, the actual execution operation types of available business types for each called component are extracted. Based on the component identifier dimension, the called components and the component requirement matrix are aligned through entity mapping to identify target components with shared entities. The actual execution operation type corresponding to the target component is compared with the business operation permission requirements, and if the permission level of the actual execution operation type is greater than or equal to the business operation permission requirements, the target component is determined to be an intersection component that meets the requirements of the deep runtime environment.

[0093] Invocation attributes refer to the characteristic descriptions of specific operations initiated by business logic on underlying dependent components. Business operation permission requirements refer to the minimum permission level that the underlying component must grant to the invocation in order for this restricted business type to execute normally, such as read permission, write permission, or administrative permission. The component requirement matrix is ​​a two-dimensional data structure, where rows represent component identification dimensions and columns represent permission requirement dimensions. Actual execution operation type refers to the specific operations initiated by the available business type on the component during actual operation, such as query (read permission) and update (write permission). Entity mapping alignment refers to the process of matching records representing the same entity in two different data sets. The target component is the specific component that is confirmed to be commonly depended upon after alignment. The permission level is the numerical level after ranking and quantifying different permissions according to their operational influence. Deep runtime environment requirements mean that in addition to the component being online, it must also have sufficient operational permissions for this business. The intersection component is the target component that meets all requirements.

[0094] The system can be implemented using an in-memory hash table and a rule engine. The system parses the configuration of restricted services, using each component identifier as the key and the extracted business operation permission requirements (converted to integer values ​​of permission levels) as the value, constructing an in-memory dictionary as the component requirement matrix. The system traverses the call history of available services, extracting the actual operation types and converting them to integers. Using the component identifier as the key, it searches the dictionary; if a match is found, that component is the target component. The system calls the rule engine to compare the actual operation permission level value of the target component with the requirement value in the dictionary. If the actual value is greater than or equal to the requirement value, the component object is added to the intersection component list.

[0095] The system can also be implemented using relational database table joins and Structured Query Language (SCL). The system inserts component identifiers and business operation permission requirement levels into the restricted requirements table of the database. It parses the available business traces to extract component identifiers and actual execution permission level values, storing them in the available execution table. The system executes a query with an inner join clause, using the component identifier as the join condition to perform entity mapping and alignment, obtaining the target component result set. On this result set, the system further performs filtering with numerical comparison conditions that specify whether the actual execution permission level is greater than or equal to the required permission level, exporting records that meet the conditions as the intersection component.

[0096] S304. If it is determined that each intersection component completely covers the set of underlying dependent components, and each intersection component shows a normal response status in the component running status feedback, it is determined that the micro-running environment of the restricted business type has been implicitly restored and is ready. Complete coverage means that the number and types of elements in the intersection component set are completely consistent with the underlying dependent component set, with no omissions. Normal response state means that the status code returned by a component or the execution time is within a predefined healthy range. Micro-operational environment refers to the operational foundation specifically for a particular restricted business type, composed of all its dependent underlying components and their corresponding permissions and states. Implicit recovery readiness means that the operational environment required by the business is inferred to be ready based on the normal operation of available services, rather than through active detection.

[0097] The system can utilize set difference operations combined with logical judgments to achieve decision-making. The system instantiates the underlying dependent component set as a hash set data structure in memory. Subsequently, the system constructs another hash set from the identifiers of all extracted intersection components. The system calls set operation functions to calculate the difference between the underlying dependent component set and the intersection set. If the difference is empty, it proves that complete coverage has been achieved. Simultaneously, the system iterates through the status feedback data dictionary of the intersection components. If all feedback values ​​are equal to the preset success status code, a conditional branch statement is triggered, modifying the micro-operational environment parameters of the restricted business type to an implicitly restored ready state.

[0098] The system can also utilize bitmap masks and bitwise operations for judgment. The system assigns a unique binary bit index to each component in the underlying dependent component set, constructing a target mask where all bits corresponding to dependent components are set to 1. When an intersection component is received and its status feedback is parsed as a normal response, the system sets the corresponding bit to 1 in a state bitmap initially set to 0. The system compares the target mask and the state bitmap by performing a bitwise AND operation. If the result equals the target mask itself, it means all necessary components are ready, and the system generates a control message containing implicit recovery ready instructions.

[0099] S305. Convert the status flag of a restricted service type that is implicitly ready for recovery to an available service type; A status flag is an enumerated variable or field maintained internally by the system for each business operation type to indicate its current scheduling status. Converting to an available business type means modifying the value of this field, which was originally marked as restricted, to the same normal scheduling flag as the available business type through memory writes or database updates. This allows the system to allocate resources according to the normal process when subsequently processing requests of this type.

[0100] The system can achieve state flag conversion by modifying the business state registry in memory. Internally, the system maintains a global concurrent hash map, where the key is the name of the business operation type and the value is the corresponding state flag object. When it is determined that a restricted business type is implicitly ready for recovery, the system's main thread acquires the write lock for the corresponding key in the map, directly calls the object's update method, modifies the state attribute inside the state flag object from an enumerated constant representing restriction to an enumerated constant representing availability, and then releases the write lock, completing the memory-level state flag conversion.

[0101] The system can also achieve the conversion through a dynamic push mechanism of a distributed configuration center. The system sends a request to modify a data node to the distributed configuration server in the cluster. The request payload contains the path node for the target restricted business operation type and the new status data. Upon receiving the request, the configuration server updates its persistent storage and uses a publish-subscribe mechanism to push the latest status flag to all blocked node client processes that have subscribed to that node. After receiving the push, the blocked nodes update their local cache, converting the flag to an available business type.

[0102] S306. Allocate corresponding service unlocking computing power to the backlog of available service types to lift the suspension of computing power allocation for restricted service types.

[0103] The computing power allocation pause state refers to the scheduling freeze mechanism implemented in the aforementioned steps, which prevents the allocation of computing resources to backlogged requests due to the restricted state of the business. Releasing this state means revoking this scheduling restriction, restoring the normal binding relationship between the request queue and the computing power resource pool, and enabling new or backlogged requests of this type to normally obtain resources such as threads and memory for processing.

[0104] The system can achieve the release operation by releasing an operating system-level semaphore. In the previous steps, the system set a semaphore with an initial value of zero for the request processing thread of this restricted business type, putting the thread in a suspended state. When the status flag changes to available, the system calls the semaphore release function, increasing the count value of the associated semaphore to the maximum allowed concurrency. The suspended thread will be reawakened by the operating system's process scheduler after sensing that the semaphore is greater than zero. The awakened thread then retrieves requests from the backlog request queue and issues them for execution, thereby allocating the business unlocking computing power to these requests.

[0105] The system can also lift the block by rewriting the access control list of the application layer request router. The system sends a policy update signaling message to the request router inside the blocking node. After parsing the signaling message, the router finds the previously configured blocking rule for this restricted service operation type in the memory access control list and deletes or modifies it to a allowing rule. Subsequently, when the router's distribution engine polls the backlog of requests for this service type, it no longer triggers blocking actions but instead normally requests worker threads from the thread pool manager and binds resources to the requests, thus lifting the pause in computing power allocation.

[0106] In the above embodiments, the underlying dependency component set of the restricted service type is extracted by parsing the service execution topology. While the system continuously sends requests for available services, the internal component call trajectory and component running status of the target recovery node are monitored indirectly. Intersecting components with overlapping calls between available and restricted services are selected through cross-dimensional mapping comparison. When the intersecting components completely cover the underlying dependencies of the restricted service and all show a normal response state, it is directly determined that the micro-operational environment of the restricted service type has implicitly recovered and is ready. By utilizing the underlying component status feedback generated by available services in actual operation, the underlying operating environment of the restricted service is indirectly verified. This avoids repeated active probing of the restricted service, reduces the additional computing power overhead and network occupation during the service status probing process, improves the system's agility in perceiving the recovery readiness status of the restricted service, and thus shortens the service backlog time of the restricted service.

[0107] The system in the embodiments of this invention is described below from the perspective of hardware processing. Please refer to [link / reference needed]. Figure 4 This is a schematic diagram of the physical device structure of an AI-based computing load management system for disaster recovery centers, provided in an embodiment of this application.

[0108] It should be noted that, Figure 4 The structure of the system shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0109] like Figure 4As shown, the system includes a Central Processing Unit (CPU) 401, which can perform various appropriate actions and processes based on a program stored in Read-Only Memory (ROM) 402 or a program loaded from storage portion 408 into Random Access Memory (RAM) 403, such as executing the methods described in the above embodiments. The RAM 403 also stores various programs and data required for system operation. The CPU 401, ROM 402, and RAM 403 are interconnected via a bus 404. An Input / Output (I / O) interface 405 is also connected to the bus 404.

[0110] The following components are connected to I / O interface 405: input section 406 including a camera, infrared sensor, etc.; output section 407 including a liquid crystal display (LCD) and speakers, etc.; storage section 408 including a hard disk, etc.; and communication section 409 including a network interface card such as a LAN (Local Area Network) card and a modem, etc. Communication section 409 performs communication processing via a network such as the Internet. Drive 410 is also connected to I / O interface 405 as needed. Removable media 411, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 410 as needed so that computer programs read from it can be installed into storage section 408 as needed.

[0111] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing computer programs for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 409, and / or installed from removable medium 411. When the computer program is executed by central processing unit (CPU) 401, it performs the various functions defined in the present invention.

[0112] It should be noted that the computer-readable medium shown in the embodiments of the present invention can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In the present invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In the present invention, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, wherein a computer-readable computer program is carried. The transmitted data signal can take many forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof.

[0113] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0114] In another aspect, the present invention also provides a computer-readable storage medium, which may be included in the system described in the above embodiments; or it may exist independently and not assembled into the system. The storage medium carries one or more computer programs that, when executed by a processor of a system, cause the system to implement the methods provided in the above embodiments.

[0115] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

[0116] As used in the above embodiments, depending on the context, the term "when..." can be interpreted as "if...", "after...", "in response to determining...", or "in response to detecting...". Similarly, depending on the context, the phrase "when determining..." or "if (the stated condition or event) is detected" can be interpreted as "if determining...", "in response to determining...", "when (the stated condition or event) is detected", or "in response to detecting (the stated condition or event)".

[0117] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive), etc.

[0118] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A method for managing the computing load of AI in a disaster recovery center, characterized in that, include: Obtain the logical dependency topology diagram of the disaster recovery takeover business system, and collect the real-time load data and ready status identifier of each business node in the logical dependency topology diagram. The ready status identifier is used to characterize whether the corresponding business node has the data support conditions to process business requests. Based on the logical dependency topology and the ready status identifier of each business node, the blocked nodes that are not ready and have real-time load data are selected from each business node, and the target recovery node pointed to by the blocked node in the logical dependency topology. By using a preset load conversion function, the real-time load data of the blocked node is reverse-mapped along the logical dependency topology to obtain the computing power compensation weight of the target recovery node. The real-time load data of the target recovery node is combined with the computing power compensation weight to generate target scheduling features; The target scheduling features are input into a pre-trained AI computing power allocation model to obtain a computing power allocation strategy for the target recovery node; Allocate computing resources to the target recovery node according to the computing power allocation strategy; When the ready status identifier of the target recovery node is updated to the ready status, the reverse mapping of the real-time load data of the blocked node is stopped, and the computing resource allocation of the blocked node based on the real-time load data is restored.

2. The method according to claim 1, characterized in that, The step of reverse mapping the real-time load data of the blocked node along the logical dependency topology graph using a preset load transformation function to obtain the computing power compensation weight of the target recovery node specifically includes: Extract the request retry frequency and concurrent queuing depth from the real-time load data of the blocked node; Calculate the load effectiveness attenuation coefficient based on the request retry frequency; The effective load pressure value of the blocked node is obtained by multiplying the concurrent queuing depth by the load effectiveness attenuation coefficient. Traverse the logical dependency topology graph to determine the topological path distance between the blocked node and the target recovery node; The effective load pressure value and the topology path distance are input into the preset load conversion function to calculate the distance attenuation and obtain the computing power compensation weight of the target recovery node.

3. The method according to claim 1, characterized in that, The step of combining the real-time load data of the target recovery node with the computing power compensation weight to generate target scheduling features specifically includes: Extract the real-time load data of the target recovery node and its resource utilization in the computing, storage, and network dimensions; By comparing the resource utilization rates of the computing dimension, the storage dimension, and the network dimension, the bottleneck resource dimension of the target recovery node can be determined. By using a preset cross-node resource mapping matrix, the computing power compensation weight is projected onto the bottleneck resource dimension, so as to convert the scalar computing power compensation weight into a multi-dimensional resource demand compensation vector. The multi-dimensional resource demand compensation vector is concatenated with the real-time load data of the target recovery node using tensor feature vectors to obtain a concatenated feature matrix. The spliced ​​feature matrix is ​​normalized to generate target scheduling features.

4. The method according to claim 1, characterized in that, The method further includes: Extract the backlog of historical service requests from the blocked nodes and parse the service operation type carried by each historical service request; The historical service requests are classified according to the service operation type, and a preset number of service requests are extracted from each category to construct a real service detection set corresponding to the blocking node. The computing resources of the blocked node are divided into basic detection computing power and service unlocking computing power; The detection base computing power is used to send the requests from the real business detection set to the target recovery node, and the success rate feedback of the target recovery node for processing requests of different business operation types is monitored. By comparing the processing success rate feedback of each of the aforementioned business operation types with a preset health baseline, the restricted business types that are in an abnormal micro-state and the available business types that are in a normal micro-state are identified. Suspend the allocation of service unlocking computing power to the backlog of requests belonging to restricted service types in the blocked node; Based on the amount of backlogged requests belonging to the available service type, the corresponding service unlocking computing power is allocated to the blocking node.

5. The method according to claim 4, characterized in that, The step of sending requests from the real business detection set to the target recovery node using the detection infrastructure computing power, and monitoring the success rate feedback of the target recovery node for different business operation types of requests, specifically includes: The real business probe set corresponding to the current business operation type is divided into a preheating probe subset and a verification probe subset; Based on the aforementioned detection computing power, the preheating detection subset is sent to the target recovery node to trigger a cold start of the dependent links for the current business operation type, and the initial response status data returned by the target recovery node for the preheating detection subset is discarded. After a preset buffer delay, the verification probe subset is sent to the target recovery node based on the basic detection computing power; Collect the service response status codes returned by the target recovery node for the verification probe subset, and calculate the processing success rate feedback of the service operation type based on the service response status codes.

6. The method according to claim 4, characterized in that, After allocating the corresponding service unlocking computing power to the blocked node based on the amount of backlogged requests belonging to the available service type, the method further includes: Analyze the business execution topology of the restricted business type and extract the set of underlying dependent components corresponding to the restricted business type on the target recovery node side; While the blocked node continuously sends the backlog requests corresponding to the available service type to the target recovery node using the service unlocking computing power, the system bypasses and listens to the internal component call trajectory and corresponding component running status feedback generated by the target recovery node for each available service type. The underlying dependent component set is compared with the collected internal component call trajectories across dimensions to filter out the components with overlapping calls between the restricted business type and the available business type; If it is determined that each of the intersection components completely covers the set of underlying dependent components, and each of the intersection components shows a normal response state in the component running status feedback, it is determined that the micro-running environment of the restricted service type has been implicitly restored to readiness. Convert the status flag of the restricted service type that is implicitly ready for recovery to an available service type; Allocate corresponding computing power to the backlog of available service types to unlock the service, thereby lifting the computing power allocation pause status of the restricted service types.

7. The method according to claim 6, characterized in that, The step of performing a cross-dimensional mapping and comparison between the set of underlying dependent components and the collected call trajectories of each of the internal components to filter out the components with overlapping calls between the restricted business type and the available business type specifically includes: The call attributes of each underlying dependent component in the underlying dependent component set are parsed, the business operation permission requirements of each underlying dependent component for the restricted business type are extracted, and a component requirement matrix containing component identifier dimension and permission requirement dimension is constructed. From the collected internal component call trajectories, extract the actual execution operation type of the available business type for each called component; Based on the component identifier dimension, the invoked component is aligned with the component requirement matrix through entity mapping to identify target components that share entities. The actual operation type corresponding to the target component is compared with the business operation permission requirements. If the permission level of the actual operation type is greater than or equal to the business operation permission requirements, the target component is determined to be the intersection component that meets the requirements of the deep runtime environment.

8. A computing load management system for AI used in disaster recovery centers, characterized in that, The system includes: One or more processors and a memory; the memory is coupled to the one or more processors, the memory being used to store computer program code, the computer program code including computer instructions, the one or more processors invoking the computer instructions to cause the system to perform the method as described in any one of claims 1-7.

9. A computer-readable storage medium comprising instructions, characterized in that, When the instructions are executed on the system, the system performs the method as described in any one of claims 1-7.

10. A computer program product, characterized in that, When the computer program product is run on the system, the system performs the method as described in any one of claims 1-7.

Images