A method, system and medium for state synchronization and dynamic scheduling of distributed tasks

Abstract

The application discloses a kind of state synchronization and dynamic scheduling method, system and medium of distributed task.The method is realized by constructing unified task state model and event protocol, realizes node real-time state synchronization and generates standardization state change event;Adopt vector clock causal ordering, hierarchical priority conflict resolution mechanism aggregation event, generate global consistent task view;Quantitative evaluation each node capability, load and health degree in combination with historical and real-time data, output node evaluation result;When satisfying scheduling trigger condition, based on global view and node evaluation result, optimal task allocation scheme is solved through multi-objective optimization model;After generating smooth batch migration plan to the task to be migrated feasibility check;According to plan, complete cross-node task handover, and based on scheduling feedback iterative update evaluation and optimization model parameters.The application solves the problem of data fragmentation, state timing conflict and scheduling cannot be self-adaptive under distributed task, improves processing efficiency and resource utilization.

Description

Technical Field

[0001] This application belongs to the field of task scheduling and allocation technology, specifically relating to a method, system and medium for state synchronization and dynamic scheduling of distributed tasks. Background Technology

[0002] In large-scale, distributed task processing applications, such as customer service, project collaboration, or complex business process management, central administrators typically need to distribute a large number of tasks to multiple parallel processing nodes (such as different teams, branch offices, or external service providers) for collaborative processing. These processing nodes often differ in geographical location, expertise, resource allocation, and processing efficiency.

[0003] However, existing multi-node parallel processing models generally suffer from the following technical bottlenecks: State information silos and synchronization delays: Task state information is scattered and stored in the local systems of various processing nodes, lacking a unified, real-time state synchronization mechanism. This makes it impossible for the central management to grasp the latest progress of the overall task in a timely and accurate manner, resulting in serious problems of information lag and state inconsistency, which affects the overall decision-making efficiency.

[0004] Lack of collaborative awareness and resource inefficiency: Different processing nodes lack the ability to collaboratively perceive related tasks (such as multiple requests initiated by the same customer or interdependent subtasks). This can lead to duplicated work, conflicting processing strategies, and even waste of resources and a decline in customer experience.

[0005] Static allocation rigidity and load imbalance: After initial task allocation, the allocation scheme is usually static. As the processing progresses, the external environment changes, or the load and capacity of each node fluctuate dynamically, the original allocation scheme may no longer be optimal. For example, some nodes may be overloaded due to task backlog, while other nodes are idle. Due to the lack of a dynamic scheduling mechanism, the system cannot intelligently migrate tasks from overloaded nodes to idle nodes, resulting in low overall resource utilization.

[0006] The scheduling decision is not intelligent: existing scheduling schemes mostly rely on preset simple rules or human experience, and lack a multi-objective optimization model that can comprehensively evaluate task characteristics, node capabilities, current load and migration costs, making it difficult to maximize global processing efficiency and benefits. Summary of the Invention

[0007] The technical problem to be solved by this application is to provide a method, system and medium for state synchronization and dynamic scheduling of distributed tasks, so as to solve the problems of uneven resource allocation and low processing efficiency caused by the asynchronous state information, lack of global consistency view and inability to perform intelligent dynamic scheduling based on the real-time load and capacity of nodes when multiple nodes are processing in parallel in the distributed processing scenario in the prior art.

[0008] To address the aforementioned technical problems, this application provides the following technical solution: Firstly, this application provides a method for state synchronization and dynamic scheduling of distributed tasks, including: A unified task state model and event protocol are constructed. Each processing node synchronizes its real-time state with the central scheduling layer through an event-driven mechanism based on the task state model and event protocol, and generates standardized state change events. For the aforementioned state change events, a causal sorting mechanism based on vector clocks and a hierarchical priority conflict resolution mechanism are used for global aggregation to generate a globally consistent task state view. Based on historical data and real-time status, the overall capabilities, real-time load, and health of each processing node are dynamically evaluated to generate node capability profiles and load assessment results. In response to preset scheduling trigger conditions, and taking the globally consistent task status view and the node capability profile and load assessment results as input, the optimal allocation scheme of tasks among nodes is solved through a multi-objective optimization model. Based on the optimal allocation scheme, the feasibility of the migration task is verified, and based on the verification results, a corresponding batch smooth migration plan is generated. The task is transferred across nodes according to the smooth migration plan, and the evaluation model and optimization model parameters are updated based on the scheduling effect feedback.

[0009] Furthermore, the causal ordering mechanism based on vector clocks includes: Maintain a logical clock vector with a dimension equal to the total number of nodes for each processing node. When an event is generated, increment the current node component and append the current vector clock. Causality is determined by comparing the vector clocks carried by the two events: if each component of the first vector is less than or equal to the corresponding component of the second vector and at least one component is strictly less than, then the first event is determined to be causally prior to the second event; if the components of the two vectors are of different magnitudes, then the two events are determined to be causally unrelated concurrent events. For events determined to be concurrent, the processing order is determined according to deterministic rules of business occurrence time, event type priority, and lexicographical order of event identifiers.

[0010] Furthermore, the hierarchical priority conflict resolution mechanism is as follows: When two events from different nodes modify the same component of the same task state and are concurrent events, they are considered to be in conflict. Conflicts should be resolved in a hierarchical manner according to the following priority levels: First priority: Updates of the nodes currently being handled by the task take precedence over updates of nodes not being handled by the task. Second priority: Stage change events take precedence over attribute update events; Third priority: Events that occur later in the business process take precedence; If the above priority rules cannot distinguish between them, both versions will be retained and marked as pending manual confirmation.

[0011] Furthermore, the comprehensive capability is constructed based on four dimensions: professional capability, handling efficiency, resource capacity, and geographical coverage. The professional competence dimension is obtained by weighting the historical processing performance of each node on various tasks according to the time window. The efficiency dimension includes average processing cycle, average effect achievement rate, cost-efficiency ratio, task completion rate, and satisfaction score; Resource capacity dimensions include total number of personnel, number of available personnel, number of professional personnel, and system concurrent processing capacity; The geographical coverage dimension is calculated based on the region where the node is located and the preset discount coefficient for remote coverage capability.

