A dynamic scheduling method and system for enterprise internal cross-domain resources

Abstract

The application relates to a kind of dynamic scheduling method and system for enterprise internal cross-domain resources, the method comprises: S1.task multidimensional feature vectorization and dynamic scoring mechanism, when the system receives cross-domain resource request, multidimensional state variable is extracted from request, and dynamic priority score is calculated by weighting evaluation model;S2. cross-domain resource negotiation and allocation based on state machine, scheduling engine is sorted according to the DPS score calculated, and cross-domain resource negotiation and allocation are completed through resource state machine. The application not only avoids the logical contradiction that "scheduling priority is high, but conflict resolution is random task selection, and priority is not considered in fault recovery", but also solves the unique technical problem in the field of resource scheduling that "multiple tasks compete for the same optimal replacement node".

Description

Technical Field

[0001] This invention relates to the field of resource optimization and scheduling technology, and in particular to a dynamic scheduling method and system for cross-domain resources within an enterprise. Background Technology

[0002] One existing technology is a static resource scheduling system based on a FIFO (First-In, First-Out) queue. This system maintains a global task waiting queue, and all cross-domain resource requests are queued in the order of their submission time. The scheduler sequentially retrieves tasks from the head of the queue and checks whether all required resources are available: if available, resources are allocated and the task is executed; if unavailable, the task is blocked at the head of the queue until the required resources are released before subsequent tasks can be scheduled.

[0003] Specifically, the scheduling process of this scheme is as follows: (1) Receive task requests and generate timestamps; (2) Insert tasks into the waiting queue in the order of timestamps; (3) Take out the first task from the head of the queue and check whether all dependent resources are available; (4) If all are available, allocate resources and mark the task as being executed; (5) If there are unavailable resources, wait and block all subsequent tasks; (6) Release resources after the task is completed and return to step (3).

[0004] However, the existing technology has the following technical defects: (1) Head-of-line blocking causes a sharp drop in system throughput. When the resources required by the task at the head of the queue are temporarily unavailable, all subsequent tasks in the entire queue are blocked. Even if the resources required by the subsequent tasks are all available and the urgency is higher, they cannot be scheduled for execution. This phenomenon of "one task blocking the whole" is particularly serious in enterprise-level cross-domain scenarios - cross-domain tasks involve many types of resources and have large availability fluctuations, and the probability of head-of-line blocking is significantly higher than in single-domain scenarios.

[0005] (2) Lack of priority perception. The FIFO mechanism uses only time as the sole scheduling criterion and cannot perceive the urgency and business value of tasks. In scenarios such as autonomous driving R&D, high-priority verification tasks with only a few days left before the mass production node may be blocked for a long time by low-priority experimental tasks that are on a first-come, first-served basis, resulting in the delay of key milestones.

[0006] (3) No deadlock detection and prevention mechanism. When multiple cross-domain tasks form a circular resource dependency (task A holds resource R1 and requests R2, task B holds R2 and requests R1), the FIFO system cannot automatically detect and break the deadlock. It can only rely on manual discovery and intervention, and the recovery cycle is usually measured in hours.

[0007] Existing technology two is a resource scheduling system based on fixed priorities. This system assigns a fixed priority label (e.g., P0 / P1 / P2 / P3) to each type of task, and the scheduler scans the task queue in descending order of priority. Within the same priority level, a FIFO (First-In, First-Out) strategy is still used. When a high-priority task requests a resource, the system can preempt resources already occupied by a low-priority task—the preempted task is suspended and re-queued.

[0008] Specifically, the scheduling process of this scheme is as follows: (1) Receive task requests and read the preset priority tags; (2) Insert the task into the tail of the sub-queue of the corresponding priority; (3) The scheduler starts scanning from the highest priority sub-queue; (4) If the high priority queue is not empty, take out the task at the head of the queue and check the resource availability; (5) If the resource is occupied by a low priority task, trigger preemption, suspend the low priority task and release the resource; (6) Allocate the resource to the high priority task for execution.

[0009] Although the prior art 2 introduces a priority mechanism, it still has the following technical shortcomings: (1) Fixed priorities lack dynamic adaptability. The priority labels of tasks are statically set when they are created and remain unchanged throughout their lifecycle. However, in real-world scenarios, the urgency of a task changes over time—for example, the closer to the deadline, the higher the urgency of the task; and the historical SLA achievement rate is also dynamically updated according to the task execution status. Fixed priorities cannot reflect this time-varying nature, leading to a disconnect between scheduling decisions and actual business needs.

[0010] (2) Preemption has high overhead and is prone to "priority inversion". When a high-priority task frequently preempts a low-priority task, the preempted task may be repeatedly suspended and resumed, resulting in a large amount of context switching overhead. More seriously, when a low-priority task holds the critical resources required by a high-priority task, the system has to wait for the low-priority task to release the resources, forming a de facto priority inversion.

[0011] (3) Fault recovery relies on manual intervention and lacks automatic reordering capabilities. When a resource node experiences a sudden failure (such as server crash or approval personnel taking leave), the existing system mostly relies on manual fault detection, manual task reallocation, or a simple timeout retry mechanism. It is impossible to automatically calculate alternative paths and trigger cascading reordering within milliseconds, resulting in a sharp drop in the overall system throughput, and the recovery cycle is usually measured in minutes or even hours.

[0012] (4) Lack of global perspective in negotiation and bargaining. Fixed priority schedulers only focus on the priority comparison of individual tasks and lack the ability to model cross-domain resource dependencies globally. When multiple high-priority tasks concurrently request cross-departmental resources, they cannot negotiate and allocate resources from the perspective of overall system optimization, which can easily lead to key resources being occupied by low-value tasks for a long time, causing high-priority tasks to be blocked. Summary of the Invention

