A distributed workflow task scheduling method and system

Abstract

The application provides a distributed workflow task scheduling method and system, and relates to the technical field of computers. The scheduling task nodes and dependency relationships are defined and stored in a drag-and-drop manner through a visual canvas. The Worker nodes with a normal ZooKeeper center hop state are screened, the node weights are calculated based on dynamic load balancing, and the tasks are distributed to the Worker nodes with the highest weights for execution. When a Worker node fails, the ZooKeeper node deletion event is listened to, the IP and port of the faulty Worker are identified, the task states of the un-terminated nodes of the faulty node are marked as needing fault tolerance and are re-allocated. When a Master node fails, the surviving Master takes over the workflow instance of the faulty Master based on a slot allocation mechanism. The task reporting address in the Worker is updated to the current Master, and the uncompleted tasks are re-dispatched. The overall usability, efficiency and stability of the workflow scheduling are improved, and the method is suitable for diversified business requirements.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a distributed workflow task scheduling method and system. Background Technology

[0002] Distributed workflow task scheduling refers to the process of distributing a business process consisting of multiple dependent tasks to multiple nodes for scheduling and execution. It is usually defined by a directed acyclic graph (DAG) to define the order of tasks and achieve parallel processing and efficient collaboration of tasks through a distributed architecture.

[0003] As business operations become increasingly complex, workflows encompass a wider variety of task types and expand in scale, placing higher demands on the visualization and orchestration capabilities, resource utilization efficiency, and fault tolerance of scheduling systems. Traditional centralized scheduling models struggle to handle the parallel processing needs of large-scale tasks, while existing distributed solutions suffer from shortcomings in task type scalability, dynamic load balancing, and node failure handling, gradually becoming bottlenecks restricting efficient business operations.

[0004] Existing technologies have significant limitations: First, task definitions rely heavily on code configuration, lacking intuitive visual interaction, making the orchestration and maintenance of complex workflows difficult; second, task types are fixed, and expanding to new types requires significant modifications to the underlying logic, making it difficult to adapt to diverse business scenarios; third, the load distribution strategy is simple, which can easily lead to uneven utilization of node resources and affect overall execution efficiency; fourth, the fault tolerance mechanism is imperfect, resulting in high task recovery delays when nodes fail and the risk of single point of failure, making it difficult to guarantee the high availability of the system. Summary of the Invention

[0005] To address the aforementioned issues, this invention proposes a distributed workflow task scheduling method and system. It lowers the operational threshold by enabling visual drag-and-drop workflow configuration, allowing for flexible task definition and reuse. A dynamic load balancing algorithm rationally allocates tasks, improving cluster resource utilization. Fault-tolerant mechanisms for Worker and Master nodes, combined with a failure retry strategy, ensure reliable task execution. A decentralized architecture and slot allocation mechanism avoid single points of failure, ensuring high system availability. Overall, this improves the ease of use, efficiency, and stability of workflow scheduling, adapting to diverse business needs.

[0006] To achieve the above objectives, the present invention adopts the following technical solution:

[0007] In a first aspect, the present invention provides a distributed workflow task scheduling method, comprising:

[0008] Define scheduling task nodes and their dependencies by dragging and dropping on a visual canvas, and store task node information, inter-node dependencies, and canvas coordinates;

[0009] Filter the Worker nodes with the ZooKeeper centerbeat status as normal, calculate the node weight based on the dynamic load balancing algorithm, and distribute the task to the Worker node with the highest weight for execution;

[0010] When a Worker node fails, listen for ZooKeeper node deletion events to identify the IP address and port of the failed Worker; mark any unterminated tasks on the failed node as requiring fault tolerance and reallocation;

[0011] When the Master node fails, the surviving Master takes over the workflow instance of the failed Master based on the slot allocation mechanism; updates the task reporting address in the Worker to the current Master, and re-dispatches the unfinished tasks.

[0012] Secondly, the present invention provides a distributed workflow task scheduling system, comprising:

[0013] The visualization definition module is used to define scheduling task nodes and their dependencies by dragging and dropping on a visual canvas, and to store task node information, inter-node dependencies, and canvas coordinates.

[0014] The load balancing distribution module is used to filter Worker nodes whose ZooKeeper center hop status is normal, calculate node weights based on a dynamic load balancing algorithm, and distribute tasks to the Worker node with the highest weight for execution.