[0012] Furthermore, the real-time load is calculated as follows: ; in, The task load is determined by the ratio of the current number of subtasks to the maximum capacity of the node; The complexity-weighted load is determined by the average complexity coefficient across the subtasks; The proportion of workload for urgent tasks is determined by the percentage of tasks with an urgency level exceeding a preset threshold out of the total number of subtasks currently in operation. The pipeline saturation load is determined by the maximum ratio of the backlog of tasks in each processing stage to the upper limit of the processing capacity of the corresponding stage. These are the preset weighting coefficients for the load dimension; The health score is calculated as follows: ; in, The processing efficiency of node j within a preset recent time window. For the historical baseline performance of node j, The preset load attenuation index, Let be the stability index of node j.

[0013] Furthermore, the optimal allocation scheme is solved using a multi-objective optimization model, employing a hierarchical solution strategy, as detailed below: First layer: Relax the integer assignment constraints into continuous constraints, solve the relaxation problem using the interior point method, and obtain the continuous optimal solution; The second layer: Based on the continuous optimal solution, sort the tasks from high to low priority, and greedily select the node that maximizes the increment of the objective function and satisfies all constraints for each task to complete the integerization repair and obtain the integer solution. The third layer: Using the integer solution output from the second layer as the initial value, perform a preset number of local search iterations. Each time, randomly select two tasks to try to swap node assignments or migrate a single task to another node. If the objective function is improved and all constraints are satisfied after the swap or migration, the operation is accepted.

[0014] Furthermore, generating a corresponding batch smooth migration plan based on the verification results includes: The verified tasks to be migrated are sorted according to their migration priority. The migration priority is calculated by weighting the expected improvement in effect after migration, the urgency of migration, and the migration cost, resulting in a sorted task sequence. Based on the sorted task sequence, the tasks are evenly divided into a preset number of batches, with the number of tasks in each batch not exceeding the preset maximum migration amount per batch. Based on the results of the batch division, each batch is executed sequentially according to the preset migration interval, and the execution order between batches is arranged from high to low priority.

[0015] Furthermore, the task is transferred across nodes according to the smooth migration plan, and the parameters of the evaluation model and optimization model are updated based on the scheduling effect feedback, including: Update the matching degree prediction network parameters: Based on the actual handling effect of the completed migration task, the weight parameters of the matching degree prediction network are updated using the gradient descent method; Update node capability profile: Recalculate the professional capability dimension and handling efficiency dimension of each node based on the latest handling result data; Adaptive adjustment of scheduling target weights: When the average performance change of migrated tasks is negative, increase the weight coefficient of migration cost target to reduce unnecessary migrations; when the average performance change of migrated tasks exceeds the preset significant effect threshold, decrease the weight coefficient of migration cost target to encourage more beneficial migrations.

[0016] Secondly, this application also provides a distributed task state synchronization and dynamic scheduling system, including: The event generation module is used to build a unified task state model and event protocol. Each processing node synchronizes its real-time state with the central scheduling layer through an event-driven mechanism based on the task state model and event protocol, and generates standardized state change events. The state view generation module is used to globally aggregate the state change events using a vector clock-based causal sorting mechanism and a hierarchical priority conflict resolution mechanism to generate a globally consistent task state view. The evaluation results module is used to dynamically evaluate the overall capabilities, real-time load, and health of each processing node based on historical data and real-time status, and generate node capability profiles and load evaluation results. The allocation module is used to respond to preset scheduling trigger conditions, and take the globally consistent task status view and the node capability profile and load assessment results as input, and solve the optimal allocation scheme of tasks among nodes through a multi-objective optimization model. The verification module is used to verify the feasibility of the migration task according to the optimal allocation scheme, and generate a corresponding batch smooth migration plan based on the verification results. The scheduling and update module is used to perform task cross-node transfer according to the smooth migration plan, and update the evaluation model and optimization model parameters based on the scheduling effect feedback.

[0017] Thirdly, this application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of state synchronization and dynamic scheduling of distributed tasks as described above.

[0018] This application provides a method, system, and medium for state synchronization and dynamic scheduling of distributed tasks, the advantages of which are: This application first establishes a unified task state model and event protocol, relying on an event-driven mechanism to achieve real-time state synchronization of each distributed node. Then, it aggregates events uniformly through vector clock causal sorting and hierarchical priority conflict resolution mechanisms to generate a globally consistent task state view with accurate timing and no data contradictions. Subsequently, it quantifies the comprehensive capabilities, real-time load, and health of each processing node in multiple dimensions based on historical data and real-time status, outputting standardized node capability profiles and load assessment results. When the preset scheduling trigger conditions are met, the global task view and node assessment results are used as inputs, and a multi-objective optimization model is used to solve for the optimal allocation scheme that takes into account the overall processing effect, node load balancing, and task migration loss. Next, multi-level feasibility verification is carried out on the tasks to be migrated, generating a smooth migration plan with staggered peaks in batches for orderly execution of cross-node task handover. Finally, the scheduling implementation effect is continuously collected, and the parameters of the node assessment model and scheduling optimization model are updated in reverse iteration and fed back to the aforementioned assessment and scheduling links to form a closed-loop self-optimization system. This application integrates distributed node data synchronization, global data unification, node quantitative evaluation, intelligent scheduling, smooth migration, and adaptive iteration across the entire chain, effectively overcoming problems such as task data silos, disordered event timing, data conflicts, inability to quantify node status, static and fixed task allocation, business and system risks caused by batch migration, and scheduling strategies lacking self-optimization capabilities in existing technologies. It achieves unified visibility of task information across all nodes, balanced distribution of business load, and controllable risks in cross-node handover, continuously improving overall task processing efficiency and node resource utilization. Attached Figure Description

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

[0020] Figure 1 This is a flowchart illustrating a distributed task state synchronization and dynamic scheduling method according to an embodiment of this application; Figure 2 This is a schematic diagram of the structure of a distributed task state synchronization and dynamic scheduling system according to an embodiment of this application. Detailed Implementation

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

