A cloud computing-based resource scheduling method and system

Abstract

The application relates to the technical field of cloud computing resource scheduling, and discloses a resource scheduling method and system based on cloud computing, which comprises the following steps: acquiring a dependency relationship graph of multiple tasks in a cloud environment, capturing feedback data of corresponding completion states of the multiple tasks in real time, iteratively updating path weights of nodes in the dependency relationship graph in combination with the feedback data, fusing the updated path weights and a topological structure of the dependency relationship graph to obtain a priority execution sequence of the multiple tasks, synchronously monitoring real-time resource occupancy and a task waiting queue in the cloud environment to obtain a resource load conflict mapping table of the multiple tasks, releasing conflict resource nodes occupied by low-priority tasks in the multiple tasks based on the resource load conflict mapping table, and re-binding the released conflict resource nodes to high-weight nodes between nodes according to the priority execution sequence; the application can solve the problems of scheduling rigidity, resource conflict response lag and low resource utilization caused by the fact that a cloud computing resource scheduling method depends on a static strategy.

Description

Technical Field

[0001] This invention relates to the field of cloud computing resource scheduling technology, and in particular to a cloud computing-based resource scheduling method and system. Background Technology

[0002] In cloud computing environments, task scheduling and resource allocation are core components for ensuring system efficiency and service quality. Existing technologies mostly employ static or semi-static resource scheduling strategies. These methods treat tasks as independent units, making it difficult to accurately depict the sequential constraints and resource contention relationships within complex workflows. Their scheduling decisions largely rely on initial configuration or offline analysis, failing to adaptively adjust based on actual progress and resource usage changes during task execution. This leads to rigid task execution sequences, increased critical path delays, and overall low scheduling efficiency. In multi-tasking, high-concurrency cloud environments, this can easily result in both resource idleness and task blocking.

[0003] Existing methods for mitigating resource conflicts often employ passive response mechanisms, lacking collaborative analysis of real-time system resource status and task waiting queues, as well as proactive conflict prediction. These methods typically trigger resource reclamation based solely on instantaneous resource utilization or simple thresholds, making it difficult to accurately identify conflict hotspots caused by both task dependencies and resource contention. Furthermore, they fail to intelligently rebind resources based on updated task priorities and topology relationships after release. This results in a coarse-grained resource release and reallocation process, easily leading to resource fragmentation, frequent task starts and stops, and system instability, reducing the stability of resource utilization and the determinism of task execution. Summary of the Invention

[0004] This invention provides a resource scheduling method and system based on cloud computing, the main purpose of which is to address the problems raised in the background section above.

[0005] To achieve the above objectives, the present invention provides a resource scheduling method based on cloud computing, comprising: S1: Obtain the dependency graph of multiple tasks in the cloud environment; S2: Real-time capture of feedback data on the completion status of the multi-task, and iteratively update the path weights of the nodes in the dependency graph based on the feedback data; S3: Integrate the updated path weights with the topology of the dependency graph to obtain the priority execution sequence of the multi-tasks; S4: Synchronously monitor the real-time resource utilization and task waiting queue in the cloud environment to obtain the resource load conflict mapping table of the multi-task. S5: Based on the resource load conflict mapping table, release the conflicting resource nodes occupied by the low-priority tasks in the multi-task process; S6: Rebind the released conflicting resource nodes to the high-weight nodes among the nodes according to the priority execution sequence.

[0006] Preferably, obtaining the dependency graph of multiple tasks in the cloud environment includes: Collect a list of interoperability relationships between multiple tasks in the cloud environment, and determine the dependency framework of the relationship list; The dependency graph of the multi-task is drawn using the aforementioned dependency framework.

[0007] Preferably, the real-time capture of feedback data corresponding to the completion status of the multiple tasks includes: Subscribe to the task execution logs of multiple tasks in the cloud environment, and compile the key fields in the task execution logs into process status codes; The resource usage statistics corresponding to the multitasking are determined by combining the process status codes. The process status code and the resource usage statistics are encapsulated into the feedback data of the multi-task.

[0008] Preferably, the step of iteratively updating the path weights of nodes in the dependency graph based on the feedback data includes: Based on the feedback data, determine the sequence of delay ratios for the completion of the corresponding tasks in the multi-task scenario; The resource usage statistics and the latency ratio sequence are coupled by an execution efficiency deviation to obtain the execution efficiency deviation index of the latency ratio sequence; The dependency propagation gain value of the nodes in the dependency graph is determined by combining the execution efficiency deviation index; The dependency propagation gain value and the current path weight of the dependency graph are dynamically superimposed to obtain the updated path weight.

[0009] Preferably, the fusion and updating of the path weights and the topology of the dependency graph to obtain the priority execution sequence of the multi-tasks includes: The depth of the critical path in the dependency graph is parsed based on the updated path weights to obtain the source node depth identifier of the dependency graph. The source node depth identifier and the path weight are concatenated into a hierarchical weight matrix, and the weighted priority of the node is determined by the hierarchical weight matrix; Verify the topological connectivity of the weighted priority to obtain the priority execution sequence of the multi-tasks.

[0010] Preferably, the step of synchronously monitoring the real-time resource occupancy and task waiting queue in the cloud environment to obtain the resource load conflict mapping table for the multi-task includes: Subscribe to the real-time consumption metrics of physical resource nodes in the cloud environment; The queue delay of the topology state corresponding to the task waiting queue is analyzed to obtain the delay sequence of the virtual resource allocation corresponding to the task waiting queue; The delay sequence and the real-time consumption index are coupled and analyzed to obtain the task packing density spectrum; Identify the conflict cores in the task stacking density spectrum to obtain a resource load conflict mapping table for the task stacking density spectrum.

[0011] Preferably, the step of releasing conflicting resource nodes occupied by low-priority tasks in the multi-task scenario based on the resource load conflict mapping table includes: The resource load conflict mapping table and the priority execution sequence are used to filter low-priority tasks to obtain a release task filtering spectrum; The interruptible state of the release task screening spectrum and the task execution log is verified to obtain the task execution state probe sequence; A resource isolation buffer pool is constructed for the task execution status probe sequence to generate the resource isolation buffer pool; Perform conflict resource unbinding on the resource isolation buffer pool to obtain a set of unbinding operations; The set of unbinding operations is aggregated to obtain conflicting resource nodes.

[0012] Preferably, the step of rebinding the released conflicting resource nodes to the high-weight nodes among the nodes according to the priority execution sequence includes: The conflicting resource nodes are parsed using physical resource units to obtain a set of released resource unit mappings; The node weight hierarchy is filtered based on the weight sorting of the priority execution sequence to obtain high-weight nodes; A resource requirement affinity scan is performed on the topology of the high-weight nodes and the dependency graph to obtain the resource node topology affinity matrix; A dynamic binding queue is constructed by performing a dynamic binding queue on the released resource unit mapping set and the resource node topology affinity matrix to obtain a resource binding operation queue; The native resource mounting interface of the cloud environment is invoked to rebind nodes in the resource binding operation queue to obtain a weighted node binding result set.