[0015] The Worker fault tolerance module is used to listen for ZooKeeper node deletion events when a Worker node fails, identify the IP and port of the failed Worker, mark the status of unterminated tasks on the failed node as requiring fault tolerance and reallocate them;

[0016] The Master high availability module is used to take over the workflow instance of the failed Master based on the slot allocation mechanism when the Master node fails; update the task reporting address in the Worker to the current Master, and re-dispatch the unfinished tasks.

[0017] Thirdly, the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the distributed workflow task scheduling method described in the first aspect.

[0018] Fourthly, the present invention provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the distributed workflow task scheduling method described in the first aspect.

[0019] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0020] This invention supports drag-and-drop configuration of tasks and dependencies through a visual canvas, combined with task information storage and rendering mechanisms, reducing user complexity and enabling efficient workflow reuse and secondary editing. Customizable extension interfaces for the task scheduling component meet the needs of various task types, including SQL and HTTP, enhancing system flexibility. A dynamic load balancing algorithm comprehensively allocates tasks based on hardware resources and task load, avoiding node overload and improving execution efficiency. Worker and Master nodes rely on the ZooKeeper monitoring mechanism for rapid fault identification and task reallocation, combined with multi-layered retry strategies to ensure reliable task operation. The decentralized architecture and slot allocation mechanism eliminate single points of failure, ensuring high cluster availability and fully adapting to complex scenarios of distributed workflow scheduling.

[0021] Advantages of additional aspects of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0022] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute a limitation thereof.

[0023] Figure 1 The main flowchart of a distributed workflow task scheduling method provided in an embodiment of the present invention is shown. Detailed Implementation

[0024] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0025] Explanation of technical terms

[0026] 1. Workflow: The process of scheduling and executing a series of tasks in a predefined order in order to achieve specific business goals.

[0027] 2. Scheduled Tasks: Tasks contained within a workflow. These tasks have dependencies on each other, and the current task can only be executed after all the preceding tasks have been successfully completed.

[0028] 3. DAG (Directed Acyclic Graph): Tasks in a workflow are assembled in the form of a directed acyclic graph, and the topology is traversed from the node with an in-degree of zero until there are no successor nodes.

[0029] 4. Web server: Includes functions such as workflow definition, workflow instance / scheduled task instance management, and runtime status monitoring.

[0030] 5. Master (master-server): Scans for runnable workflows in real time, creates workflow instances, schedules task instances, and distributes task instances to worker-servers for execution.

[0031] 6. Worker (worker-server): Provides the execution logic for scheduling task instances and reports the running status of task instances to the master-server.

[0032] 7. alert-server: Sends workflow and scheduling task execution result notifications and alarm notifications.

[0033] 8. ZooKeeper (ZK): Use ZooKeeper as the service registry center for Master, Worker, and alert-server services to enable dynamic discovery and communication between services.

[0034] Example 1

[0035] like Figure 1 As shown in the figure, this embodiment discloses a distributed workflow task scheduling method, including the following steps:

[0036] S1: Define scheduling task nodes and their dependencies by dragging and dropping on a visual canvas, and store task node information, inter-node dependencies, and canvas coordinates;

[0037] S2: Filter the Worker nodes with the ZooKeeper center jump status as normal, calculate the node weight based on the dynamic load balancing algorithm, and distribute the task to the Worker node with the highest weight for execution;

[0038] S3: When a Worker node fails, listen for ZooKeeper node deletion events, identify the IP and port of the failed Worker, and mark the status of any unterminated tasks on the failed node as requiring fault tolerance and reallocation.

[0039] S4: When the Master node fails, the surviving Master takes over the workflow instance of the failed Master based on the slot allocation mechanism; updates the task reporting address in the Worker to the current Master, and re-dispatches the unfinished tasks.

[0040] Next, combined Figure 1 This embodiment provides a detailed description of a distributed workflow task scheduling method.

[0041] In S1, task nodes and their dependencies are defined by dragging and dropping on a visual canvas. The task node information, inter-node dependencies, and canvas coordinates are stored. Custom extensions of task components are also supported, enabling flexible workflow configuration and adaptation to diverse task requirements.

[0042] The workflow visualization canvas provided by the web server allows users to drag and drop task components, such as SQL tasks and HTTP tasks, within the workflow canvas; fill in the task name, task type, and task parameters, such as the SQL to be executed and data source information for the SQL task component, and the request type (GET / POST), request URL, and request parameters for the HTTP task component; and define the dependencies between tasks.