[0022] Please see Figure 1 This application provides a distributed task state synchronization and dynamic scheduling method, applied to a distributed collaborative processing scenario involving multiple external collaborating organizations. The management center centrally coordinates all business tasks, splitting and distributing large batches of tasks to multiple remote collaborative processing nodes for parallel processing. Each collaborative node possesses an independent business processing system, exhibiting significant differences in the types of tasks it can handle, personnel resources, offline geographical coverage, and business processing efficiency. This embodiment achieves unified synchronization of task data across multiple nodes and a global view through a complete closed-loop scheduling process. Figure 1 Consistency control, intelligent node assessment, automatic task dispatch, smooth handover, and model self-iterative optimization should include at least the following steps: S10. Construct a unified task state model and event protocol. Each processing node synchronizes its real-time state with the central scheduling layer through an event-driven mechanism based on the task state model and event protocol, and generates standardized state change events.

[0023] Specifically, step S10 first constructs a unified task state model and event protocol. This step is the data foundation of the entire method. By defining standardized state representations and event structures, it provides a unified language specification for real-time synchronization between each node and the central scheduling layer. The specific implementation is as follows: (I) Unified Task State Model For each task Its state is defined as a structured state vector: ; The components are defined as follows: : Task main stage identifier, with a value set of {pending allocation, processing, negotiating, preparing, in progress, executing, closed, suspended, awaiting reassignment}, and the data type is an enumeration value.

[0024] : Task sub-stage identifier, representing a detailed state under the main stage. For example, sub-stages under the "In Progress" main stage may include "Initiated", "Solution Development", "Evidence Exchange", "Review", "Pending Decision", etc., and the data type is an enumeration value.

[0025] : Task progress percentage, with a value range of [0,1], calculated as the ratio of the number of currently completed milestones to the total number of expected milestones.

[0026] The task dynamic attribute set includes, but is not limited to: current task size, completed workload, processing cost, last effective contact time, last status update time, current processing strategy code, estimated remaining workload, and estimated remaining processing time.

[0027] : The identifier of the node currently in charge of handling the issue; the data type is node number.

[0028] The status is last updated timestamp, with data type UTC timestamp and precision in milliseconds.

[0029] (II) Definition of State Change Events Define a State Change Event (SCE) as a structured message generated and reported by the handling node when the task state changes: ; The meanings of each field are as follows: The globally unique identifier for an event is generated by combining the node number, local sequence number, and timestamp hash.

[0030] : Unique identifier for the task.

[0031] : Identifier of the processing node that generated the event.

[0032] Event type, with a value set of {stage change, attribute update, achievement registration, strategy adjustment, anomaly reporting, milestone completion, and association discovery}.

[0033] State change increment, which only includes the state components that have changed and their new values.

[0034] : Event generation timestamp (node ​​local clock).

[0035] The time when the event occurred (the time when the actual business action took place).

[0036] : Precursor event identifier (which preceding event triggered this event, used to establish the causal chain of events), can be empty.

[0037] (III) Event-Driven Synchronization Protocol The state synchronization between each processing node and the central scheduling layer adopts an event-driven push-pull combined mechanism: Push mechanism: When a processing node generates a state change event, the event is immediately pushed to the central scheduling layer via a message queue. ; Push notifications employ at-least-once delivery semantics, using idempotent deduplication through unique event identifiers. In one specific implementation, the message queue uses Apache Kafka or RabbitMQ to ensure reliable transmission under high throughput.

[0038] Pull mechanism: The central scheduling layer uses a preset synchronous polling period. Actively pull the latest state snapshot from each node to verify the integrity of the pushed events: ; ; In one specific implementation, The value is set to 300 seconds (5 minutes). In another implementation, It can be dynamically adjusted according to network conditions, with a value range of 60 seconds to 600 seconds.

[0039] Heartbeat and Survival Detection: Each node operates according to a preset heartbeat cycle. Send a heartbeat message to the central scheduling layer, containing a summary of the node's current load: ; in, This is a summary of the node's current load. This represents the depth of the node's local queue of pending events. This is the event identifier last generated for the node. In one specific implementation, The value is 60 seconds. In another implementation, The value ranges from 30 seconds to 180 seconds.

[0040] When the central scheduling layer is continuous If no heartbeat message is received from a node within a heartbeat cycle, the node is marked as "suspected offline" and an alarm is triggered. In one specific implementation, The value is 3. In another implementation, The value ranges from 2 to 5.

[0041] (iv) Event serialization and transmission optimization For high-frequency state update scenarios, event batch aggregation and incremental compression transmission are adopted: Batch aggregation: In the preset aggregation window Internally, multiple attribute update events for the same task are merged into a single composite event: ; The merging rule is as follows: for multiple updates to the same attribute, only the latest value is retained; updates to different attributes are merged into a single incremental set. In one specific implementation, The value is 5 seconds. In another implementation, The value ranges from 2 seconds to 30 seconds, and the specific value is dynamically adjusted according to the event reporting frequency.

[0042] Incremental compression: Differential coding is used for transmitting state snapshots, transmitting only the parts that have changed relative to the last synchronization snapshot. ; in, This represents state differential operations. In one specific implementation, the differential encoding uses the JSON Patch format (RFC 6902) or a custom binary differential format to reduce network transmission bandwidth consumption.

[0043] The output of step S10 is the real-time state change event stream reported by each processing node. and periodically pulled state snapshots This serves as the input for step S20.

[0044] S20. For the state change events, a global aggregation is performed using a vector clock-based causal sorting mechanism and a hierarchical priority conflict resolution mechanism to generate a globally consistent task state view.