[0013] Preferably, the formula for calculating the execution efficiency deviation index is: in: The execution efficiency deviation index. For resource occupancy tensor modulus, For cumulative delay curvature factor, To quantize the blocking threshold, To accommodate covariance factors, Entropy that depends on propagation gain Delay ratio gradient, As a phase transition indicator, It is a measure of critical resource manifold.

[0014] A cloud computing-based resource scheduling system, the system comprising: Dependency graph building module, used to obtain the dependency graph of multiple tasks in a cloud environment; The weight dynamic update module is used to capture feedback data on the completion status of the multi-task in real time, and to iteratively update the path weights of the nodes in the dependency graph in combination with the feedback data. The task sequence optimization module is used to fuse the updated path weights with the topology of the dependency graph to obtain the priority execution sequence of the multi-tasks; The conflict monitoring and analysis module is used to synchronously monitor the real-time resource utilization and task waiting queue in the cloud environment to obtain the resource load conflict mapping table of the multi-task. The resource release scheduling module is used to release conflicting resource nodes occupied by low-priority tasks in the multi-task based on the resource load conflict mapping table. The resource rebinding module is used to rebind released conflicting resource nodes to high-weight nodes among the nodes according to the priority execution sequence.

[0015] Compared with the prior art, the present invention has the following beneficial effects:

[0016] This invention captures real-time feedback data on task completion status and dynamically updates path weights in the dependency graph, making scheduling based on data that is no longer static and preset, but continuously evolving with the actual system operation. By integrating the updated weights with the topology to generate a priority execution sequence, this mechanism accurately identifies and prioritizes the execution of critical path tasks, effectively reducing inter-task blocking and waiting times, shortening the overall workflow completion time, and improving system throughput and response speed. Its dynamic adjustment capability allows the system to maintain high scheduling performance even when facing uncertainties such as load fluctuations and task execution deviations.

[0017] This invention constructs a resource load conflict mapping table by synchronously monitoring real-time resource occupancy and task waiting queues, enabling predictive insights into potential resource contention hotspots. Based on this mapping table, conflicting resources occupied by low-priority tasks are precisely released, and these resources are rebound to high-weight nodes according to priority, significantly improving resource utilization efficiency and turnover rate, and effectively reducing system turbulence and performance fluctuations caused by resource contention. The topology-aware resource rebinding strategy enhances the affinity between resource allocation and task dependencies, reduces resource fragmentation, and improves the overall stability and reliability of resource scheduling in large-scale cloud environments. Attached Figure Description

[0018] Figure 1 This is a flowchart illustrating a cloud computing-based resource scheduling method according to an embodiment of the present invention.

[0019] Figure 2 A functional block diagram of a cloud computing-based resource scheduling system provided in an embodiment of the present invention;

[0020] The objectives, features, and advantages of this invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0021] It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0022] This application provides a cloud computing-based resource scheduling method. The executing entity of this cloud computing-based resource scheduling method includes, but is not limited to, at least one of the following electronic devices that can be configured to execute the method provided in this application: a server, a terminal, etc. In other words, the cloud computing-based resource scheduling method can be executed by software or hardware installed on a terminal device or a server device. The server includes, but is not limited to, a single server, a server cluster, a cloud server, or a cloud server cluster. The server can be an independent server or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks, and big data and artificial intelligence platforms.

[0023] Reference Figure 1 The diagram shown is a flowchart illustrating a cloud computing-based resource scheduling method according to an embodiment of the present invention. In this embodiment, the cloud computing-based resource scheduling method includes: S1: Obtain the dependency graph of multiple tasks in the cloud environment; In this embodiment of the invention, obtaining the dependency graph of multiple tasks in the cloud environment includes: Collect a list of interoperability relationships between multiple tasks in the cloud environment, and determine the dependency framework of the relationship list; The dependency graph of the multi-task is drawn using the aforementioned dependency framework.

[0024] Specifically, a cloud environment refers to a service platform that provides on-demand computing resources, such as virtual machines, containers, storage, and networks, in which multiple computing jobs submitted by users or systems run.

[0025] Specifically, multitasking refers to multiple computing units or job instances with independent identification and resource requirements that are waiting to be scheduled and executed in the cloud environment.

[0026] Specifically, an interoperable relation list is a data set in which each record explicitly describes an interaction or constraint relationship between any two tasks in a multitasking scenario.

[0027] Specifically, the dependency framework is a logical structure model of all dependency types and directions between tasks, derived from an interoperable list of relationships through analysis and induction.

[0028] Specifically, a dependency graph is a graphical data structure representing the final collection of all dependencies between multiple tasks.

[0029] Furthermore, firstly, the scheduling system needs to connect to the management plane or data plane of the cloud environment. The system will proactively send query requests to the task orchestration engine or listen for task submission events. The system extracts metadata about task definitions from these sources.

[0030] Next, the system parses these fields, identifies other task identifiers referenced in the fields, and thus collects raw relationship records such as task A depending on the output of task B or task C sharing the same configuration volume with task D.

[0031] Finally, the system organizes and deduplicates all identified binary relation pairs, and arranges them in a unified format to form a structured list of interoperable relations. This list is the raw, unprocessed dependency data.

[0032] Furthermore, a logical analysis is performed to establish a more formalized structure. Each relation record in the list is traversed, and dependencies are categorized, for example, into data flow dependencies, control flow dependencies, or resource affinity dependencies.

[0033] Then, check whether these relationships form circular dependencies, i.e., tasks waiting for each other, and mark the detected circular dependencies or handle them according to preset rules.

[0034] Next, all tasks are treated as nodes, and dependencies are treated as directed edges to construct an initial logical graph model. In this model, the system analyzes the in-degree and out-degree of the nodes, identifying source nodes with no preceding dependencies and sink nodes with no subsequent dependencies.

[0035] Ultimately, this logical model, which includes all task nodes, dependency edges with category labels, and overall topological features such as hierarchy and ring information, was established as a dependency framework. This framework clarifies the static logic of dependencies but does not contain any runtime state.

[0036] Furthermore, the logical framework is transformed into a data structure that can be directly used for scheduled computation. The system reads the established dependency framework. Based on the node set and edge set defined in the framework, the system instantiates a graph object in memory or a dedicated graph database.

[0037] Each task is created as a graph node object, with node attributes including at least the task ID and type. Each dependency is created as a directed edge object from the preceding task node to the succeeding task node, with the edge attribute containing the dependency type.

[0038] This instantiated graph data structure, residing in computer memory, is the final multi-task dependency graph. This graph can be efficiently traversed, queried, and modified by subsequent modules.