[0043] The system will save all the scheduling task information drawn during the workflow drawing process, including: scheduling task node information drawn in the canvas, including task name, task type, task parameters, etc.; the relationship between scheduling task nodes, including storing the information of the preceding and following nodes of the scheduling task node; and the coordinates of the scheduling task node, which are recorded in the form of (x,y) data to show the position coordinates of the task node in the canvas.

[0044] When a user re-enters the workflow canvas interface, the system will query the scheduling task information that has been drawn in the workflow and complete the page rendering and display based on this data.

[0045] In addition, to support custom extensions of the scheduling task component, relevant abstract classes and interfaces are defined:

[0046] The BaseParameter.class interface: Subclasses can implement it to extend business parameters;

[0047] AbstractTask.class contains the execute method. Subclasses can inherit from this class to customize the scheduling task execution logic. For example, the SQL task component's task execution logic is to execute SQL on the target data source, and the HTTP task component's task execution logic is to send an HTTP request.

[0048] The TaskChannel.class interface contains the createTask method. Subclasses that implement this interface can create different instances of the AbstractTask subclass.

[0049] The TaskChannelFactory.class factory class creates different TaskChannel subclass instances based on different task types.

[0050] Specifically, the BaseParameter.class interface serves as the basic contract for defining all task parameters. By implementing this interface, subclasses can flexibly extend and encapsulate the business parameters required for specific types of tasks, such as SQL statements and data source information in SQL tasks, and request methods and URL parameters in HTTP tasks, thereby achieving standardization and scalability of parameter structures.

[0051] The AbstractTask.class abstract class encapsulates the basic framework for task execution. Its defined execute() method provides a unified entry point for specific task execution logic. Subclasses can inherit from this class and implement the execute() method to customize specific task behaviors such as executing SQL or sending HTTP requests, thereby organically connecting task parameters with the task execution process.

[0052] The TaskChannel.class interface acts as a task instantiation factory. Its createTask() method is responsible for constructing the corresponding AbstractTask subclass object based on the passed TaskExecutionReq request parameter, while the taskType() method is used to identify the task types supported by the channel. Each task type (such as SQL task, HTTP task) can have independent instantiation logic by implementing this interface.

[0053] TaskChannelFactory.class serves as the centralized management and scheduling factory for task channels. Internally, it maintains a list of all registered TaskChannel subclass instances. When a task execution request is received, the factory can quickly locate and return the corresponding TaskChannel instance based on the task type. This instance then completes the creation of the specific task object, thereby achieving decoupling and dynamic mapping between task type and task creation logic.

[0054] Different task components implement different logic for the abstract class, which can improve the flexibility and scalability of the code.

[0055] After receiving the scheduled task dispatched by the master, the worker-server first obtains a TaskChannel instance through taskChannelFactory based on taskType, then creates a task object from that instance, and finally executes task.execute() to complete the scheduled task.

[0056] In this embodiment, the drag-and-drop visual operation lowers the barrier to workflow configuration, allowing users to define tasks without complex programming; comprehensive storage of task information ensures the reusability and continuity of the workflow, allowing users to quickly restore the previous configuration state when they re-enter; and the custom expansion mechanism of the scheduling task component meets the needs of diverse task types in different business scenarios, enhancing the system's flexibility and scalability.

[0057] In S2, Worker nodes with a ZooKeeper center jump status of "normal" are selected, and node weights are calculated based on a dynamic load balancing algorithm. Tasks are then distributed to the Worker node with the highest weight for execution, achieving efficient and balanced scheduling of distributed workflow tasks.

[0058] Within the master-server, a dynamic task allocation algorithm based on worker-server load balancing is used for task dispatching.

[0059] When the worker-server starts, it supports specifying the normal range of CPU, memory, and disk usage, as well as the node's weight value in the configuration file. It also sends a heartbeat to ZooKeeper every second. The heartbeat contains: machine resources (usable CPU percentage, memory percentage, disk percentage), the number of scheduled tasks running on the node, and the node status. The node status is BUSY if the number of scheduled tasks waiting to be executed is greater than 0 or the CPU, memory, and disk usage percentages exceed the normal range; otherwise, it is normal.