[0013] In view of the shortcomings of the prior art, the present invention provides a dynamic scheduling method and system for cross-domain resources within an enterprise. It not only avoids the logical contradiction of "scheduling with high priority, but randomly selecting tasks for conflict resolution and not considering priority for fault recovery", but also solves the unique technical problem in the field of resource scheduling of "multiple tasks competing for the same optimal alternative node".

[0014] To achieve the above and other related objectives, the present invention provides the following technical solution: A dynamic scheduling method for cross-domain resources within an enterprise, the method comprising: S1. Task multidimensional feature vectorization and dynamic scoring mechanism: When the system receives a cross-domain resource request, it extracts multidimensional state variables from the request and calculates the dynamic priority score through a weighted evaluation model. S2. Cross-domain resource negotiation and allocation based on state machine: The scheduling engine sorts concurrent requests according to the calculated DPS score and completes cross-domain resource negotiation and allocation through the resource state machine. S3. Adaptive Rearrangement Algorithm Triggered by Node Anomalies: The system monitors the health status of each resource node in real time through a heartbeat mechanism. When a node failure or response timeout is detected, the adaptive rearrangement process is immediately triggered.

[0015] Further, in step S1, the calculation of the dynamic priority score using the weighted evaluation model includes: S11. Feature extraction: The system extracts the following four feature variables from each cross-domain resource request: task urgency U(t), cross-domain dependency amplification factor Ω(t), business strategic value V(t), historical SLA achievement rate S(t), and resource consumption estimate R(t). S12. Weighted evaluation model: The system calculates the dynamic priority score using the following weighted formula. DPS(t)=α(t)·(U(t)×Ω(t))+β(t)·V(t)+γ(t)·S(t)+δ(t)·(1-R(t)), Where α(t), β(t), γ(t), and δ(t) are dynamic weighting coefficients, satisfying α+β+γ+δ=1, and each value is [0, 1]. S13. Dynamic update mechanism: The DPS score is not calculated all at once, but is dynamically refreshed at fixed intervals. Each time it is refreshed, U(t), S(t), and R(t) are extracted again and the DPS is recalculated. This ensures that the scheduling decision is always based on the latest task status.

[0016] Further, in step S11, the task urgency U(t) is, U(t) = max(0, 1 - (T) deadline -t now ) / T estimated ), Among them, T deadline t is the task deadline. now T represents the current time. estimated The estimated execution time for the task is as follows: when U(t)=0, it means that the task has ample time; when U(t)→1, it means that the task is about to exceed the deadline and has the highest urgency.

[0017] Further, in step S11, the cross-domain dependent amplification factor Ω(t) is, Ω(t) = 1 + κ·(N) domain -1), Where, N domain The number of cross-domain resource domains required for the task, κ is the amplification factor, defaulting to 0.15; The business strategic value V(t) reflects the contribution of the task to the company's strategic goals. It is a preset score in the range of [0, 1] and is automatically labeled by the business system according to the project level to which the task belongs: mass production level = 0.9, pre-research level = 0.5, and experimental level = 0.2. V(t) does not change over time during the task's life cycle, but different tasks at the same project level can be fine-tuned according to the criticality of their respective sub-modules.