[0039] In summary, the combination and drawing operations instantiate the logical skeleton into an operable tool, generating a battle map—a dependency graph—that the scheduling system can directly read and analyze.

[0040] In summary, the above steps enable the scheduling system to understand the constraints between tasks and avoid invalid scheduling that violates dependency order. Secondly, it provides a platform for graph analysis and computation for subsequent steps, such as updating path weights and detecting resource conflicts. Without the dependency graph established in this step, all subsequent intelligent optimizations based on task dependencies would lack a foundation and basis.

[0041] S2: Real-time capture of feedback data on the completion status of the multi-task, and iteratively update the path weights of the nodes in the dependency graph based on the feedback data; The real-time capture of feedback data corresponding to the completion status of the multi-task includes: Subscribe to the task execution logs of multiple tasks in the cloud environment, and compile the key fields in the task execution logs into process status codes; The resource usage statistics corresponding to the multitasking are determined by combining the process status codes. The process status code and the resource usage statistics are encapsulated into the feedback data of the multi-task.

[0042] The iterative update of the path weights of nodes in the dependency graph based on the feedback data includes: Based on the feedback data, determine the sequence of delay ratios for the completion of the corresponding tasks in the multi-task scenario; The resource usage statistics and the latency ratio sequence are coupled by an execution efficiency deviation to obtain the execution efficiency deviation index of the latency ratio sequence; The dependency propagation gain value of the nodes in the dependency graph is determined by combining the execution efficiency deviation index; The dependency propagation gain value and the current path weight of the dependency graph are dynamically superimposed to obtain the updated path weight.

[0043] The formula for calculating the execution efficiency deviation index is as follows: in: The execution efficiency deviation index. For resource occupancy tensor modulus, For cumulative delay curvature factor, To quantize the blocking threshold, To accommodate covariance factors, Entropy that depends on propagation gain Delay ratio gradient, As a phase transition indicator, It is a measure of critical resource manifold.

[0044] Specifically, a cloud environment refers to a distributed computing platform that deploys virtualized resource pools, including compute instances, storage volumes, and network resources, and provides task execution services.

[0045] Specifically, multitasking refers to multiple independent or interconnected compute job instances that are in the scheduling and execution lifecycle within the cloud environment.

[0046] Specifically, the completion status refers to the stage or final execution result reached by each task instance in a multi-task process within its lifecycle.

[0047] Specifically, feedback data refers to a structured data package generated in this step, which integrates the process status of task execution and a snapshot of resource consumption.

[0048] Specifically, a task execution log is a text or structured data stream that is automatically generated by a task runtime in a cloud environment, such as a container engine, virtual machine monitor, or job management system, and records task execution events and detailed information in chronological order.

[0049] Specifically, key fields refer to data items with specific indicative significance that are filtered out from the raw and complex task execution logs according to the needs of scheduling decisions.

[0050] Specifically, a process status code is a machine-readable code that concisely and unambiguously represents the current completion status of a task after standardizing and normalizing the information about the task execution result in the key fields.

[0051] Specifically, resource usage statistics refer to a set of quantitative measures of various cloud environment resources consumed by each task instance in a multitasking process at a specific time period or state point, such as CPU core time, memory capacity, disk I / O, and network bandwidth.

[0052] Furthermore, firstly, the data capture module of the scheduling system needs to establish a connection with the infrastructure logging services of the cloud environment, such as container runtime log drivers, system log services, or centralized log management platforms. It then initiates a continuous subscription request to these logging services based on a push or long polling mechanism.

[0053] In this request, the module explicitly specifies the list of task identifiers for the multi-tasks it is interested in, and may define filtering conditions. Once the subscription relationship is established, the log service will push new log entries matching the conditions from the runtime of the specified tasks to the capture module of the scheduling system in real time as a data stream. The module maintains an independent log receiving buffer for each task to ensure the orderliness and integrity of the log stream, thereby continuously acquiring first-hand text records reflecting the task execution situation.

[0054] Furthermore, after receiving the raw task execution log stream, the capture module parses each log entry. The module has pre-defined field extraction rules that locate and extract predefined key fields from the log text. Then, the module calls a status mapper that has a built-in lookup table from the raw log values ​​to standard process status codes.

[0055] Furthermore, once the process status code is compiled, the system triggers a resource metric collection action. The scheduling system's resource monitoring agent, or by calling the cloud platform's monitoring API, initiates a query to the physical host or virtualization layer hosting the task.

[0056] The system receives raw monitoring data from the resource layer, aggregates and calculates it according to the task identifier, and generates the resource usage statistics for the task at the corresponding time point.

[0057] Next, create a standard format data structure. The process status codes and resource usage statistics belonging to the same task and time slice, generated in the previous step, are placed into this structure as its core content.

[0058] At the same time, some metadata is usually encapsulated. This packaging and encapsulation action integrates scattered state information and resource information into a complete, self-describing feedback data unit.

[0059] Subsequently, the data unit is placed in a high-priority internal message queue or directly passed to the next processing module of the scheduling system, marking the completion of this capture-compile-determine-encapsulate process.

[0060] In summary, the subscription operation establishes a persistent, low-latency data connection channel with the cloud environment operation site. It is the source of all real-time sensing, ensuring that the scheduling system can hear every heartbeat and alarm of the task.

[0061] In summary, the deterministic operation links the abstract task state with the concrete resource consumption, and by combining status codes to trigger precise resource auditing, it provides a key quantitative basis for evaluating task execution efficiency and resource costs.

[0062] In summary, the encapsulation process is the final step in data production. It standardizes and packages the processed information products, making the feedback data an information capsule that can be efficiently and reliably transmitted between various modules within the system.

[0063] In summary, the above steps construct an automated production line from raw runtime signals to standardized scheduling feedback information.

[0064] First, it frees the scheduling system from dependence on periodic polling or delayed reporting, enabling near real-time perception of task status. Second, the structured feedback data it produces integrates information from both status and resource dimensions, providing high-quality and timely input data for subsequent steps such as weight iteration updates and conflict analysis.

[0065] Specifically, feedback data refers to the task runtime information package that has been captured and encapsulated in the preceding steps, containing process status codes and resource usage statistics.

[0066] Specifically, the task completion delay ratio sequence is a numerical sequence organized by task or time segment, quantifying the deviation between the actual completion time of each task and its expected or baseline completion time. It is calculated from the status and time information in the feedback data and reflects the timeliness of task execution.

[0067] Specifically, resource usage statistics refer to the set of specific values ​​extracted from feedback data that describe the consumption of various cloud resources by tasks, such as CPU, memory, and I / O.

[0068] Specifically, execution efficiency deviation coupling refers to an analytical processing action that aims to correlate resource usage statistics with latency ratio sequences to comprehensively evaluate their matching relationship.