[0060] The master-server obtains the worker-server's heartbeat from ZK every 10 seconds and filters out nodes whose status is "normal".

[0061] Then calculate the worker-server weights. The calculation formula is:

[0062] ;

[0063] in, Here are the weighting coefficients: A is CPU utilization, B is memory utilization, C is disk utilization, and D is the number of scheduled tasks.

[0064] For example, A is 20, B is 20, C is 50, and D is 10. Finally, the worker-server with the highest weight is selected, and the scheduling task is dispatched to that node for execution.

[0065] In this embodiment, the dynamic load balancing algorithm comprehensively considers various resource usage conditions and task execution numbers of the worker-server, effectively avoiding situations where a certain worker-server node is overloaded but is still assigned tasks. This achieves reasonable distribution of pressure among worker-server nodes, improves resource utilization and task execution efficiency, and ensures the stability of distributed workflow scheduling.

[0066] In S3, when a Worker node fails, the ZooKeeper node deletion event is monitored to identify the IP and port of the failed Worker; the status of unterminated tasks on the failed node is marked as requiring fault tolerance and reallocation, and combined with the failure retry strategy, the high reliability of task execution is ensured.

[0067] This embodiment utilizes the ZooKeeper watch mechanism to achieve worker-server downtime fault tolerance.

[0068] When the worker-server project starts, it registers nodes with ZooKeeper. The node path is / node / worker / worker-server ip:port;

[0069] When the master-server project starts, it registers a node with ZooKeeper. The node path is / node / master / master-server ip:port. It also registers a listener for events on the / node path, which can listen for the creation, deletion, and modification of nodes under the / node path.

[0070] When the worker-server service fails, ZooKeeper will delete the temporary node registered by the failed service because it has not reported heartbeats to ZooKeeper for a long time. At this time, the master-server service will listen for the worker-server node deletion event and obtain the IP and port of the failed worker-server service from the node deletion event.

[0071] Subsequently, the master-server service retrieves the scheduled task instances that have been assigned to the worker-server and are not in a terminated state within the workflow instance that is currently running in this service. It changes the status of these scheduled task instances to NEED_FAILOVER (fault tolerance is required) and puts them back into the list of task instances to be dispatched, waiting to be reassigned to other normal worker-servers for execution.

[0072] In addition, the system includes a failure retry policy, where task failure retry is task-level. The number of retries can be set when defining the scheduled task in the workflow canvas. When a task fails, it will try to run the task up to the set number of times.

[0073] In this embodiment, ZooKeeper's watch mechanism can detect worker-server node failures in a timely manner, ensuring timely fault handling; tasks that have not yet terminated on the faulty node are reassigned, preventing tasks from being interrupted or lost due to node failure; the task failure retry strategy further increases the probability of successful task execution. These multiple safeguards make the distributed workflow task scheduling highly reliable.

[0074] In S4, when the Master node fails, the surviving Master takes over the workflow instance of the failed Master based on the slot allocation mechanism; updates the task reporting address in the Worker to the current Master, and redistributes unfinished tasks. Combined with the decentralized architecture and other failure retry strategies, the system achieves high availability.

[0075] This embodiment adopts a decentralized approach. The master-server and worker-server are registered in ZooKeeper and report heartbeats periodically. The master-server processes its own workflow based on slots (resource slots) and distributed locks, and distributes tasks to the worker-servers through a dynamic task allocation algorithm, thus achieving a decentralized master-server cluster and worker-server cluster.

[0076] The master-server service periodically retrieves a list of live master-servers from ZooKeeper and sorts them according to their startup time. After sorting, the service's position number in the list is the slot for this node. When the result of modulo operation of the workflow ID with the total number of live master-server nodes is equal to the slot number of this node, it means that the workflow to be run will be processed and dispatched by this master-server node.

[0077] When the master-server service fails, ZooKeeper will delete the temporary node registered by the failed service because it has not reported heartbeats to ZooKeeper for a long time. At this time, a normal master-server service (called master-server A) will listen for the deletion event of the failed master-server node.