[0045] Specifically, step S20 receives the state change events output in step S10 and performs global aggregation on them. The core task of this step is to resolve the issues of event timing discrepancies and data conflicts in a distributed environment. Through causal ordering and conflict resolution mechanisms, fragmented node-reported data is merged into a globally consistent state view, providing a reliable data foundation for subsequent node evaluation and scheduling optimization. The specific implementation method is as follows: (I) Causal ordering mechanism based on vector clock Because the local clocks of each processing node may deviate, and network transmission may experience delays, the order in which events arrive at the central scheduling layer may differ from the actual order of occurrence. Therefore, this application employs a causal ordering mechanism based on vector clocks: Each handling node Maintain a logical clock vector ( (Total number of nodes to be processed), where the first... Each component represents a node. Known nodes The latest logical time.

[0046] When an event is generated, the node Increment its own logical clock and append the current vector clock: ; ; After receiving events, the central scheduling layer determines the causal relationships between events based on vector clocks. The specific determination rules are as follows: ; in, Represents a vector clock Each component is less than or equal to The corresponding component and at least one component is strictly less than.

[0047] If vector clock Each component is less than or equal to If the corresponding component is such that at least one component is strictly less than 0, then it is determined that... Cause and effect precede .

[0048] like and If the components of the two events are of different magnitudes, then the two events are determined to be concurrent events with no causal relationship.

[0049] For events determined to be concurrent, the processing order is determined according to the following deterministic rules: First, by the time the business occurred Sort by time (earlier ones are processed first); If the business events occur at the same time, they are sorted by event type priority (stage change events take precedence over attribute update events). If they still cannot be distinguished, sort them lexicographically by the event identifier EventID.

[0050] In one specific implementation, the vector clock is stored in the form of a hash table (HashMap), where the key is the node number and the value is the logical counter value of that node, and the initial state is an all-zero vector.

[0051] (II) Hierarchical Priority Conflict Resolution Mechanism When multiple nodes concurrently update the same state component of the same task, state conflicts may occur. Define conflict detection rules: ; That is, a conflict is a pair of events from different nodes that modify the same state component and are causally unrelated.

[0052] The conflict resolution strategy employs a hierarchical prioritization mechanism, determining issues level by level in the following order: First priority (highest): The node currently responsible for the task ( Updates from nodes that are currently responsible for the task take precedence over updates from nodes that are not responsible for the task. That is, if one of two conflicting events comes from the node currently responsible for the task, then that event is adopted.

[0053] Second priority: Phase change events take precedence over property update events. That is, if one of two conflicting events is of the "phase change" type, then that event is adopted.

[0054] Third priority: Time of business occurrence Later events take precedence. That is, events that actually occurred later in the business process are adopted.

[0055] Fourth priority (last resort): If the above rules cannot distinguish between the two versions, both versions will be retained and marked as "pending manual confirmation" for management personnel to make a decision.

[0056] The final state after conflict resolution is updated as follows: ; (III) Global State View Maintenance The central scheduling layer maintains a global task status view. It contains the latest consistent state of all tasks: ; Updates to the global state view adhere to the following consistency guarantees: Eventual consistency: If no new events occur, the state views of all nodes will converge to a consistent state after a finite amount of time.

[0057] Causal consistency: If events Cause precedes event ( Then the event will appear in the global state view. The effect always precedes the event. It is applied.

[0058] Monotonic read consistency: No rollback of state is observed in any request that queries the global state view.

[0059] To ensure the above, the global state view uses versioned storage, with a new version generated for each state update: ; in, This is the global state version number, which monotonically increases. In one specific implementation, the global state view is stored in a distributed database (such as TiDB or CockroachDB), utilizing its MVCC (Multi-Version Concurrency Control) mechanism to achieve versioned storage.

[0060] (iv) Linkage of related task status For task groups with related relationships (including but not limited to multiple related tasks for the same object, and related tasks within the same case package), maintain a relationship graph. :

[0061] in, Each edge in ( ) indicates a task and There exists a type of The relationship between them.

[0062] When the status of a task undergoes a specific change, an associated notification event is automatically generated and propagated to the responsible node of the associated task: ; in, This is a set of trigger event types corresponding to preset association types. For example, under the "same object" association type, the "result registration" and "stage change" events need to notify the associated task nodes.

[0063] The output of step S20 is a globally consistent task state view. The status notification is linked to the associated task and serves as input for steps S30 and S40.

[0064] S30. Based on historical data and real-time status, dynamically evaluate the comprehensive capabilities, real-time load, and health of each processing node, and generate node capability profiles and load assessment results.

[0065] Specifically, step S30, based on the global task status view output in step S20 and combined with the historical processing data of each node, performs a multi-dimensional comprehensive evaluation of each processing node. The purpose of this step is to quantitatively characterize the static capabilities and dynamic load of the nodes, generating an accurate node capability profile so that the scheduling layer can accurately determine "who can do what" and "who is currently available," thus providing input for the optimization decision in step S40. The specific evaluation process is as follows: In one embodiment of this application, the comprehensive capability is constructed based on four dimensions: professional capability, handling efficiency, resource capacity, and geographical coverage. The professional capability dimension is calculated by weighting the historical processing performance of each node across various tasks using a time window. The processing efficiency dimension includes average processing cycle, average result achievement rate, cost-efficiency ratio, task completion rate, and satisfaction rating. The resource capacity dimension includes total personnel, available personnel, number of professional personnel, and system concurrent processing capacity. The geographical coverage dimension is calculated based on the node's location and a preset remote coverage discount coefficient. Details are as follows: (I) Construction of Node Capability Profile For each processing node ( Construct a multi-dimensional capability profile vector: ; The components are defined as follows: Professional competence dimension : ; in, : Number of task type dimensions (including but not limited to the number of task types such as type A, type B, type C, and type D); :node The first historical processing A collection of tasks; :Task The actual processing results (such as completion rate, achievement rate, etc.); A preset capability assessment time window. In one specific implementation, The value is 365 days. In another implementation, The value ranges from 180 days to 730 days and can be dynamically configured according to business characteristics; : Smoothing factor, to prevent the denominator from being zero, takes the value of a small positive number.

[0066] Dimension of handling efficiency This includes, but is not limited to: average processing time (the average number of days from receiving a task to completing it); average performance achievement rate (the ratio of actual performance to expected performance); cost-efficiency ratio (the ratio of performance achieved to processing cost); task completion rate (the proportion of completed tasks out of the total number of received tasks); and satisfaction rating (a comprehensive rating based on feedback from stakeholders).

[0067] Resource capacity dimension This includes, but is not limited to: the total number of personnel handling the task; the number of currently available personnel (excluding those who are on leave, undergoing training, or otherwise unavailable); the number of professional personnel (personnel with specific qualifications or professional skills); and the system's concurrent processing capacity (the maximum number of tasks that can be processed simultaneously per unit of time).

[0068] Geographical coverage dimension : ; in, This is a preset remote coverage capability discount coefficient, with a value range of (0,1), representing the discount on a node's coverage capability for non-local tasks. In one specific implementation, The value is 0.6. In another implementation, The value ranges from 0.3 to 0.9, and is configured according to the node type and business characteristics.

[0069] (II) Real-time load assessment Perform multi-dimensional quantitative evaluation of the real-time load of node j: ; The specific calculation methods for each component are as follows: Task quantity load The ratio of the current number of subtasks to the maximum capacity of the node: ; in, For nodes The preset maximum task capacity is determined by data sourced from node service protocols or system configuration.

[0070] Complexity-weighted load Considering the differences in processing complexity among various tasks: ; in, Let be the complexity coefficient of task i, with a value range of [0.5, 3.0]. In one specific implementation, the complexity coefficient is comprehensively evaluated based on factors such as task type, amount involved, geographical distribution, and legal complexity.

[0071] Emergency tasks account for a significant portion of the workload. : ; in, Assess the urgency of task i (calculated based on factors such as remaining time and preservation time). This is a preset urgency threshold. In one specific implementation, The value is 0.7 (out of 1.0).

[0072] Pipeline saturation load This reflects the task backlog at each processing stage of the node. ; in, For node j in stage The upper limit of processing capacity.

[0073] Weighting coefficients: These are preset load dimension weights, with values ​​ranging from positive real numbers and summing to 1. In one specific implementation, the four weights are set to 0.25, 0.25, 0.25, and 0.25 (equal weights). In another implementation, the weight configuration is dynamically adjusted based on business priority.

[0074] (III) Node Health Assessment Comprehensive capability profiling and load assessment are used to calculate node health metrics. ; in, :node Recent handling efficiency (near The average achievement rate within a day), the data source is the completion statistics of the task for that node in the global status view. In one specific implementation, The value is 30 days.

[0075] The historical baseline performance of node j is calculated based on the historical data of that node over the past year.

[0076] The preset load attenuation index, with a value range of positive real numbers, is used to control the intensity of the load's impact on health. In one specific implementation, The value is 1.5.

[0077] Node stability index (calculated by combining heartbeat normality rate, event reporting timeliness rate, and system availability rate), with a value range of [0,1].

[0078] The output of step S30 is the capability profile, real-time load, and health assessment results for each node. This serves as the input for step S40.

[0079] S40. In response to the preset scheduling triggering conditions, the optimal allocation scheme of tasks among nodes is solved through a multi-objective optimization model, taking the globally consistent task status view and the node capability profile and load assessment results as input.

[0080] Specifically, step S40 takes the global task status view output from step S20 and the node capability profile and load assessment results output from step S30 as dual inputs, and initiates the scheduling optimization process when preset trigger conditions are met. This step is the core decision-making step of this method, and its goal is to comprehensively consider the three mutually constraining indicators of handling effect, load balancing, and migration cost from a global perspective, and solve for the optimal task allocation scheme. The specific optimization model and solution strategy are as follows: (a) Scheduling Triggering Conditions Dynamic scheduling is initiated when one of the following triggering conditions is met: Condition T1 (Periodic Scheduling): Based on a preset scheduling period Global scheduling optimizations are performed periodically. In one specific implementation, The value is 7 days. In another implementation, The value ranges from 1 day to 30 days.

[0081] Condition T2 (Load Imbalance Trigger): Triggered when the load imbalance between nodes exceeds a preset threshold. ; In one specific implementation, The value is 0.5. In another implementation, The value ranges from 0.3 to 0.8.

[0082] Condition T3 (Performance Anomaly Trigger): Triggered when the health of a node remains below a preset threshold. ; In one specific implementation, The value is 0.4. The value is 14 days.

[0083] Condition T4 (New Task Entering Pool Triggered): Triggered when a new batch of tasks needs to be initially allocated.

[0084] Condition T5 (Node Change Trigger): Triggered when a new node joins or an existing node leaves.

[0085] (II) Definition of Scheduling Decision Variables Define the scheduling decision variable matrix ,in: ; in, This represents the total number of currently active tasks (excluding completed tasks). Each task must be assigned to one node: ; (III) Multi-objective optimization function Define three objectives for scheduling optimization: Objective O1 – Maximizing the expected treatment effect: ; in, For the task Assigned to nodes The expected handling effect at that time is predicted by the matching degree between task characteristics and node capabilities: ; in, For the task The feature vectors include task type, scale range, region, complexity, current stage, etc. For matching degree prediction networks (such as machine learning models such as neural networks, random forests, or gradient boosting trees). These are learnable parameters, and the training data comes from historical task assignments and actual performance data.

[0086] Target O2 – Load Balancing Optimization: ; in: ; in, For nodes The complexity-weighted maximum capacity, The preset target load balancing level.

[0087] Target O3 – Minimize migration costs: ; in, For the task The migration costs (including but not limited to the manpower costs of task handover, information transmission costs, and costs of loss of continuity in handling) are determined by the current stage of the task and the depth of handling already invested: ; in, and The preset migration cost coefficient, Additional migration cost penalty for high-cost phase tasks.

[0088] Multi-objective weighted aggregation: ; in, These are preset target weight coefficients, with values ​​ranging from positive real numbers. In one specific implementation, the three weights are set to 0.5, 0.3, and 0.2, respectively. In another implementation, the weight values ​​are dynamically configured based on the business strategy.

[0089] (iv) Constraints The optimization process must meet the following constraints: Node capacity constraints: ; Geographic matching constraint (tasks requiring on-site handling must be assigned to nodes covering the corresponding geographic region): ; in, A collection of tasks requiring on-site handling. For the task The region to which it belongs.

[0090] Professional qualification constraints (specific types of tasks must be assigned to nodes with the corresponding qualifications): ; in, Represents a node Does it have the capability to handle task types? Qualifications.

[0091] Strongly related tasks have the same node constraint: ; in, For a set of strongly associated task pairs (e.g., multiple associated tasks of the same object).

[0092] Migration frequency constraints (to avoid frequent task migrations): ; in, For the task The last time we moved, This is the preset minimum dwell time. In one specific implementation, The value is 30 days.

[0093] (V) Layered Solution Strategy In one embodiment of this application, the optimal allocation scheme is solved using a multi-objective optimization model, employing a hierarchical solution strategy, as follows: First layer: Relax the integer assignment constraints into continuous constraints, and solve the relaxation problem using the interior point method to obtain a continuous optimal solution. Second layer: Based on the continuous optimal solution, sort tasks by priority from high to low, and greedily select the node that maximizes the increment of the objective function and satisfies all constraints for each task, completing the integerization repair and obtaining the integer solution. Third layer: Using the integer solution output from the second layer as the initial value, perform a preset number of local search iterations. Each time, randomly select two tasks to try swapping node assignments or migrating a single task to another node. If the objective function improves and satisfies all constraints after the swap or migration, the operation is accepted. Since the above optimization problem is a constrained large-scale integer programming problem, a hierarchical solution strategy is adopted: First layer – Relaxation solution: Relaxing integer constraints into continuous constraints The continuous optimal solution is obtained by solving the relaxation problem using the interior point method. .

[0094] The second layer—integerization repair: Based on the continuous optimal solutions, tasks are sorted from high to low priority (determined by weighted urgency and size). For each task, nodes that maximize the increment of the objective function and satisfy all constraints are greedily selected and allocated to complete the integerization repair, resulting in the integer solution.

[0095] The third layer – Local Search Improvement: Using integer solutions as initial values, perform a preset number of local search iterations. In each iteration, randomly select two tasks to try swapping node assignments or migrating a single task to another node. If the objective function is improved and all constraints are satisfied after the swap or migration, the operation is accepted.

[0096] In one implementation, the number of local search iterations is 1000. In another implementation, the number of iterations ranges from 500 to 5000, and is dynamically adjusted according to the task size.

[0097] The output of step S40 is the optimized scheduling scheme. and the corresponding task migration list This serves as the input for step S50.

[0098] S50. Based on the optimal allocation scheme, perform feasibility verification on the migration task to be migrated, and generate a corresponding batch smooth migration plan based on the verification results.

[0099] Specifically, step S50 receives the optimal allocation scheme and the list of tasks to be migrated output from step S40, and performs feasibility verification on the tasks to be migrated before implementation. The purpose of this step is to establish a safety barrier between scheduling decisions and actual execution, ensuring that each migration meets the conditions in three dimensions: business continuity, timeliness and security, and operational channels, and reducing the impact of batch migrations on the system through a staggered, phased migration strategy. The specific verification and planning process is as follows: (I) Business Continuity Verification For migration list For each task to be migrated, verify that the migration will not cause business interruption: High-cost phase task verification: For tasks in progress or execution, verify whether the target node has the ability to continue the current phase of the processing procedure. ; in, This indicates whether the target node's qualification coverage includes the specific conditions required for the task. This represents the target node's familiarity score with this task type. This is a preset familiarity threshold.

[0100] Verification of time-sensitive tasks: For tasks with short remaining deadlines, verify that the migration process will not lead to time-related risks. ; in, This is the estimated time for task migration and handover (including the time for data transfer, system switching, and familiarization with the new nodes). This is the preset safety margin for timeliness.

[0101] Operation channel continuity verification: Verify the continuity of critical operation channels after task migration (ensure that relevant operation authorizations are valid on the new node).

[0102] Tasks that do not meet business continuity verification requirements are removed from the migration list, while the original node allocation remains unchanged.

[0103] (II) Migration Priority Ranking For the migration tasks that have passed the verification, determine the migration execution order according to migration urgency and expected benefits: ; in, The urgency of migration is indicated (high urgency if the original node is severely overloaded or has extremely low health). These are preset priority dimension weights. In one specific implementation, the three weights are set to 0.4, 0.3, and 0.3, respectively.

[0104] (III) Generation of a Smooth Migration Plan In one embodiment of this application, the smooth migration plan generation includes: The verified tasks to be migrated are sorted according to their migration priority. The migration priority is calculated by weighting the expected improvement in effect after migration, the urgency of migration, and the migration cost, resulting in a sorted task sequence. Based on the sorted task sequence, the tasks are evenly divided into a preset number of batches, with the number of tasks in each batch not exceeding the preset maximum migration amount per batch. Based on the results of the batch division, each batch is executed sequentially according to the preset migration interval, and the execution order between batches is arranged from high to low priority.

[0105] Understandably, to avoid system overload caused by migrating a large number of tasks simultaneously, a phased, smooth migration plan is generated: The verified tasks to be migrated are sorted by migration priority to obtain a sorted task sequence; based on the sorted task sequence, the tasks are evenly divided into a preset number of batches: ; The number of tasks in each batch shall not exceed the preset maximum migration amount per batch. : ; Based on the batch division results, each batch is executed sequentially according to the preset migration interval time, and the execution order between batches is arranged from high to low priority.

[0106] In one specific implementation, The value is 5. The value is 2 days. The value is set to 50. In another implementation, the above parameter is dynamically adjusted based on the total number of tasks and the system's capacity.

[0107] The output of step S50 is a validated and confirmed batch smooth migration plan. This serves as the input for step S60.

[0108] S60. Perform task cross-node transfer according to the smooth migration plan, and update the evaluation model and optimization model parameters based on scheduling effect feedback.

[0109] Step S60, following the smooth migration plan output in step S50, formally executes the task cross-node transfer. This step is not only the final implementation of the scheduling scheme but also a crucial link in the entire closed-loop system—by monitoring the actual effects after migration and feeding feedback data back to the evaluation and optimization models, the scheduling strategy gains the ability to continuously evolve. The specific migration protocol and feedback update mechanism are as follows: In one embodiment of this application, step S60 includes: Update the matching degree prediction network parameters: Based on the actual handling effect of the completed migration task, the weight parameters of the matching degree prediction network are updated using the gradient descent method; Update node capability profile: Recalculate the professional capability dimension and handling efficiency dimension of each node based on the latest handling result data; Adaptive adjustment of scheduling target weights: When the average performance change of migrated tasks is negative, increase the weight coefficient of the migration cost target to reduce unnecessary migrations; when the average performance change of migrated tasks exceeds a preset significant effect threshold, decrease the weight coefficient of the migration cost target to encourage more beneficial migrations, as detailed below: (I) Task Migration Execution Agreement For each task i to be migrated (from the source node) Migrate to target node The following four-phase migration protocol will be implemented: Phase M1 – Migration Preparation: The central scheduling layer sends a migration preparation instruction to the source node, and the source node freezes the task status update (only emergency operations are allowed). The source node packages a complete information package of the task (including basic task information, processing history, current strategy, key contact information, materials list, and to-do list).

[0110] Phase M2 – Information Transmission: The source node transmits the task information packet to the target node through an encrypted channel (such as a TLS / SSL encrypted connection); The central scheduling layer synchronously updates the node affiliation of tasks in the global status view: .

[0111] Phase M3 – Receive Confirmation: The target node receives the information packet and performs integrity verification (such as through hash value verification or digital signature verification). The target node confirms receipt and generates a receipt confirmation event: ; Phase M4 – Parallel Transition Period: During the pre-set transition period Within the system, both the source node and the target node can view task information, and the source node is responsible for answering inquiries from the target node. After the transition period ends, the task access permissions of the source node will be automatically revoked.

[0112] In one specific implementation, The value is 7 days. In another implementation, The value ranges from 3 to 14 days, and is dynamically adjusted based on the complexity of the task and familiarity with the nodes.

[0113] (II) Monitoring the scheduling effect For the implemented scheduling schemes, continuously monitor the following performance metrics: Performance changes after migration: For each migrated task i, compare the processing performance before and after migration. ; in, For the post-migration The actual progress of the handling within the day, This is to extrapolate the expected progress of the treatment based on the pre-migration trend. In one specific implementation, The value is 30 days.

[0114] Changes in global load balancing: ; Changes in overall processing efficiency: ; (III) Model Parameter Feedback Update Based on scheduling performance monitoring data, update the following model parameters: Match prediction network update: ; in, This refers to the set of tasks that have completed the migration and have a sufficient observation period. To determine the actual effectiveness of the relocation, This is the preset learning rate for the matching model. In one specific implementation, The value is 0.001.

[0115] Node capability profile update: Recalculate the professional capability dimension and handling efficiency dimension of each node based on the latest handling result data.

[0116] The scheduling target weight is adaptively adjusted:

[0117] ; in, The preset weight adjustment step size, This is a preset threshold for significant effect. When the average migration effect is negative, the migration cost weight is increased (to reduce unnecessary migrations); when the migration effect is significant, the migration cost weight is decreased (to encourage more beneficial migrations). In one specific implementation, The value is 0.1. The value is 0.05.

[0118] This application provides a method for state synchronization and dynamic scheduling of distributed tasks, the advantages of which are: This application first establishes a unified task state model and event protocol, relying on an event-driven mechanism to achieve real-time state synchronization of each distributed node. Then, it aggregates events uniformly through vector clock causal sorting and hierarchical priority conflict resolution mechanisms to generate a globally consistent task state view with accurate timing and no data contradictions. Subsequently, it quantifies the comprehensive capabilities, real-time load, and health of each processing node in multiple dimensions based on historical data and real-time status, outputting standardized node capability profiles and load assessment results. When the preset scheduling trigger conditions are met, the global task view and node assessment results are used as inputs, and a multi-objective optimization model is used to solve for the optimal allocation scheme that takes into account the overall processing effect, node load balancing, and task migration loss. Next, multi-level feasibility verification is carried out on the tasks to be migrated, generating a smooth migration plan with staggered peaks in batches for orderly execution of cross-node task handover. Finally, the scheduling implementation effect is continuously collected, and the parameters of the node assessment model and scheduling optimization model are updated in reverse iteration and fed back to the aforementioned assessment and scheduling links to form a closed-loop self-optimization system. This application integrates distributed node data synchronization, global data unification, node quantitative evaluation, intelligent scheduling, smooth migration, and adaptive iteration across the entire chain, effectively overcoming problems such as task data silos, disordered event timing, data conflicts, inability to quantify node status, static and fixed task allocation, business and system risks caused by batch migration, and scheduling strategies lacking self-optimization capabilities in existing technologies. It achieves unified visibility of task information across all nodes, balanced distribution of business load, and controllable risks in cross-node handover, continuously improving overall task processing efficiency and node resource utilization.

[0119] Please see Figure 2 This application also provides a distributed task state synchronization and dynamic scheduling system 200, including: The event generation module 201 is used to construct a unified task state model and event protocol. Each processing node synchronizes its real-time state with the central scheduling layer through an event-driven mechanism based on the task state model and event protocol, and generates standardized state change events. The state view generation module 202 is used to globally aggregate the state change events using a vector clock-based causal sorting mechanism and a hierarchical priority conflict resolution mechanism to generate a globally consistent task state view. The evaluation results module 203 is used to dynamically evaluate the comprehensive capabilities, real-time load and health of each processing node based on historical data and real-time status, and generate node capability profiles and load evaluation results. The allocation module 204 is used to respond to preset scheduling trigger conditions, and take the globally consistent task status view and the node capability profile and load assessment results as input, and solve the optimal allocation scheme of tasks among nodes through a multi-objective optimization model. The verification module 205 is used to verify the feasibility of the migration task according to the optimal allocation scheme, and generate a corresponding batch smooth migration plan based on the verification results. The scheduling and update module 206 is used to perform task cross-node transfer according to the smooth migration plan, and update the evaluation model and optimization model parameters based on the scheduling effect feedback.

[0120] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of state synchronization and dynamic scheduling of a distributed task as described above.

[0121] In this embodiment, the computer-readable storage medium can be a non-volatile storage medium or a volatile storage medium. For example, the computer storage medium may include, but is not limited to, various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0122] In all examples shown and described herein, any specific values ​​should be interpreted as merely exemplary and not as limitations; therefore, other examples of exemplary embodiments may have different values.

[0123] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0124] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings show the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that, in alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagram and / or flowchart, and combinations of blocks in the block diagram and / or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0125] In addition, the functional modules or units in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0126] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a terminal device (which may be a smartphone, personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application.

[0127] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A method for state synchronization and dynamic scheduling of distributed tasks, characterized in that, include: A unified task state model and event protocol are constructed. Each processing node synchronizes its real-time state with the central scheduling layer through an event-driven mechanism based on the task state model and event protocol, and generates standardized state change events. For the aforementioned state change events, a causal sorting mechanism based on vector clocks and a hierarchical priority conflict resolution mechanism are used for global aggregation to generate a globally consistent task state view. Based on historical data and real-time status, the overall capabilities, real-time load, and health of each processing node are dynamically evaluated to generate node capability profiles and load assessment results. In response to preset scheduling trigger conditions, and taking the globally consistent task status view and the node capability profile and load assessment results as input, the optimal allocation scheme of tasks among nodes is solved through a multi-objective optimization model. Based on the optimal allocation scheme, the feasibility of the migration task is verified, and based on the verification results, a corresponding batch smooth migration plan is generated. The task is transferred across nodes according to the smooth migration plan, and the evaluation model and optimization model parameters are updated based on the scheduling effect feedback.

2. The method according to claim 1, characterized in that, The vector clock-based causal ordering mechanism includes: Maintain a logical clock vector with a dimension equal to the total number of nodes for each processing node. When an event is generated, increment the current node component and append the current vector clock. Causality is determined by comparing the vector clocks carried by the two events: if each component of the first vector is less than or equal to the corresponding component of the second vector and at least one component is strictly less than, then the first event is determined to be causally prior to the second event; if the components of the two vectors are of different magnitudes, then the two events are determined to be causally unrelated concurrent events. For events determined to be concurrent, the processing order is determined according to deterministic rules of business occurrence time, event type priority, and lexicographical order of event identifiers.

3. The method according to claim 1, characterized in that, The hierarchical priority conflict resolution mechanism is as follows: When two events from different nodes modify the same component of the same task state and are concurrent events, they are considered to be in conflict. Conflicts should be resolved in a hierarchical manner according to the following priority levels: First priority: Updates of the nodes currently being handled by the task take precedence over updates of nodes not being handled by the task. Second priority: Stage change events take precedence over attribute update events; Third priority: Events that occur later in the business process take precedence; If the above priority rules cannot distinguish between them, both versions will be retained and marked as pending manual confirmation.

4. The method according to claim 1, characterized in that, The comprehensive capabilities are constructed based on four dimensions: professional capabilities, handling efficiency, resource capacity, and geographical coverage. The professional competence dimension is obtained by weighting the historical processing performance of each node on various tasks according to the time window. The efficiency dimension includes average processing cycle, average effect achievement rate, cost-efficiency ratio, task completion rate, and satisfaction score; Resource capacity dimensions include total number of personnel, number of available personnel, number of professional personnel, and system concurrent processing capacity; The geographical coverage dimension is calculated based on the region where the node is located and the preset discount coefficient for remote coverage capability.

5. The method according to claim 1, characterized in that, The real-time load is calculated as follows: ； in, The task load is determined by the ratio of the current number of subtasks to the maximum capacity of the node; The complexity-weighted load is determined by the average complexity coefficient across the subtasks; The proportion of workload for urgent tasks is determined by the percentage of tasks with an urgency level exceeding a preset threshold out of the total number of subtasks currently in operation. The pipeline saturation load is determined by the maximum ratio of the backlog of tasks in each processing stage to the upper limit of the processing capacity of the corresponding stage. These are the preset weighting coefficients for the load dimension; The health score is calculated as follows: ； in, The processing efficiency of node j within a preset recent time window. For the historical baseline performance of node j, The preset load attenuation index, Let be the stability index of node j.

6. The method according to claim 1, characterized in that, The optimal allocation scheme is solved using a multi-objective optimization model, employing a hierarchical solution strategy, as detailed below: First layer: Relax the integer assignment constraints into continuous constraints, solve the relaxation problem using the interior point method, and obtain the continuous optimal solution; The second layer: Based on the continuous optimal solution, sort the tasks from high to low priority, and greedily select the node that maximizes the increment of the objective function and satisfies all constraints for each task to complete the integerization repair and obtain the integer solution. The third layer: Using the integer solution output from the second layer as the initial value, perform a preset number of local search iterations. Each time, randomly select two tasks to try to swap node assignments or migrate a single task to another node. If the objective function is improved and all constraints are satisfied after the swap or migration, the operation is accepted.

7. The method according to claim 1, characterized in that, The step of generating a corresponding batch smooth migration plan based on the verification results includes: The verified tasks to be migrated are sorted according to their migration priority. The migration priority is calculated by weighting the expected improvement in effect after migration, the urgency of migration, and the migration cost, resulting in a sorted task sequence. Based on the sorted task sequence, the tasks are evenly divided into a preset number of batches, with the number of tasks in each batch not exceeding the preset maximum migration amount per batch. Based on the results of the batch division, each batch is executed sequentially according to the preset migration interval, and the execution order between batches is arranged from high to low priority.

8. The method according to claim 1, characterized in that, The task is transferred across nodes according to the smooth migration plan, and the evaluation model and optimization model parameters are updated based on the scheduling effect feedback, including: Update the matching degree prediction network parameters: Based on the actual handling effect of the completed migration task, the weight parameters of the matching degree prediction network are updated using the gradient descent method; Update node capability profile: Recalculate the professional capability dimension and handling efficiency dimension of each node based on the latest handling result data; Adaptive adjustment of scheduling target weights: When the average performance change of migrated tasks is negative, increase the weight coefficient of migration cost target to reduce unnecessary migrations; when the average performance change of migrated tasks exceeds the preset significant effect threshold, decrease the weight coefficient of migration cost target to encourage more beneficial migrations.

9. A distributed task state synchronization and dynamic scheduling system, characterized in that, include: The event generation module is used to build a unified task state model and event protocol. Each processing node synchronizes its real-time state with the central scheduling layer through an event-driven mechanism based on the task state model and event protocol, and generates standardized state change events. The state view generation module is used to globally aggregate the state change events using a vector clock-based causal sorting mechanism and a hierarchical priority conflict resolution mechanism to generate a globally consistent task state view. The evaluation results module is used to dynamically evaluate the overall capabilities, real-time load, and health of each processing node based on historical data and real-time status, and generate node capability profiles and load evaluation results. The allocation module is used to respond to preset scheduling trigger conditions, and take the globally consistent task status view and the node capability profile and load assessment results as input, and solve the optimal allocation scheme of tasks among nodes through a multi-objective optimization model. The verification module is used to verify the feasibility of the migration task according to the optimal allocation scheme, and generate a corresponding batch smooth migration plan based on the verification results. The scheduling and update module is used to perform task cross-node transfer according to the smooth migration plan, and update the evaluation model and optimization model parameters based on the scheduling effect feedback.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of state synchronization and dynamic scheduling of distributed tasks as described in any one of claims 1-8.

Images