[0069] Specifically, the execution efficiency deviation index is a comprehensive scalar indicator produced by coupling actions through execution efficiency deviation.

[0070] Specifically, a dependency graph is a graph data structure that represents the dependency logic between multiple tasks, and includes nodes and directed edges.

[0071] Specifically, the dependency propagation gain value is an adjustment coefficient calculated based on the execution efficiency deviation index and applied to a specific node in the dependency graph.

[0072] Specifically, the current path weight refers to the weight value carried by each directed edge in the dependency graph before the current update iteration, and this weight value affects the priority of the path.

[0073] Specifically, dynamic overlay refers to a computational operation that combines the calculated dependency propagation gain value with the existing current path weights on the edge according to specific rules.

[0074] Specifically, the updated path weight refers to the new edge weight value obtained after dynamic overlay operation, which is used to guide the scheduling decision in the next round.

[0075] Furthermore, the received feedback data stream is first categorized by task ID. For each task, the system extracts its process status code sequence and associated timestamp. When the system recognizes a status code indicating task completion, it records that moment as the actual completion time.

[0076] The system then retrieves the preset expected completion time for the task or the baseline completion time estimated from historical data. It calculates the difference between the actual completion time and the expected completion time, and divides this difference by the expected completion time or another baseline duration to obtain a proportional value representing the degree of delay; this is the delay ratio for the task.

[0077] The system performs this calculation on all completed multitasking tasks within the current monitoring period, and arranges them according to the order of tasks in the dependency graph or the order of completion time, ultimately generating an ordered list of values, which is the sequence of task completion delay ratios.

[0078] Furthermore, the system synchronously acquires resource usage statistics for the same batch of tasks, such as average CPU utilization, peak memory usage, and latency ratios. The core of the coupling analysis is to examine the relationship between resource consumption and execution latency. The system does not simply compare individual values, but rather constructs a resource-latency correlation pair for each task.

[0079] If a task consumes a high amount of resources but still incurs significant latency, its execution efficiency is considered severely flawed; conversely, if resource consumption is low and latency is minimal, the flaw is small. The system uses an internal evaluation logic to perform a comprehensive analysis, normalization, and aggregation of the resource-latency relationships of all tasks. Ultimately, it calculates a single indicator that represents the overall resource utilization efficiency and schedule compliance of this batch of tasks—the execution efficiency deviation index.

[0080] Furthermore, the calculated execution efficiency deviation index is used as a key input. The update module iterates through each task node in the dependency graph. For each node, the module considers the performance of that node's own task in the latest feedback data, such as its individual latency ratio and resource consumption, and takes into account the overall system stress reflected by the global execution efficiency deviation index. The module determines a dependency propagation gain value for that node based on a set of built-in rules.

[0081] Furthermore, the weights of the dependency graph are modified. For any directed edge in the graph, i.e., the path from parent node A to child node B, its current path weight is known. The system obtains the dependency propagation gain value corresponding to the parent node A of this edge.

[0082] Dynamic overlay operation means that the system applies the gain value to the current path weight of the edge in some way, such as addition, multiplication, or a more complex function, based on the sign and magnitude of the gain value. This overlay process is dynamic because the gain value calculated in each iteration is different, and the overlay rule may take into account the historical trend of weight changes. After performing this operation on all edges in the graph originating from nodes with non-zero gain values, each edge receives a new weight value, i.e., the updated path weight.

[0083] In summary, the execution efficiency deviation coupling operation is the core diagnostic step. By correlating resource consumption and time delay, it comprehensively diagnoses the health index of task execution from a cost-benefit perspective, and integrates isolated resource data and delay data into signals with decision-making significance.

[0084] In summary, determining the propagation gain value combines the global efficiency deviation signal with the performance of each specific node in the graph, microscopically transforming the macroscopic problem and calculating a specific responsibility coefficient or influence coefficient for each source of influence in the graph.

[0085] In summary, the dynamic overlay operation is the final adjustment action, which applies the calculated influence coefficients to each relevant path in the dependency graph in a practical and differentiated manner, thereby completing an online redraw of the scheduling priority map.

[0086] In summary, the overall effect of the above steps is to realize a closed-loop adaptive adjustment loop for the scheduling strategy based on real-time operational feedback. Its impact is to endow the scheduling system with learning and adaptive capabilities.

[0087] First, it transforms the dependency graph from a static topological description into a heat map that can dynamically adjust priorities based on system performance. Second, by coupling resource utilization efficiency with task latency analysis and propagating the impact of deviations along the dependency chain, the system can more accurately identify bottlenecks and anticipate risks, thereby making more accurate predictions and more proactive resource allocation in subsequent scheduling.

[0088] Specifically, the execution efficiency deviation index This refers to a scalar value calculated using this formula, which quantitatively characterizes the overall deviation of the execution efficiency of the examined task set from the ideal state within a specific observation period. This value is typically a real number, and its absolute value and positive / negative direction have clear scheduling guidance significance.

[0089] Specifically, the resource occupancy tensor modulus It is a scalar value, obtained by modulo calculation of the resource consumption tensor composed of multidimensional resources consumed by the task in the cloud environment, such as the number of CPU cores, memory capacity, disk IOPS, network bandwidth, etc. It comprehensively reflects the overall scale or intensity of the task's consumption of various resources.

[0090] Specifically, cumulative delay curvature factor It is a parameter derived from the sequence of task completion delay ratios. It describes the curvature characteristics of task delays, which are not simply linear accumulations, but may exhibit acceleration or deceleration trends, reflecting the urgency of delay deterioration.

[0091] Specifically, the quantized blocking threshold It is a theoretical blocking threshold value related to the granularity of underlying resource allocation in the cloud environment or the size of task scheduling time slices, used to standardize latency effects.

[0092] Specifically, compatible covariant factors It is a coordination parameter used to adjust the strength of the correlation between different resource types and latency, reflecting the coupling relationship between resources and performance in system architecture or task characteristics.

[0093] Specifically, entropy depends on propagation gain. It is a parameter related to the uncertainty or disorder of the distribution of dependency propagation gain values. From an information theory perspective, it characterizes the unpredictability or diffusion potential of task efficiency deviations propagating in the dependency graph.

[0094] Specifically, the delay scaling gradient It is a vector or scalar that describes the rate of change of the delay scale sequence over time or task-dependent order, i.e., whether the delay is aggravated or mitigated.

[0095] Specifically, phase transition indicator factor It is an indicative parameter used to sense whether the system load state is about to undergo a qualitative change, such as transitioning from a steady state to a congested state.

[0096] Specifically, critical resource manifold measure It is a geometric measure that measures the distance between the current system operating point and a certain theoretical performance critical boundary in an abstract resource-performance joint state space.