[0018] Further, in step S11, the historical SLA achievement rate S(t) reflects the historical on-time completion rate of this type of task, and takes a value of [0, 1], with a base value S0(t) = N. success / N total , where N success N represents the number of times a historical task has been completed on time. total Given the total number of executions in history, the initial value of the new task is S0(t) = 0.5. To avoid bias caused by outdated historical data, a time decay factor is introduced: S(t) = S0(t)·e (-μ·Δt) Where Δt is the time difference between the most recent SLA record and the current time, and μ is the attenuation coefficient, which makes the weight of recent SLA records higher than that of distant records; the estimated resource consumption R(t) reflects the estimated resource scale occupied by the task, and takes a normalized value of [0,1], R(t=Resource estimate / Resourcemax Among them, Resource estimate To estimate resource consumption for the task, Resource max The smaller R(t) is, the more "lightweight" the task is, and the easier it is to be scheduled quickly.

[0019] Furthermore, the dynamic weighting coefficients α(t), β(t), γ(t), and δ(t) do not employ discrete, step-by-step switching, but are adjusted by continuous linear interpolation based on the system load rate L(t), according to the following specific rules: Define the baseline load factor L ref =65%, the formula for calculating the weighting coefficient is: α(t)=α base +k α ·(L(t)-L ref ) / L ref , δ(t)=δ base -k δ ·(L(t)-L ref ) / L ref , Where, α base =0.3,δ base =0.2, which is the baseline weight value; k α = 0.1, k δ =0.1 is the sensitivity adjustment coefficient; β(t) and γ(t) are finely adjusted from 0.3 and 0.2 to 0.25 and 0.25 respectively under high load; when L(t) > L ref When α(t) increases and δ(t) decreases, the system prioritizes urgency and SLA assurance; when L(t) < L ref When α(t) decreases and δ(t) increases, the system focuses on resource utilization. The continuous adjustment of the weight coefficients avoids sudden jitter during discrete tier switching, ensuring a smooth transition of scheduling decisions. To prevent weight imbalance under extreme loads, boundary constraints are set for α(t)∈[0.15, 0.5], β(t)∈[0.2, 0.35], γ(t)∈[0.15, 0.35], and δ(t)∈[0.05, 0.35].

[0020] Further, in step S2, the process of completing cross-domain resource negotiation and allocation through the resource state machine includes: S21. Resource node state machine modeling: The system abstracts the resource pools of each functional department into independent state nodes; S22. DPS sorting and resource negotiation: The scheduling engine sorts all pending cross-domain resource requests from high to low according to their DPS scores, forming a priority queue. S23. Resource Dependency Directed Graph Construction and Circular Dependency Detection: For cross-domain tasks with resource dependencies, the system constructs a resource dependency directed graph. Nodes in the RDG represent resource allocation relationships, and directed edges represent resource request relationships. S24. DPS-driven degradation strategy: When a circular dependency is detected, the system automatically triggers the following degradation strategy. The selection order and execution objects of the degradation strategy are based on the DPS score, rather than random selection or simple time ordering.

[0021] Furthermore, the DPS-driven degradation strategy includes: Task splitting involves breaking down nodes with large circular dependencies into multiple subtasks, releasing some occupied resources, and breaking the circular dependency. The splitting granularity is determined by the task's segmentability. During splitting, the subtask segment with the highest DPS score is prioritized for continued execution, while the subtask segment with low DPS is temporarily suspended. Low DPS tasks are suspended. In the deadlock loop, the task with the lowest DPS score is selected, suspended, and its resources are released. The suspended task enters the waiting queue and is rescheduled after the resource conflict is resolved. The sacrifice target is determined by DPS rather than time order or randomness, ensuring that high-value tasks are always prioritized. Resource degradation is used. If there is a backup node in the DEGRADED state in the deadlock loop, the task with the lowest DPS score is migrated from the OCCUPIED node to the DEGRADED node to break the deadlock at the cost of performance degradation.

[0022] Further, in step S3, the adaptive rearrangement algorithm triggered by node anomalies includes: S31. Heartbeat monitoring mechanism: Each resource node sends a heartbeat signal to the scheduling engine at a fixed period. The heartbeat signal includes the node ID, current status, load rate, and available capacity. The scheduling engine maintains a heartbeat time window. If no heartbeat is received from a node for 3 consecutive periods, the node is determined to be in the FAILED state and reordering is triggered immediately. S32. Snapshot retention: When a node is determined to be FAILED, the system immediately extracts the context state vectors of all tasks currently being executed on that node; S33.DPS weighted heuristic search: The system is based on an improved A* search algorithm, which calculates alternative execution paths among the remaining available nodes. The evaluation function of the A* algorithm is defined as follows: f(n) = g(n) + h(n), Where g(n) is the actual migration cost from the starting node to the candidate node n, including the data transmission cost C. transfer (n), State reconstruction cost C rebuild (n) Resource switching cost C switch , g(n) = C transfer (n)+C rebuild (n)+C switch ; h(n) is a heuristic function that estimates the remaining cost from candidate node n to task completion, defined as: h(n) = T remaining (n)×(1 / DPS)×λ load (n), Among them, T remaining (n) represents the estimated remaining execution time on the candidate node, DPS is the dynamic priority score of the task, and λ load (n) is the load penalty factor for candidate nodes.

[0023] To achieve the above and other related objectives, the present invention also provides a dynamic scheduling system for cross-domain resources within an enterprise, used to implement the aforementioned dynamic scheduling method for cross-domain resources within an enterprise, the system comprising: The task feature extraction and scoring module is used to extract multidimensional state variables from the request and calculate dynamic priority scores through a weighted evaluation model. The state machine resource negotiation module, connected to the task feature extraction and scoring module, is used to calculate the obtained DPS score, sort concurrent requests, and complete cross-domain resource negotiation and allocation through the resource state machine. The DPS-driven conflict degradation module is connected to the state machine resource negotiation module and is used to automatically trigger the degradation strategy based on the DPS score. The adaptive reordering module, connected to the conflict degradation module of the DPS driver, is used to monitor the health status of each resource node in real time through a heartbeat mechanism. When a node failure or response timeout is detected, the adaptive reordering process is immediately triggered.

[0024] The present invention has the following positive effects: 1. The core of this invention is not any single technical step, but rather that the DPS score is specifically integrated across four stages: calculating output in the feature extraction stage → driving priority queue sorting in the resource negotiation stage → driving the "who is sacrificed" degradation decision in the conflict degradation stage → driving the "who recovers first" search weight in the A* fault recovery stage → and refreshing DPS by feeding back the recovery results. This specific integration ensures that the decision-making logic of each stage remains consistent (high DPS tasks are prioritized in sorting, conflict, and fault scenarios), avoiding the logical contradiction of "scheduling prioritizing high-priority tasks, but randomly selecting tasks for conflict resolution and not considering priority in fault recovery."

[0025] 2. This invention extracts feature variables from four dimensions: task urgency U(t), business strategic value V(t), historical SLA achievement rate S(t), and estimated resource consumption R(t). It introduces a cross-domain dependency amplification factor Ω(t) and an SLA time decay factor, and calculates DPS(t) using dynamic weighting coefficients that are continuously and linearly interpolated based on the system load rate L(t). Continuous adjustment of the weighting coefficients (rather than discrete tier switching) avoids abrupt fluctuations in scheduling decisions.

[0026] 3. This invention abstracts the resource pool into state machine nodes with five states (AVAILABLE, RESERVED, OCCUPIED, DEGRADED, FAILED), and performs resource negotiation after sorting according to DPS scores. When a circular dependency is detected, the execution target and order of the degradation strategy are entirely driven by the DPS score: the task with the lowest DPS is suspended or migrated to the degradation node, ensuring that the task with the highest DPS continues to execute. Attached Figure Description

[0027] Figure 1 This is a schematic diagram of the method flow of the present invention; Figure 2 The flowchart of the Dynamic Priority Scoring (DPS) mechanism of this invention is shown below; Figure 3 This is the state machine transition diagram for the resource node of the present invention; Figure 4 This is a flowchart of the cross-domain resource negotiation and deadlock detection process of the present invention; Figure 5 This is a flowchart of the adaptive reordering algorithm of the present invention; Figure 6 This is a schematic diagram of the system framework of the present invention. Detailed Implementation

[0028] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0029] Example: Figure 1 As shown, a dynamic scheduling method for cross-domain resources within an enterprise is described, the method comprising: S1. Task multidimensional feature vectorization and dynamic scoring mechanism: When the system receives a cross-domain resource request, it extracts multidimensional state variables from the request and calculates the dynamic priority score through a weighted evaluation model. S2. Cross-domain resource negotiation and allocation based on state machine: The scheduling engine sorts concurrent requests according to the calculated DPS score and completes cross-domain resource negotiation and allocation through the resource state machine. S3. Adaptive Rearrangement Algorithm Triggered by Node Anomalies: The system monitors the health status of each resource node in real time through a heartbeat mechanism. When a node failure or response timeout is detected, the adaptive rearrangement process is immediately triggered.