[0078] Master-server A uses the IP address and port of the failed master-server service as the key to acquire a distributed lock. Then, it retrieves the workflow instance that was processed by the failed master-server service and is in an unfinished state from the database table, and changes the master-server address of the workflow instance to the IP address and port of this service. At the same time, it queries the scheduling task instance associated with the workflow instance. If the scheduling task instance is in an unfinished state, it sends a notification to the worker server that is processing the scheduling task, updating the master-server IP address and port recorded in the scheduling task context within the worker server. Subsequently, the worker server will communicate with the new master-server to report the task execution status and dispatch the unprocessed scheduling tasks in the workflow according to the DAG execution order. After that, master-server A releases the distributed lock.

[0079] In addition, the failure retry strategy also includes process failure recovery and process failure rerun, both of which are at the workflow level. The workflow instance management page provides failure recovery and rerun buttons respectively. Process failure recovery needs to be run manually. After running, it will resume the execution of the workflow instance from the failed scheduled task. Process failure rerun also needs to be run manually. After running, it will rerun the workflow instance from the first scheduled task.

[0080] In this embodiment, the decentralized architecture avoids the single point of failure caused by the existence of a single "manager" node; based on the slot allocation mechanism and distributed lock, it ensures that the surviving Master can take over the workflow instances of the failed Master in an orderly and accurate manner, thus guaranteeing the continuity of the workflow; updating the task reporting address in the Worker and re-dispatching the incomplete tasks allows the workflow tasks to continue to execute under the management of the new Master node; the process failure recovery and rerun strategy provides users with the means to deal with workflow-level failures, improves the usability and fault tolerance of the system, and ensures the high availability of the system as a whole.

[0081] This specific embodiment supports drag-and-drop task definition and dependency configuration through a visual canvas, and achieves intuitive orchestration by combining coordinates and relational storage, solving the complex workflow maintenance problems brought about by traditional code configuration. An abstract class and interface system is designed to allow flexible expansion of task types such as SQL and HTTP, adapting to diverse business scenarios without modifying the underlying logic. A dynamic load balancing algorithm comprehensively considers the weights of CPU, memory, disk, and task volume calculation nodes to accurately allocate tasks and avoid resource imbalance, improving overall execution efficiency. Relying on the ZooKeeper monitoring mechanism and distributed locks, it achieves rapid identification of Worker and Master node failures, task status marking, and reallocation. Combined with a multi-layered retry strategy to reduce recovery latency, and with a decentralized architecture and slot allocation mechanism to eliminate single points of failure, it comprehensively ensures high system availability, effectively overcoming the bottlenecks of traditional solutions in visualization, scalability, load balancing, and fault tolerance.

[0082] Example 2

[0083] This embodiment provides a distributed workflow task scheduling system, including:

[0084] The visualization definition module is used to define scheduling task nodes and their dependencies by dragging and dropping on a visual canvas, and to store task node information, inter-node dependencies, and canvas coordinates.

[0085] The load balancing distribution module is used to filter Worker nodes whose ZooKeeper center hop status is normal, calculate node weights based on a dynamic load balancing algorithm, and distribute tasks to the Worker node with the highest weight for execution.

[0086] The Worker fault tolerance module is used to listen for ZooKeeper node deletion events when a Worker node fails, identify the IP and port of the failed Worker, mark the status of unterminated tasks on the failed node as requiring fault tolerance and reallocate them;

[0087] The Master high availability module is used to take over the workflow instance of the failed Master based on the slot allocation mechanism when the Master node fails; update the task reporting address in the Worker to the current Master, and re-dispatch the unfinished tasks.

[0088] Example 3

[0089] This embodiment provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of a distributed workflow task scheduling method as described in Embodiment 1 above.

[0090] Example 4

[0091] This embodiment provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements the steps in the distributed workflow task scheduling method described in Embodiment 1 above.

[0092] The steps or modules involved in Embodiments 2 to 4 above correspond to those in Embodiment 1. For specific implementation details, please refer to the relevant description section of Embodiment 1. The term "computer-readable storage medium" should be understood as a single medium or multiple media including one or more instruction sets; it should also be understood as including any medium capable of storing, encoding, or carrying an instruction set for execution by a processor and enabling the processor to perform any of the methods in this invention.