[0097] Specifically, the resource occupancy tensor is a mathematical structure used to abstractly represent the occupancy of a task with various heterogeneous resource types on a cloud platform.

[0098] Specifically, the delay ratio sequence is an ordered set that records a series of task completion delay ratio values.

[0099] Specifically, the dependency propagation gain value is a node influence coefficient used to adjust the edge weights in the dependency graph.

[0100] S3: Integrate the updated path weights with the topology of the dependency graph to obtain the priority execution sequence of the multi-tasks; The fusion and updating of the path weights and the topology of the dependency graph are used to obtain the priority execution sequence of the multi-tasks, including: The depth of the critical path in the dependency graph is parsed based on the updated path weights to obtain the source node depth identifier of the dependency graph. The source node depth identifier and the path weight are concatenated into a hierarchical weight matrix, and the weighted priority of the node is determined by the hierarchical weight matrix; Verify the topological connectivity of the weighted priority to obtain the priority execution sequence of the multi-tasks.

[0101] Specifically, the updated path weight refers to the new weight value carried by each directed edge in the dependency graph after iterative updates in the previous steps. The value indicates the importance of the dependency path in the current system state.

[0102] Specifically, the topology of a dependency graph refers to the connection method and directionality formed by all nodes and directed edges in the dependency graph.

[0103] Specifically, the priority execution sequence of multiple tasks specifies the order in which tasks are executed, taking into account the updated path weights while satisfying topological constraints.

[0104] Specifically, critical path depth refers to the weighted distance or number of levels traversed from the starting node of a dependency graph to a specific node in the graph, along the path with the highest cumulative path weight. It is used to identify the task chains in the graph that are most significantly affected by the weights.

[0105] Specifically, the source node depth identifier is an identifier value calculated and assigned to each task node in the dependency graph. This value accurately reflects the critical path depth of the node after considering the updated path weights.

[0106] Specifically, a hierarchical weight matrix is ​​a two-dimensional data structure that combines the source node depth identifier with the updated path weight according to specific rules, and is used to systematically organize the priority calculation elements of nodes.

[0107] Specifically, weighted priority refers to a comprehensive priority score calculated for each task node in the dependency graph by analyzing the hierarchical weight matrix.

[0108] Specifically, topological connectivity refers to whether there are reachable paths between nodes in a dependency graph, based on the direction of directed edges. In particular, it refers to whether the task order, initially sorted by weighted priority, still satisfies all the preceding and following dependency constraints defined by the topological structure of the dependency graph.

[0109] Furthermore, the system first loads the dependency graph containing the updated path weights. Then, starting with all nodes in the graph with an in-degree of 0, the system performs a graph traversal analysis. For each node in the graph, the system calculates all possible paths from all source nodes to that node. For each path, the system sums the updated path weights of all edges along that path to obtain the total weight of that path.

[0110] The system analyzes and identifies the path with the highest total weight among all paths leading to the node; this path is the critical path to that node. The total weight of the critical path can be converted into a depth in units of path edges, which is defined as the critical path depth of the node.

[0111] The system performs this calculation for each node in the graph and records and stores the calculated depth value as the source node depth identifier for that node. Essentially, this process maps dynamic path weight information to the global position coordinates of each node in the weighted view.

[0112] Furthermore, a matrix or matrix-like data structure is created, whose rows typically correspond to the nodes in the dependency graph. For each node, the source node depth identifier is used as the first data dimension, and the updated path weights of all incoming edges pointing to that node are used as the second and subsequent data dimensions, together filling the row. Each node is represented by a data vector containing depth information and association weight information, and the set of vectors for all nodes constitutes the hierarchical weight matrix.

[0113] Next, the weighted priority is determined by performing multi-dimensional comparisons of these data vectors in the matrix based on a built-in sorting rule. Through this multi-level comparison, the system calculates a unique, sortable weighted priority score or level for each node.

[0114] Further, a weighted priority list of all nodes is obtained. This preliminary priority list is traversed and checked against the original dependency graph. For each task in the list, the system checks whether all its predecessor dependent tasks have already appeared in the list sequence preceding that task. If a violation of this topological connectivity rule is found, the system adjusts the task's position in the sequence, moving it to the beginning after all its predecessor tasks have been arranged.

[0115] Ultimately, the final multi-task priority execution sequence is the ordered list of tasks that, after verification and adjustment, reflects both priority and logical correctness.

[0116] In summary, the process of parsing the critical path depth to obtain the source node depth identifier aggregates and transforms the dynamic, distributed weight information on the edges into static positional attributes on each node, establishing a unified, weight-based depth coordinate system for cross-node global priority comparison.

[0117] S4: Synchronously monitor the real-time resource utilization and task waiting queue in the cloud environment to obtain the resource load conflict mapping table of the multi-task. The synchronous monitoring of real-time resource occupancy and task waiting queues in the cloud environment to obtain a resource load conflict mapping table for the multi-task includes: Subscribe to the real-time consumption metrics of physical resource nodes in the cloud environment; The queue delay of the topology state corresponding to the task waiting queue is analyzed to obtain the delay sequence of the virtual resource allocation corresponding to the task waiting queue; The delay sequence and the real-time consumption index are coupled and analyzed to obtain the task packing density spectrum; Identify the conflict cores in the task stacking density spectrum to obtain a resource load conflict mapping table for the task stacking density spectrum.

[0118] Specifically, the task waiting queue refers to the sorted list of multiple tasks in the scheduling system that have been determined to be executed but cannot be temporarily assigned to physical resource nodes due to insufficient resources.

[0119] Specifically, the multi-task resource load conflict mapping table refers to a data structure or table that is the final output of this step. It clearly maps which physical resource nodes will become bottlenecks at some point in the future, and which multi-tasks will therefore compete for resources.

[0120] Specifically, a physical resource node refers to a physical hardware unit or its virtualization management unit that provides specific computing, storage, or networking capabilities in a cloud environment.

[0121] Specifically, real-time consumption metrics refer to the specific numerical data streams that are directly read from the monitoring system of physical resource nodes, reflecting the current consumption status of their various resources.

[0122] Specifically, topological state refers to the order of tasks in the task waiting queue and their corresponding state with the dependencies defined in the dependency graph.

[0123] Specifically, queue delay refers to the time a task has been waiting in the task waiting queue, or the estimated time it will need to wait.

[0124] Specifically, the sequence of virtual resource allocation latency refers to an ordered list in which each element quantifies the magnitude or expected latency of each task in the task waiting queue due to the inability to immediately satisfy its required virtual resources.

[0125] Specifically, coupling analysis refers to the analysis of two or more sets of data in order to discover their correlations and mutual influences.

[0126] Specifically, the task accumulation density spectrum refers to a multi-dimensional data distribution picture or model obtained through coupling analysis. It intuitively shows the severity of the accumulation of waiting tasks on different physical resource nodes or resource types and their spatial correspondence with the current resource consumption level.