[0030] In this embodiment, as Figure 2 As shown, in step S1, calculating the dynamic priority score using the weighted evaluation model includes: S11. Feature extraction: The system extracts the following four feature variables from each cross-domain resource request: task urgency U(t), cross-domain dependency amplification factor Ω(t), business strategic value V(t), historical SLA achievement rate S(t), and resource consumption estimate R(t). S12. Weighted evaluation model: The system calculates the dynamic priority score using the following weighted formula. DPS(t)=α(t)·(U(t)×Ω(t))+β(t)·V(t)+γ(t)·S(t)+δ(t)·(1-R(t)), Where α(t), β(t), γ(t), and δ(t) are dynamic weighting coefficients, satisfying α+β+γ+δ=1, and each value is [0, 1]. S13. Dynamic update mechanism: The DPS score is not calculated all at once, but is dynamically refreshed at fixed intervals. Each time it is refreshed, U(t), S(t), and R(t) are extracted again and the DPS is recalculated. This ensures that the scheduling decision is always based on the latest task status.

[0031] In this embodiment, in step S11, the task urgency U(t) is, U(t) = max(0, 1 - (T) deadline -t now ) / T estimated ), Among them, T deadline t is the task deadline. now T represents the current time. estimated The estimated execution time for the task is as follows: when U(t)=0, it means that the task has ample time; when U(t)→1, it means that the task is about to exceed the deadline and has the highest urgency.

[0032] In this embodiment, in step S11, the cross-domain dependent amplification factor Ω(t) is, Ω(t) = 1 + κ·(N) domain -1), Where, N domainThe number of cross-domain resource domains required for the task, κ is the amplification factor, defaulting to 0.15; The business strategic value V(t) reflects the contribution of the task to the company's strategic goals. It is a preset score in the range of [0, 1] and is automatically labeled by the business system according to the project level to which the task belongs: mass production level = 0.9, pre-research level = 0.5, and experimental level = 0.2. V(t) does not change over time during the task's life cycle, but different tasks at the same project level can be fine-tuned according to the criticality of their respective sub-modules.