[0093] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A distributed workflow task scheduling method, characterized in that, include: Define scheduling task nodes and their dependencies by dragging and dropping on a visual canvas, and store task node information, inter-node dependencies, and canvas coordinates; Filter the Worker nodes with the ZooKeeper centerbeat status as normal, calculate the node weight based on the dynamic load balancing algorithm, and distribute the task to the Worker node with the highest weight for execution; The formula for calculating node weights in the dynamic load balancing algorithm is as follows: ； in, Here are the weighting coefficients: A is CPU utilization, B is memory utilization, C is disk utilization, and D is the number of scheduled tasks. When a Worker node fails, listen for ZooKeeper node deletion events to identify the IP address and port of the failed Worker; mark any unterminated tasks on the failed node as requiring fault tolerance and reallocation; When the Master node fails, the surviving Master takes over the workflow instance of the failed Master based on the slot allocation mechanism; updates the task reporting address in the Worker to the current Master, and re-dispatches the unfinished tasks; The takeover process in the event of a Master node failure specifically includes: Surviving Master nodes listen for node deletion events in the path used to register Master nodes in ZooKeeper to identify faulty Master nodes; The distributed lock is obtained using the network address of the faulty Master node as the key; The management node address of the workflow instance that was originally handled by the faulty Master node and has not yet ended is changed to the currently active Master node; The worker node is notified to update its task reporting address to the currently active master node, and the current master node then reassigns the unfinished tasks in the workflow instance.

2. The distributed workflow task scheduling method as described in claim 1, characterized in that, The task node information includes the task name, task type, and task parameters; the dependency relationship between nodes includes the predecessor and successor node information of the current node; the canvas coordinates are the coordinates of all nodes in the canvas.

3. The distributed workflow task scheduling method as described in claim 1, characterized in that, Running the scheduled task includes: Based on the task type of the scheduled task, obtain the corresponding TaskChannel instance through the TaskChannelFactory factory class; Call the createTask() method of the TaskChannel instance to generate a task object of the AbstractTask subclass; Execute the execute() method of the task object to run the business logic of the scheduled task.

4. The distributed workflow task scheduling method as described in claim 1, characterized in that, The reassignment in the event of a Worker node failure specifically includes: The surviving Master node listens for node deletion events under the path used to register Worker nodes in ZooKeeper and identifies the network address of the failed Worker node. Mark the status of task instances that have been assigned to the faulty Worker node and have not been terminated as requiring fault tolerance; The task instances marked as requiring fault tolerance are re-added to the allocation queue so that they can be assigned to other surviving Worker nodes for execution.

5. The distributed workflow task scheduling method as described in claim 1, characterized in that, It also includes multi-level failure handling, which includes task-level retry, workflow-level recovery, and workflow-level rerun. The task-level retry is to preset the number of automatic retries, and to retry immediately after a task fails until the limit is reached; The workflow level is restored to continue running the incomplete DAG branch from the failed node after manual triggering; The workflow-level rerun is a process that restarts the entire workflow from the first node after being manually triggered.

6. A distributed workflow task scheduling system, characterized in that, include: The visualization definition module is used to define scheduling task nodes and their dependencies by dragging and dropping on a visual canvas, and to store task node information, inter-node dependencies, and canvas coordinates. The load balancing distribution module is used to filter Worker nodes whose ZooKeeper center hop status is normal, calculate node weights based on a dynamic load balancing algorithm, and distribute tasks to the Worker node with the highest weight for execution. The formula for calculating node weights in the dynamic load balancing algorithm is as follows: ； in, Here are the weighting coefficients: A is CPU utilization, B is memory utilization, C is disk utilization, and D is the number of scheduled tasks. The Worker fault tolerance module is used to listen for ZooKeeper node deletion events when a Worker node fails, identify the IP and port of the failed Worker, mark the status of unterminated tasks on the failed node as requiring fault tolerance and reallocate them; The Master high availability module is used to take over the workflow instance of the failed Master based on the slot allocation mechanism when the Master node fails; update the task reporting address in the Worker to the current Master, and re-dispatch unfinished tasks; The takeover process in the event of a Master node failure specifically includes: Surviving Master nodes listen for node deletion events in the path used to register Master nodes in ZooKeeper to identify faulty Master nodes; The distributed lock is obtained using the network address of the faulty Master node as the key; The management node address of the workflow instance that was originally handled by the faulty Master node and has not yet ended is changed to the currently active Master node; The worker node is notified to update its task reporting address to the currently active master node, and the current master node then reassigns the unfinished tasks in the workflow instance.

7. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the steps in the distributed workflow task scheduling method as described in any one of claims 1-5.

8. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps in the distributed workflow task scheduling method as described in any one of claims 1-5.

Images