[0127] Specifically, the core of the conflict refers to the focal area or resource entity identified in the task stacking density spectrum that represents a high concentration of resource demand and overlaps with the current high-resource-consuming area, and is most likely to cause systemic blockage.

[0128] Specifically, the resource load conflict mapping table refers to a list of specific conflict relationships extracted from the task stacking density spectrum by identifying the conflict core, and clearly recorded in tabular or list form. Its entries usually include information such as conflict resource identifiers, conflict task lists, and conflict intensity estimates.

[0129] Furthermore, a subscription request is sent to the monitoring service, declaring the list of target physical resource nodes that need to be continuously acquired and the types of resource metrics of interest. After the subscription is established, the monitoring service will proactively push real-time consumption metric data of each node to the monitoring module at a preset frequency.

[0130] The module continuously receives these data streams and categorizes and caches them by node and resource type, forming a dataset that scrolls over time.

[0131] Furthermore, the task waiting queue is examined. For each task in the queue, its topology state is first resolved, with the system focusing on tasks waiting due to insufficient resources. For these tasks, the system calculates their queue latency. Then, combining the task's resource requirement specifications, the abstract queue latency is transformed into a resource-related quantifiable value, namely the latency of virtual resource allocation.

[0132] Performing this calculation and transformation on all resource-waiting tasks in the queue, and organizing them by task order or resource type, yields a sequence of latency for virtual resource allocation.

[0133] Furthermore, supply-side and demand-side data are coupled and analyzed together. The analysis module establishes a coordinate system along the resource dimension. On each resource dimension, the module labels the real-time consumption indicators of each physical resource node as the current pressure.

[0134] Simultaneously, the resource requirements and latency of each task in the latency sequence are mapped to its target resource node, forming unmet demand pressure. The module then performs fusion calculation and visualization rendering on the same resource topology map, generating a task packing density spectrum.

[0135] Furthermore, the generated task stacking density spectrum is automatically diagnosed. The diagnostic algorithm scans the entire spectrum and identifies peak regions with density values ​​exceeding a preset threshold, which are the conflict cores. For each conflict core, the algorithm accurately extracts its associated physical resource nodes and lists all multitasks whose latency is highly correlated with that core.

[0136] The system then records detailed information about each conflict core, including resource identifier, conflict task list, conflict intensity, and predicted outbreak time, in a formatted entry. All such entries together form a structured and operable resource load conflict mapping table.

[0137] S5: Based on the resource load conflict mapping table, release the conflicting resource nodes occupied by the low-priority tasks in the multi-task process; The step of releasing conflicting resource nodes occupied by low-priority tasks in the multi-task scenario based on the resource load conflict mapping table includes: The resource load conflict mapping table and the priority execution sequence are used to filter low-priority tasks to obtain a release task filtering spectrum; The interruptible state of the release task screening spectrum and the task execution log is verified to obtain the task execution state probe sequence; A resource isolation buffer pool is constructed for the task execution status probe sequence to generate the resource isolation buffer pool; Perform conflict resource unbinding on the resource isolation buffer pool to obtain a set of unbinding operations; The set of unbinding operations is aggregated to obtain conflicting resource nodes.

[0138] Specifically, low-priority tasks refer to task instances that are ranked low in the priority execution sequence or are evaluated as relatively unimportant under the current resource occupancy situation.

[0139] Specifically, a conflicting resource node refers to a physical resource node or specific resource unit that is identified as a potential bottleneck in the resource load conflict mapping table.

[0140] Specifically, the release task screening spectrum refers to a visual or structured list of candidate tasks that are most suitable for release, generated by comparing and analyzing the resource load conflict mapping table with the priority execution sequence, and weighted by priority and conflict correlation.

[0141] Specifically, a task execution log refers to an information flow that records the history and real-time running status of a task.

[0142] Specifically, interruptible state verification is used to confirm whether a task is currently in a state that allows it to be safely released without causing data loss or logical errors.

[0143] Specifically, the task execution status probe sequence refers to an ordered sequence of explicit status information about whether a task is currently interruptible, obtained by conducting in-depth querying and analysis of task execution logs to select each candidate task in the task screening spectrum.

[0144] Specifically, a resource isolation buffer pool refers to a logically secure isolation area or context storage space created in the system before resources are unbound for tasks that are about to be released, in order to ensure the recoverability of task states and the atomicity of operations.

[0145] Specifically, conflict resource unbinding refers to a specific system call or instruction operation used to sever the allocation relationship between a task and the conflict resource node it occupies.

[0146] Specifically, the unbinding operation set refers to a set of instructions that records all conflicting resource unbinding operations to be executed.

[0147] Specifically, conflicting resource node aggregation refers to the process of merging and summarizing resource units released after the execution of the unbinding operation set, which come from different tasks but belong to the same physical resource node or the same type of resource.

[0148] Further, identify which tasks are currently consuming the node's resources. Compare this list of tasks consuming resources with the priority execution sequence. Identify those tasks that are both consuming conflicting resource nodes and are ranked low in the sequence.

[0149] Furthermore, after obtaining the release task screening spectrum, a security check is first performed. A deep, real-time query is initiated to the task execution log system. By analyzing the real-time and historical information returned by the log, the system verifies whether the task is interruptible at the current moment. The verification results of each candidate task are recorded, forming a task execution status probe sequence consisting of probe results corresponding to the screening spectrum order.

[0150] Furthermore, for tasks marked as safely interruptible in the task execution status probe sequence, the system will first construct a safe haven for them before actually releasing their resources. The system allocates an independent, protected storage area in memory or persistent storage for each such task.

[0151] Simultaneously, the scheduling attributes of the tasks are adjusted to mark them as being migrated or suspended, preventing other schedulers from performing conflicting operations on them during this period. The logical collection of context-saving regions created for all these tasks that are about to be operated on is called the resource isolation buffer pool.

[0152] Further, substantive resource reclamation is performed. The system iterates through every task entry in the buffer pool. For each task, the system sends an explicit control command to the manager of its physical resource node. This command instructs the manager to unbind the task instance from the specified conflicting resource node, i.e., unbind the conflicting resource. Each such unbinding command, along with its target task and resource identifier, is recorded as an atomic operation. The set of all these atomic operations constitutes a defined set of unbinding operations to be executed. At this point, the resource is logically marked as pending release, but physical reclamation may not yet be fully synchronized.

[0153] Furthermore, after the unbinding operation set is issued and confirmed to be executed, each record in the operation set is parsed to extract the identifier of the physical resource node that was successfully unbound, as well as the specific resource type and quantity that were released.

[0154] Then, the amount of all released resources belonging to the same physical resource node is summed up; the release of the same resource type on different nodes is summarized separately.