[0033] In this embodiment, in step S11, the historical SLA achievement rate S(t) reflects the historical on-time completion rate of this type of task, and takes a value of [0, 1], with a base value S0(t) = N. success / N total , where N success N represents the number of times a historical task has been completed on time. total Given the total number of executions in history, the initial value of the new task is S0(t) = 0.5. To avoid bias caused by outdated historical data, a time decay factor is introduced: S(t) = S0(t)·e (-μ·Δt) Where Δt is the time difference between the most recent SLA record and the current time, and μ is the attenuation coefficient, which makes the weight of recent SLA records higher than that of distant records; the estimated resource consumption R(t) reflects the estimated resource scale occupied by the task, and takes a normalized value of [0,1], R(t=Resource estimate / Resource max Among them, Resource estimate To estimate resource consumption for the task, Resource max The smaller R(t) is, the more "lightweight" the task is, and the easier it is to be scheduled quickly.

[0034] In this embodiment, the dynamic weighting coefficients α(t), β(t), γ(t), and δ(t) are not switched discretely, but are adjusted by continuous linear interpolation based on the system load rate L(t). The specific rules are as follows: Define the baseline load factor L ref =65%, the formula for calculating the weighting coefficient is: α(t)=α base +k α ·(L(t)-L ref ) / L ref , δ(t)=δ base -k δ ·(L(t)-L ref ) / L ref , Where, α base =0.3,δbase =0.2, which is the baseline weight value; k α = 0.1, k δ =0.1 is the sensitivity adjustment coefficient; β(t) and γ(t) are finely adjusted from 0.3 and 0.2 to 0.25 and 0.25 respectively under high load; when L(t) > L ref When α(t) increases and δ(t) decreases, the system prioritizes urgency and SLA assurance; when L(t) < L ref When α(t) decreases and δ(t) increases, the system focuses on resource utilization. The continuous adjustment of the weight coefficients avoids sudden jitter during discrete tier switching, ensuring a smooth transition of scheduling decisions. To prevent weight imbalance under extreme loads, boundary constraints are set for α(t)∈[0.15, 0.5], β(t)∈[0.2, 0.35], γ(t)∈[0.15, 0.35], and δ(t)∈[0.05, 0.35].

[0035] In this embodiment, as Figure 3 or Figure 4 As shown, in step S2, the process of completing cross-domain resource negotiation and allocation through the resource state machine includes: S21. Resource node state machine modeling: The system abstracts the resource pools of each functional department into independent state nodes; S22. DPS sorting and resource negotiation: The scheduling engine sorts all pending cross-domain resource requests from high to low according to their DPS scores, forming a priority queue. S23. Resource Dependency Directed Graph Construction and Circular Dependency Detection: For cross-domain tasks with resource dependencies, the system constructs a resource dependency directed graph. Nodes in the RDG represent resource allocation relationships, and directed edges represent resource request relationships. S24. DPS-driven degradation strategy: When a circular dependency is detected, the system automatically triggers the following degradation strategy. The selection order and execution objects of the degradation strategy are based on the DPS score, rather than random selection or simple time ordering.

[0036] In this embodiment, the degradation strategy driven by DPS includes: Task splitting involves breaking down nodes with large circular dependencies into multiple subtasks, releasing some occupied resources, and breaking the circular dependency. The splitting granularity is determined by the task's segmentability. During splitting, the subtask segment with the highest DPS score is prioritized for continued execution, while the subtask segment with low DPS is temporarily suspended. Low DPS tasks are suspended. In the deadlock loop, the task with the lowest DPS score is selected, suspended, and its resources are released. The suspended task enters the waiting queue and is rescheduled after the resource conflict is resolved. The sacrifice target is determined by DPS rather than time order or randomness, ensuring that high-value tasks are always prioritized. Resource degradation is used. If there is a backup node in the DEGRADED state in the deadlock loop, the task with the lowest DPS score is migrated from the OCCUPIED node to the DEGRADED node to break the deadlock at the cost of performance degradation.

[0037] In this embodiment, as Figure 5 As shown, in step S3, the adaptive reordering algorithm triggered by node anomalies includes: S31. Heartbeat monitoring mechanism: Each resource node sends a heartbeat signal to the scheduling engine at a fixed period. The heartbeat signal includes the node ID, current status, load rate, and available capacity. The scheduling engine maintains a heartbeat time window. If no heartbeat is received from a node for 3 consecutive periods, the node is determined to be in the FAILED state and reordering is triggered immediately. S32. Snapshot retention: When a node is determined to be FAILED, the system immediately extracts the context state vectors of all tasks currently being executed on that node; S33.DPS weighted heuristic search: The system is based on an improved A* search algorithm, which calculates alternative execution paths among the remaining available nodes. The evaluation function of the A* algorithm is defined as follows: f(n) = g(n) + h(n), Where g(n) is the actual migration cost from the starting node to the candidate node n, including the data transmission cost C. transfer (n), State reconstruction cost C rebuild (n) Resource switching cost C switch , g(n) = C transfer (n)+C rebuild (n)+C switch ; h(n) is a heuristic function that estimates the remaining cost from candidate node n to task completion, defined as: h(n) = T remaining (n)×(1 / DPS)×λ load (n), Among them, T remaining (n) represents the estimated remaining execution time on the candidate node, DPS is the dynamic priority score of the task, and λ load (n) is the load penalty factor for candidate nodes.

[0038] In this embodiment, as Figure 6As shown, the present invention also provides a dynamic scheduling system for cross-domain resources within an enterprise, used to implement the aforementioned dynamic scheduling method for cross-domain resources within an enterprise. The system includes: The task feature extraction and scoring module is used to extract multidimensional state variables from the request and calculate dynamic priority scores through a weighted evaluation model. The state machine resource negotiation module, connected to the task feature extraction and scoring module, is used to calculate the obtained DPS score, sort concurrent requests, and complete cross-domain resource negotiation and allocation through the resource state machine. The DPS-driven conflict degradation module is connected to the state machine resource negotiation module and is used to automatically trigger the degradation strategy based on the DPS score. The adaptive reordering module, connected to the conflict degradation module of the DPS driver, is used to monitor the health status of each resource node in real time through a heartbeat mechanism. When a node failure or response timeout is detected, the adaptive reordering process is immediately triggered.

[0039] In this embodiment, the scheduling engine sorts concurrent requests based on the calculated DPS score and completes cross-domain resource negotiation and allocation through the resource state machine. The core of this step lies in the DPS score's specific driving force for conflict identification and degradation decisions: DPS determines the resource sorting order, which task is prioritized in a conflict, and which task is sacrificed in the degradation strategy. The specific technical solution is as follows: Resource node state machine modeling. The system abstracts the resource pools of each functional department into independent state nodes. Each resource node has the following five states and transition rules:

[0040] (2) DPS Ranking and Resource Negotiation. The scheduling engine sorts all pending cross-domain resource requests from high to low according to their DPS scores, forming a priority queue. For each request, the system performs resource negotiation according to the following steps: 1. Analyze all resource nodes required by the task and their dependencies; 2. Check the current status of each resource node and filter candidate nodes whose status is AVAILABLE or DEGRADED; 3. Perform DPS-weighted matching on candidate nodes: prioritize assigning high-DPS tasks to high-performance (AVAILABLE) nodes; 4. If all required resource nodes are available, change the status of the relevant nodes from AVAILABLE to RESERVED and construct the resource reservation combination; 5. If there are unavailable resource nodes, mark the task as "waiting" and continue processing the next request.

[0041] (3) Resource Dependency Directed Graph Construction and Circular Dependency Detection. For cross-domain tasks with resource dependencies, the system constructs a resource dependency directed graph (RDG). Nodes in the RDG represent resource allocation relationships (task A holds resource R1), and directed edges represent resource request relationships (task A requests resource R2, and R2 is currently held by task B, so there is an edge A→B).

[0042] The system employs a topology sorting method based on the Kahn algorithm to detect the existence of cycles (i.e., circular dependencies / deadlocks) in an RDG. Topology sorting itself is a classic algorithm and does not constitute an independent inventive point of this invention. The core of this invention at this stage lies in the correlation between the topology sorting detection result and the DPS-driven degradation decision: topology sorting is only responsible for identifying the existence of circular dependencies and participating nodes, while how to break the circular dependencies is entirely driven by the DPS score—the choice of which task to sacrifice and which degradation strategy to adopt are all based on the DPS score.

[0043] (4) DPS-driven degradation strategy. When a circular dependency is detected, the system automatically triggers the degradation strategy. It is important to emphasize that the selection order and execution targets of the degradation strategy are based on the DPS score, rather than random selection or simple chronological order: Strategy 1: Task Splitting. Nodes holding large tasks with circular dependencies are split into multiple subtasks, releasing some occupied resources and breaking the circular dependency. The granularity of splitting is determined by the task's segmentability. During splitting, the subtask segment with the highest DPS score is prioritized for continued execution, while subtask segments with lower DPS are temporarily suspended.

[0044] Strategy Two: Suspend Low-DPS Tasks. In a deadlock loop, select the task with the lowest DPS score, suspend it, and release its resources. Suspended tasks enter a waiting queue and are rescheduled after the resource conflict is resolved. The core of this strategy is to determine the sacrifice target based on DPS rather than time order or randomness, ensuring that high-value tasks are always prioritized.

[0045] Strategy 3: Resource Degradation. If there are alternative nodes in the deadlock loop in a DEGRADED state, the task with the lowest DPS score is migrated from the OCCUPIED node to the DEGRADED node, breaking the deadlock at the cost of performance degradation. The task with the highest DPS score remains on the OCCUPIED node and continues to execute, unaffected by the degradation.

[0046] The execution priority of the three strategies mentioned above is as follows: Strategy 1 (split) → Strategy 2 (suspend) → Strategy 3 (downgrade). After each strategy is executed, the circular dependency is rechecked to see if it has been eliminated. If not, it is upgraded step by step. Throughout the downgrade process, the DPS score serves as the decision-making basis to determine "who is sacrificed and who is guaranteed," ensuring that the conflict resolution strategy and scheduling priority remain consistent.

[0047] The system monitors the health status of each resource node in real time through a heartbeat mechanism. When a node fails or times out, an adaptive reordering process is immediately triggered. The specific technical solution is as follows: (1) Heartbeat monitoring mechanism. Each resource node sends a heartbeat signal to the scheduling engine at a fixed period (default 2 seconds). The heartbeat signal includes: node ID, current status, load rate, and available capacity. The scheduling engine maintains a heartbeat time window (default 3 periods, i.e. 6 seconds). If no heartbeat is received from a node for 3 consecutive periods, the node is determined to be in the FAILED state and rescheduling is triggered immediately.

[0048] (2) Snapshot retention. When a node is determined to be FAILED, the system immediately extracts the context state vector (CSV) of all tasks currently executing on that node. The CSV contains the following information: Task identifiers: Task ID, DPS score; Execution progress: Completed steps, current step, remaining steps; Resource usage: List of allocated resources, resource consumption; Intermediate state: checkpoint data (such as weight parameters for model training, and signed / approved records in the approval process); Time information: task start time, end time, and execution time.

[0049] The system-level improvement—implicit priority isolation: In the traditional A* algorithm, all tasks share the same heuristic function, neglecting the priority differences between tasks. This invention introduces 1 / DPS into h(n), resulting in the system-level effect of asymmetric search behavior. High DPS tasks: 1 / DPS is relatively small, h(n) is compressed, A* search converges quickly, and tends to lock the optimal replacement node with the lowest migration cost.

[0050] Low DPS tasks: 1 / DPS is larger, h(n) is amplified, the A* search range is wider, and it tends to go to suboptimal but usable alternative nodes.

[0051] This asymmetric search behavior achieves implicit priority isolation: without the need for additional preemption mechanisms, high-priority and low-priority tasks naturally move to different alternative nodes during the search process, avoiding the conflict of "all faulty tasks competing for the same optimal node." This effect does not exist in the traditional A* algorithm and is a system-level behavior generated by introducing DPS into the heuristic function in this invention.

[0052] The essential difference between this invention and the weight adjustment in the path planning field: There is indeed an improvement idea of ​​adding weight factors to h(n) of A*, but there are three fundamental differences between the two: (1) Different scenarios - Path planning searches the physical path network, and all search objects converge to the same optimal path; This invention searches the resource node set and finds the optimal alternative node for different tasks with different DPS. (2) Different semantics - The weights in path planning are static environmental parameters shared by all objects; 1 / DPS in this invention is a dynamic score unique to each task, and different tasks use different heuristic functions. (3) Different objectives - Path planning introduces weights to optimize search efficiency or path quality; This invention introduces 1 / DPS to solve the priority isolation problem of "multiple tasks competing for the same optimal alternative node", which does not exist in the path planning field.

[0053] In summary, the scope of protection of the A* improvement of this invention is limited to the combined features of "resource scheduling failure recovery scenario" + "task-specific DPS weight" + "implicit priority isolation", rather than a generalized improvement of the A* algorithm weight.

[0054] Context compatibility constraints: The candidate node set for A* search is not simply the complete set of nodes with "state = AVAILABLE"; it must also satisfy the context state vector (CSV) compatibility constraint. Define the compatibility judgment function: Compat(n,CSV)=(Type match (n,CSV.task type )) ∧(Cap sufficient (n,CSV.resource need )) ∧ (Env compatible (n,CSV.runtime env )); Among them, Type match Check whether the resource types of candidate nodes match the task requirements (e.g., GPU model compatibility, approval permission matching), Cap sufficient Check if the remaining capacity of the node meets the estimated resource consumption of the task. compatibleCheck if the operating environment is compatible (e.g., CUDA version, approval system version). Nodes that do not meet the compatibility constraints are excluded from the search space. This constraint is not considered in the traditional A* algorithm and is a special adaptation of this invention for cross-domain heterogeneous resource scenarios.

[0055] Two-stage search strategy: To achieve a balance between search efficiency and path quality, this invention employs a two-stage A* search: Phase 1 (Rapid Localization): Using h(n) weighted by DPS as the heuristic function, quickly search the set of compatible nodes, with the goal of finding at least one feasible alternative path within 100ms.

[0056] Phase Two (Quality Optimization): If the migration cost of the path found in Phase One exceeds the threshold C. threshold Then, a second search is performed using a more refined h(n) (incorporating network transmission delay estimation between nodes) to optimize path quality.

[0057] (4) Seamless migration. After the A* algorithm finds the optimal replacement node, the system completes the seamless migration according to the following steps: 1. Mark the status of the faulty node as FAILED; 2. Change the candidate replacement node's state from AVAILABLE to RESERVED; 3. Inject the task's context state vector (CSV) into the replacement node; 4. The replacement node resumes execution from the checkpoint, and its status changes from RESERVED to OCCUPIED; 5. Notify the upper-level business system that the migration is complete, and the entire process is transparent to the business.

[0058] In summary, this invention not only avoids the logical contradiction of "prioritizing scheduling and prioritizing tasks, but randomly selecting tasks for conflict resolution and not considering priority in fault recovery," but also solves the unique technical problem in the field of resource scheduling: "multiple tasks competing for the same optimal alternative node."

[0059] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A dynamic scheduling method for cross-domain resources within an enterprise, characterized in that, The method includes: S1. Task multidimensional feature vectorization and dynamic scoring mechanism: When the system receives a cross-domain resource request, it extracts multidimensional state variables from the request and calculates the dynamic priority score through a weighted evaluation model. S2. Cross-domain resource negotiation and allocation based on state machine: The scheduling engine sorts concurrent requests according to the calculated DPS score and completes cross-domain resource negotiation and allocation through the resource state machine. S3. Adaptive Rearrangement Algorithm Triggered by Node Anomalies: The system monitors the health status of each resource node in real time through a heartbeat mechanism. When a node failure or response timeout is detected, the adaptive rearrangement process is immediately triggered.

2. The dynamic scheduling method for cross-domain resources within an enterprise according to claim 1, characterized in that, In step S1, calculating the dynamic priority score using the weighted evaluation model includes: S11. Feature extraction: The system extracts the following four feature variables from each cross-domain resource request: task urgency U(t), cross-domain dependency amplification factor Ω(t), business strategic value V(t), historical SLA achievement rate S(t), and resource consumption estimate R(t). S12. Weighted evaluation model: The system calculates the dynamic priority score using the following weighted formula. DPS(t)=α(t)·(U(t)×Ω(t))+β(t)·V(t)+γ(t)·S(t)+δ(t)·(1-R(t)), Where α(t), β(t), γ(t), and δ(t) are dynamic weight coefficients, satisfying α+β+γ+δ=1, and each value is [0,1]. S13. Dynamic update mechanism: The DPS score is not calculated all at once, but is dynamically refreshed at fixed intervals. Each time it is refreshed, U(t), S(t), and R(t) are extracted again and the DPS is recalculated. This ensures that the scheduling decision is always based on the latest task status.

3. The dynamic scheduling method for cross-domain resources within an enterprise according to claim 2, characterized in that, In step S11, the task urgency U(t) is, U(t)=max(0,1-(T deadline -t now ) / T estimated ) Among them, T deadline t is the task deadline. now T represents the current time. estimated The estimated execution time for the task is as follows: when U(t)=0, it means that the task has ample time; when U(t)→1, it means that the task is about to exceed the deadline and has the highest urgency.

4. The dynamic scheduling method for cross-domain resources within an enterprise according to claim 2, characterized in that, In step S11, the cross-domain dependent amplification factor Ω(t) is, Ω(t)=1+κ·(N domain -1), Where, N domain The number of cross-domain resource domains required for the task, κ is the amplification factor, defaulting to 0.15; The business strategic value V(t) reflects the contribution of the task to the company's strategic goals. It is a preset score in the range of [0, 1] and is automatically labeled by the business system according to the project level to which the task belongs: mass production level = 0.9, pre-research level = 0.5, and experimental level = 0.

2. V(t) does not change over time during the task's life cycle, but different tasks at the same project level can be fine-tuned according to the criticality of their respective sub-modules.

5. The dynamic scheduling method for cross-domain resources within an enterprise according to claim 2, characterized in that, In step S11, the historical SLA achievement rate S(t) reflects the historical on-time completion rate of this type of task, and takes a value of [0, 1]. The base value S0(t) = N. success / N total , where N success N represents the number of times a historical task has been completed on time. total Given the total number of executions in history, the initial value of the new task is S0(t) = 0.

5. To avoid bias caused by outdated historical data, a time decay factor is introduced: S(t) = S0(t)·e (-μ·Δt) Where Δt is the time difference between the most recent SLA record and the current time, and μ is the attenuation coefficient, which makes the weight of recent SLA records higher than that of distant records; the estimated resource consumption R(t) reflects the estimated resource scale occupied by the task, and takes a normalized value of [0,1], R(t=Resource estimate / Resource max Among them, Resource estimate To estimate resource consumption for the task, Resource max R(t) represents the total available resources of the system. The smaller the value of R(t), the more "lightweight" the task is, and the easier it is to be scheduled quickly.

6. The dynamic scheduling method for cross-domain resources within an enterprise according to claim 2, characterized in that, The dynamic weighting coefficients α(t), β(t), γ(t), and δ(t) do not use discrete tiered switching, but are adjusted by continuous linear interpolation based on the system load rate L(t), with the specific rules as follows: Define the baseline load factor L ref =65%, the formula for calculating the weighting coefficient is: α(t)=α base +k α ·(L(t)-L ref ) / L ref , δ(t)=δ base -k δ ·(L(t)-L ref ) / L ref , Where, α base =0.3,δ base =0.2, which is the baseline weight value; k α = 0.1, k δ =0.1 is the sensitivity adjustment coefficient; β(t) and γ(t) are finely adjusted from 0.3 and 0.2 to 0.25 and 0.25 respectively under high load; when L(t) > L ref When α(t) increases and δ(t) decreases, the system prioritizes urgency and SLA assurance; when L(t) < L ref When α(t) decreases and δ(t) increases, the system focuses on resource utilization. The continuous adjustment of the weight coefficients avoids sudden jitter during discrete tier switching, ensuring a smooth transition of scheduling decisions. To prevent weight imbalance under extreme loads, boundary constraints are set for α(t)∈[0.15, 0.5], β(t)∈[0.2, 0.35], γ(t)∈[0.15, 0.35], and δ(t)∈[0.05, 0.35].

7. The dynamic scheduling method for cross-domain resources within an enterprise according to claim 1, characterized in that, In step S2, the process of completing cross-domain resource negotiation and allocation through the resource state machine includes: S21. Resource node state machine modeling: The system abstracts the resource pools of each functional department into independent state nodes; S22. DPS sorting and resource negotiation: The scheduling engine sorts all pending cross-domain resource requests from high to low according to their DPS scores, forming a priority queue. S23. Resource Dependency Directed Graph Construction and Circular Dependency Detection: For cross-domain tasks with resource dependencies, the system constructs a resource dependency directed graph. Nodes in the RDG represent resource allocation relationships, and directed edges represent resource request relationships. S24. DPS-driven degradation strategy: When a circular dependency is detected, the system automatically triggers the following degradation strategy. The selection order and execution objects of the degradation strategy are based on the DPS score, rather than random selection or simple time ordering.

8. The dynamic scheduling method for cross-domain resources within an enterprise according to claim 7, characterized in that: The DPS-driven degradation strategy includes: Task splitting involves breaking down nodes with large circular dependencies into multiple subtasks, releasing some occupied resources, and breaking the circular dependency. The splitting granularity is determined by the task's segmentability. During splitting, the subtask segment with the highest DPS score is prioritized for continued execution, while the subtask segment with low DPS is temporarily suspended. Low DPS tasks are suspended. In the deadlock loop, the task with the lowest DPS score is selected, suspended, and its resources are released. The suspended task enters the waiting queue and is rescheduled after the resource conflict is resolved. The sacrifice target is determined by DPS rather than time order or randomness, ensuring that high-value tasks are always prioritized. Resource degradation is used. If there is a backup node in the DEGRADED state in the deadlock loop, the task with the lowest DPS score is migrated from the OCCUPIED node to the DEGRADED node to break the deadlock at the cost of performance degradation.

9. The dynamic scheduling method for cross-domain resources within an enterprise according to claim 1, characterized in that, In step S3, the adaptive reordering algorithm triggered by node anomalies includes: S31. Heartbeat monitoring mechanism: Each resource node sends a heartbeat signal to the scheduling engine at a fixed period. The heartbeat signal includes the node ID, current status, load rate, and available capacity. The scheduling engine maintains a heartbeat time window. If no heartbeat is received from a node for 3 consecutive periods, the node is determined to be in the FAILED state and reordering is triggered immediately. S32. Snapshot retention: When a node is determined to be FAILED, the system immediately extracts the context state vectors of all tasks currently being executed on that node; S33.DPS weighted heuristic search: The system is based on an improved A* search algorithm, which calculates alternative execution paths among the remaining available nodes. The evaluation function of the A* algorithm is defined as follows: f(n) = g(n) + h(n), Where g(n) is the actual migration cost from the starting node to the candidate node n, including the data transmission cost C. transfer (n), State reconstruction cost C rebuild (n) Resource switching cost C switch , g(n)=C transfer (n)+C rebuild (n)+C switch ; h(n) is a heuristic function that estimates the remaining cost from candidate node n to task completion, defined as: h(n)=T remaining (n)×(1 / DPS)×λ load (n), Among them, T remaining (n) represents the estimated remaining execution time on the candidate node, DPS is the dynamic priority score of the task, and λ load (n) is the load penalty factor for candidate nodes.

10. A dynamic scheduling system for cross-domain resources within an enterprise, characterized in that, The system is used to implement the dynamic scheduling method for cross-domain resources within an enterprise as described in any one of claims 1-9, the system comprising: The task feature extraction and scoring module is used to extract multidimensional state variables from the request and calculate dynamic priority scores through a weighted evaluation model. The state machine resource negotiation module, connected to the task feature extraction and scoring module, is used to calculate the obtained DPS score, sort concurrent requests, and complete cross-domain resource negotiation and allocation through the resource state machine. The DPS-driven conflict degradation module is connected to the state machine resource negotiation module and is used to automatically trigger the degradation strategy based on the DPS score. The adaptive reordering module, connected to the conflict degradation module of the DPS driver, is used to monitor the health status of each resource node in real time through a heartbeat mechanism. When a node failure or response timeout is detected, the adaptive reordering process is immediately triggered.

Images