[0155] In summary, the above steps constitute a precise, safe, and controllable proactive resource recovery operation, aimed at resolving predicted resource conflicts and freeing up critical operating space for the system.

[0156] S6: Rebind the released conflicting resource nodes to the high-weight nodes among the nodes according to the priority execution sequence.

[0157] The step of rebinding the released conflicting resource nodes to the high-weight nodes among the nodes according to the priority execution sequence includes: The conflicting resource nodes are parsed using physical resource units to obtain a set of released resource unit mappings; The node weight hierarchy is filtered based on the weight sorting of the priority execution sequence to obtain high-weight nodes; A resource requirement affinity scan is performed on the topology of the high-weight nodes and the dependency graph to obtain the resource node topology affinity matrix; A dynamic binding queue is constructed by performing a dynamic binding queue on the released resource unit mapping set and the resource node topology affinity matrix to obtain a resource binding operation queue; The native resource mounting interface of the cloud environment is invoked to rebind nodes in the resource binding operation queue to obtain a weighted node binding result set.

[0158] Specifically, the released conflict resource nodes refer to the set of physical resource nodes or resource units that were originally part of the conflict hotspots and have become available after the previous step of unbinding.

[0159] Specifically, the priority execution sequence is an ordered list of tasks that determines the order in which tasks are scheduled.

[0160] Specifically, physical resource unit resolution refers to an analysis action used to break down a logically conflicting resource node into its internal, independently allocable specific resource components.

[0161] Specifically, node weight hierarchy filtering refers to the process of extracting the top-ranked task nodes from the priority execution sequence based on a preset weight threshold or hierarchy ratio.

[0162] Specifically, high-weight nodes refer to the set of key task nodes that are selected through a node weight hierarchy filtering operation and require priority access to resource replenishment.

[0163] Specifically, resource requirement affinity scanning is a matching analysis process designed to assess the performance, latency, and architectural suitability of the resource requirement specifications of high-weight nodes with their potential, available release resource units, taking into account the position of tasks in the topology.

[0164] Specifically, the resource node topology affinity matrix is ​​a data structure generated after resource demand affinity scanning. Its rows and columns represent high-weight nodes and available release resource units, respectively. Each element value in the matrix represents the affinity score between the node and the resource unit. The higher the score, the better the match.

[0165] Specifically, dynamic binding queue construction refers to a planning process that determines an optimal binding target node for each resource unit to be allocated based on the scoring results of the resource node topology affinity matrix and the real-time status of the current system, and organizes the resource-node allocation decisions into an executable instruction queue in sequence.

[0166] Specifically, the resource binding operation queue is an ordered list in which each item explicitly specifies which specific resource release unit will be bound to which specific high-weight node.

[0167] Specifically, the native resource mounting interface of a cloud environment refers to the standard API or system call interface provided by the underlying cloud computing platform for actually allocating physical resources to virtual machines or containers.

[0168] Specifically, node rebinding refers to calling the aforementioned native interface to actually perform the resource mounting operation.

[0169] Specifically, the weighted node binding result set refers to a report generated by the system after all node rebinding operations have been completed, which lists which new resource units each high-weight node has successfully bound to.

[0170] Further, obtain the list of conflicting resource nodes obtained from the previous step. Then, for each node in the list, query its detailed resource directory. Determine its starting physical address or corresponding NUMA node information. Parse this information from the aggregated macro-description into individual, independently schedulable and bindable minimum resource units.

[0171] Finally, all the parsed resource unit information is organized and registered in a unified format to form a detailed, itemized list, which is the release of the resource unit mapping set.

[0172] Furthermore, the priority execution sequence is loaded. The node weight hierarchy filtering operation involves extracting the beginning of this ordered sequence based on a dynamic or static rule. Starting from the head of the sequence and scanning downwards, all task nodes that meet the rule's conditions are marked. These constitute the target group for this resource reallocation—high-weight nodes.

[0173] Further, the system obtains a list of high-weight nodes and a set of resource release unit mappings. Then, it initiates a resource requirement affinity scan. For each high-weight node, its resource requirement specifications are obtained. Simultaneously, the system analyzes the node's position in the dependency graph's topology and evaluates the characteristics of each resource release unit. The scanning algorithm calculates an affinity score for each pair, resulting in a resource node topology affinity matrix.

[0174] Furthermore, the dynamic binding queue construction algorithm uses the resource node topological affinity matrix as its core input, while also considering some dynamic constraints, such as the same task not being able to bind to two mutually exclusive resources simultaneously. The algorithm traverses the available resource units, selecting the high-weight node with the highest affinity score for each resource unit that has not yet met all its resource requirements, as a binding pair.

[0175] These instructions are sorted according to a certain logic, and finally an ordered, serializable, and executable resource binding operation queue is generated.

[0176] Furthermore, the engine invokes the cloud environment's native resource mounting interface. Following the queue order, the engine calls these underlying interfaces one by one, actually mounting the specified resource unit to the runtime instance corresponding to the target high-weight node. The operation results are recorded. Once all instructions in the queue have been processed, the engine summarizes all operation results to generate a weighted node binding result set.

[0177] like Figure 2 The diagram shown is a functional block diagram of a cloud computing-based resource scheduling system provided in an embodiment of the present invention.

[0178] The cloud computing-based resource scheduling system 100 described in this invention can be installed in an electronic device. Depending on the functions implemented, the cloud computing-based resource scheduling system 100 may include a dependency graph construction module 101, a weight dynamic update module 102, a task sequence optimization module 103, a conflict monitoring and analysis module 104, a resource release scheduling module 105, and a resource rebinding module 106. The modules described in this invention can also be referred to as units, which are a series of computer program segments that can be executed by the processor of an electronic device and can perform a fixed function, stored in the memory of the electronic device.

[0179] In this embodiment, the functions of each module / unit are as follows: Dependency graph construction module 101 is used to obtain the dependency graph of multiple tasks in the cloud environment; The weight dynamic update module 102 is used to capture feedback data of the completion status of the multi-task in real time, and iteratively update the path weight of the node in the dependency graph in combination with the feedback data. The task sequence optimization module 103 is used to fuse the updated path weights with the topology of the dependency graph to obtain the priority execution sequence of the multi-tasks. The conflict monitoring and analysis module 104 is used to synchronously monitor the real-time resource occupancy rate and task waiting queue in the cloud environment to obtain the resource load conflict mapping table of the multi-task. Resource release scheduling module 105 is used to release conflicting resource nodes occupied by low-priority tasks in the multi-task based on the resource load conflict mapping table; Resource rebinding module 106 is used to rebind the released conflicting resource nodes to the high-weight nodes among the nodes according to the priority execution sequence.

[0180] In the several embodiments provided by this invention, it should be understood that the disclosed methods and systems can be implemented in other ways. For example, the system embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and other division methods may be used in actual implementation.

[0181] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0182] Furthermore, the functional modules in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in the form of hardware plus software functional modules.

[0183] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the present invention can be implemented in other specific forms without departing from the spirit or essential characteristics of the present invention.

[0184] The embodiments of this application can acquire and process relevant data based on artificial intelligence technology. Artificial intelligence is the theory, method, technology, and application system that uses digital computers or machines controlled by digital computers to simulate, extend, and expand human intelligence, perceive the environment, acquire knowledge, and use that knowledge to obtain optimal results.

[0185] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention.

Claims

1. A resource scheduling method based on cloud computing, characterized in that, The method includes: S1: Obtain the dependency graph of multiple tasks in the cloud environment; S2: Real-time capture of feedback data on the completion status of the multi-task, and iteratively update the path weights of the nodes in the dependency graph based on the feedback data; S3: Integrate the updated path weights with the topology of the dependency graph to obtain the priority execution sequence of the multi-tasks; S4: Synchronously monitor the real-time resource utilization and task waiting queue in the cloud environment to obtain the resource load conflict mapping table of the multi-task. S5: Based on the resource load conflict mapping table, release the conflicting resource nodes occupied by the low-priority tasks in the multi-task process; S6: Rebind the released conflicting resource nodes to the high-weight nodes among the nodes according to the priority execution sequence.

2. The resource scheduling method based on cloud computing as described in claim 1, characterized in that, The process of obtaining the dependency graph of multiple tasks in the cloud environment includes: Collect a list of interoperability relationships between multiple tasks in the cloud environment, and determine the dependency framework of the relationship list; The dependency graph of the multi-task is drawn using the aforementioned dependency framework.

3. The resource scheduling method based on cloud computing as described in claim 1, characterized in that, The real-time capture of feedback data corresponding to the completion status of the multi-task includes: Subscribe to the task execution logs of multiple tasks in the cloud environment, and compile the key fields in the task execution logs into process status codes; The resource usage statistics corresponding to the multitasking are determined by combining the process status codes. The process status code and the resource usage statistics are encapsulated into the feedback data of the multi-task.

4. The resource scheduling method based on cloud computing as described in claim 3, characterized in that, The iterative update of the path weights of nodes in the dependency graph based on the feedback data includes: Based on the feedback data, determine the sequence of delay ratios for the completion of the corresponding tasks in the multi-task scenario; The resource usage statistics and the latency ratio sequence are coupled by an execution efficiency deviation to obtain the execution efficiency deviation index of the latency ratio sequence; The dependency propagation gain value of the nodes in the dependency graph is determined by combining the execution efficiency deviation index; The dependency propagation gain value and the current path weight of the dependency graph are dynamically superimposed to obtain the updated path weight.

5. A resource scheduling method based on cloud computing as described in claim 1, characterized in that, The fusion and updating of the path weights and the topology of the dependency graph are used to obtain the priority execution sequence of the multi-tasks, including: The depth of the critical path in the dependency graph is parsed based on the updated path weights to obtain the source node depth identifier of the dependency graph. The source node depth identifier and the path weight are concatenated into a hierarchical weight matrix, and the weighted priority of the node is determined by the hierarchical weight matrix. Verify the topological connectivity of the weighted priority to obtain the priority execution sequence of the multi-tasks.

6. A resource scheduling method based on cloud computing as described in claim 5, characterized in that, The synchronous monitoring of real-time resource occupancy and task waiting queues in the cloud environment to obtain a resource load conflict mapping table for the multi-task includes: Subscribe to the real-time consumption metrics of physical resource nodes in the cloud environment; The queue delay of the topology state corresponding to the task waiting queue is analyzed to obtain the delay sequence of the virtual resource allocation corresponding to the task waiting queue; The delay sequence and the real-time consumption index are coupled and analyzed to obtain the task packing density spectrum; Identify the conflict cores in the task stacking density spectrum to obtain a resource load conflict mapping table for the task stacking density spectrum.

7. A resource scheduling method based on cloud computing as described in claim 3, characterized in that, The step of releasing conflicting resource nodes occupied by low-priority tasks in the multi-task scenario based on the resource load conflict mapping table includes: The resource load conflict mapping table and the priority execution sequence are used to filter low-priority tasks to obtain a release task filtering spectrum; The interruptible state of the release task screening spectrum and the task execution log is verified to obtain the task execution state probe sequence; A resource isolation buffer pool is constructed for the task execution status probe sequence to generate the resource isolation buffer pool; Perform conflict resource unbinding on the resource isolation buffer pool to obtain a set of unbinding operations; The set of unbinding operations is aggregated to obtain conflicting resource nodes.

8. A resource scheduling method based on cloud computing as described in claim 7, characterized in that, The step of rebinding the released conflicting resource nodes to the high-weight nodes among the nodes according to the priority execution sequence includes: The conflicting resource nodes are parsed using physical resource units to obtain a set of released resource unit mappings; The node weight hierarchy is filtered based on the weight sorting of the priority execution sequence to obtain high-weight nodes; A resource requirement affinity scan is performed on the topology of the high-weight nodes and the dependency graph to obtain the resource node topology affinity matrix; A dynamic binding queue is constructed by performing a dynamic binding queue on the released resource unit mapping set and the resource node topology affinity matrix to obtain a resource binding operation queue; The native resource mounting interface of the cloud environment is invoked to rebind nodes in the resource binding operation queue to obtain a weighted node binding result set.

9. A resource scheduling method based on cloud computing as described in claim 4, characterized in that, The formula for calculating the execution efficiency deviation index is as follows: in: The execution efficiency deviation index. For the resource occupancy tensor modulus, For cumulative delay curvature factor, To quantize the blocking threshold, To accommodate covariance factors, Entropy that depends on propagation gain Delay ratio gradient, As a phase transition indicator, It is a measure of critical resource manifold.

10. A cloud computing-based resource scheduling system, used to implement the cloud computing-based resource scheduling method according to any one of claims 1-9, characterized in that, The system includes: Dependency graph building module, used to obtain the dependency graph of multiple tasks in a cloud environment; The weight dynamic update module is used to capture feedback data on the completion status of the multi-task in real time, and to iteratively update the path weights of the nodes in the dependency graph in combination with the feedback data. The task sequence optimization module is used to fuse the updated path weights with the topology of the dependency graph to obtain the priority execution sequence of the multi-tasks; The conflict monitoring and analysis module is used to synchronously monitor the real-time resource occupancy and task waiting queue in the cloud environment to obtain the resource load conflict mapping table of the multi-task. The resource release scheduling module is used to release conflicting resource nodes occupied by low-priority tasks in the multi-task based on the resource load conflict mapping table. The resource rebinding module is used to rebind released conflicting resource nodes to high-weight nodes among the nodes according to the priority execution sequence.

Images