Task scheduling method and device for distributed cluster, equipment and medium

Abstract

The embodiment of the invention relates to a task scheduling method and device for a distributed cluster, equipment and a medium, and the method comprises the steps: responding to a monitored to-be-executed target task event in the distributed cluster, determining a target event type to which the target task event belongs from a plurality of preset task event types, determining a target type scheduler corresponding to the target event type from multiple types of task schedulers; wherein the multiple types of task schedulers and the multiple types of task event types have a one-to-one correspondence relationship; determining a target node for executing the target task event from the nodes of the distributed cluster based on the target type scheduler; and executing the target task event through the target node. According to the embodiment of the invention, corresponding types of schedulers can be respectively set for various task event types, and task scheduling is performed in a targeted manner by adopting an event-driven manner, so that the reliability of task scheduling is ensured, the universality is relatively high, and the task scheduling method and device are relatively well suitable for complex and diversified business scenes.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to a task scheduling method, apparatus, device and medium for a distributed cluster. Background Technology

[0002] A distributed cluster consists of multiple computers (nodes). In this distributed environment, task scheduling is a critical operation, which distributes tasks to the nodes in the cluster for execution. However, the inventors found through research that the task scheduling methods used in existing distributed clusters lack versatility and still need improvement. Summary of the Invention

[0003] To solve the above-mentioned technical problems, or at least partially solve them, this disclosure provides a task scheduling method, apparatus, device, and medium for distributed clusters.

[0004] This disclosure provides a task scheduling method for a distributed cluster. The method includes: in response to detecting a target task event to be executed in the distributed cluster, determining a target event type from a preset variety of task event types, and determining a target type scheduler corresponding to the target event type from a variety of task schedulers; wherein the variety of task schedulers and the variety of task event types have a one-to-one correspondence; based on the target type scheduler, determining a target node from the nodes of the distributed cluster for executing the target task event; and executing the target task event through the target node.

[0005] Optionally, determining the target node for executing the target task event from the nodes of the distributed cluster based on the target type scheduler includes: if the primary scheduling node in the distributed cluster is not faulty, determining the target node for executing the task event from the nodes of the distributed cluster using the target type scheduler on the primary scheduling node; if the primary scheduling node in the distributed cluster is faulty, determining the target scheduling node from the backup scheduling nodes in the distributed cluster, and determining the target node for executing the task event from the nodes of the distributed cluster using the target type scheduler on the target scheduling node.

[0006] Optionally, the distributed cluster has at least one backup scheduling node, and the primary scheduling node and at least one backup scheduling node of the distributed cluster are distributed in at least two data centers.

[0007] Optionally, determining the target node for executing the target task event from the nodes of the distributed cluster includes: determining the target node for executing the target task event from the nodes of the distributed cluster based on a preset task distribution strategy; wherein the task distribution strategy includes at least one or more of the following: a load balancing strategy, a node selection strategy based on node health status.

[0008] Optionally, executing the target task event through the target node includes: executing the target task event through a target type executor in the target node that corresponds to the target event type; wherein the target node is provided with multiple types of task executors, and the multiple types of task executors have a one-to-one correspondence with the multiple types of task event.

[0009] Optionally, the method further includes: delivering the target task event to a preset task scheduling event queue through the target type scheduler; and executing the target task event through the target type executor corresponding to the target event type in the target node, which includes: pulling the target task event from the task scheduling event queue and executing the target task event through the target type executor corresponding to the target event type in the target node.

[0010] Optionally, the method further includes: in response to a failure of the target node, migrating the target task event to a healthy node in the distributed cluster for processing.

[0011] Optionally, the method further includes: managing the node resources of the distributed cluster based on a lease mechanism.

[0012] Optionally, the distributed cluster includes a central node and edge nodes.

[0013] This disclosure also provides a task scheduling device for a distributed cluster, comprising: a scheduler determination module, configured to, in response to detecting a target task event to be executed in the distributed cluster, determine the target event type to which the target task event belongs from a preset variety of task event types, and determine a target type scheduler corresponding to the target event type from a variety of task schedulers; wherein the variety of task schedulers and the variety of task event types have a one-to-one correspondence; a node determination module, configured to, based on the target type scheduler, determine a target node for executing the target task event from the nodes of the distributed cluster; wherein the nodes of the distributed cluster include central nodes and edge nodes; and an event execution module, configured to execute the target task event through the target node.

[0014] This disclosure also provides an electronic device, comprising: a storage device storing a computer program thereon; and a processing device for executing the computer program in the storage device to implement the task scheduling method for a distributed cluster as provided in this disclosure.

[0015] This disclosure also provides a computer-readable storage medium storing a computer program for executing a task scheduling method for a distributed cluster as provided in this disclosure.

[0016] This disclosure also provides a computer program product, including a computer program that, when executed by a processor, implements the task scheduling method for a distributed cluster as provided in this disclosure.

[0017] The technical solution provided in this disclosure can determine the target event type from a set of preset task event types when a target task event to be executed is detected in a distributed cluster. It also determines the target type scheduler corresponding to the target event type from a set of task schedulers, with a one-to-one correspondence between the various task schedulers and task event types. Based on the target type scheduler, a target node for executing the target task event can be determined from the nodes of the distributed cluster, and then the target task event can be executed through the target node. Related technologies typically use a fixed task scheduler to determine if a trigger time has been reached, and then execute the scheduled task upon reaching the trigger time. This disclosure fully considers that the methods provided by related technologies can only meet basic distributed scheduled task requirements, have strong limitations, and are applicable to only a single scenario. Therefore, the above-mentioned method can set corresponding schedulers for various task event types and use an event-driven approach to perform targeted task scheduling, ensuring the reliability of task scheduling, and has strong versatility, making it well-suited for complex and diverse business scenarios.

[0018] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0019] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure.

[0020] To more clearly illustrate the technical solutions in the embodiments of this disclosure or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 A flowchart illustrating a task scheduling method for a distributed cluster provided in this embodiment of the disclosure; Figure 2 This is a schematic diagram of the architecture of a distributed task scheduling system provided in an embodiment of the present disclosure; Figure 3 This is a schematic diagram of a distributed task scheduling process provided in an embodiment of the present disclosure; Figure 4 This is a schematic diagram of a distributed task scheduling process provided in an embodiment of the present disclosure; Figure 5 A schematic diagram of the layout of a scheduling node provided in an embodiment of this disclosure; Figure 6 This is a schematic diagram of a distributed task scheduling process provided in an embodiment of the present disclosure; Figure 7 This is a schematic diagram of the structure of a task scheduling device for a distributed cluster provided in an embodiment of the present disclosure; Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure. Detailed Implementation

[0022] To better understand the above-mentioned objectives, features, and advantages of this disclosure, the solutions disclosed herein will be further described below. It should be noted that, unless otherwise specified, the embodiments and features described herein can be combined with each other.

[0023] It is understood that before using the technical solutions disclosed in the various embodiments of this disclosure, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this disclosure in an appropriate manner in accordance with relevant laws and regulations, and user authorization should be obtained.

[0024] For example, upon receiving a user's active request, a prompt message is sent to the user to explicitly inform them that the requested operation will require the acquisition and use of the user's personal information. This allows the user to independently choose whether to provide personal information to the software or hardware, such as the electronic device, application, server, or storage medium performing the operations of this disclosed technical solution, based on the prompt message.

[0025] As an optional but non-limiting implementation, in response to a user's active request, sending a prompt message to the user can be done via a pop-up window, where the prompt message can be presented in text format. Furthermore, the pop-up window can also include a selection control allowing the user to choose "agree" or "disagree" to provide personal information to the electronic device.

[0026] It is understood that the above notification and user authorization process are merely illustrative and do not constitute a limitation on the implementation of this disclosure. Other methods that comply with relevant laws and regulations may also be applied to the implementation of this disclosure.

[0027] Numerous specific details are set forth in the following description in order to provide a full understanding of this disclosure, but this disclosure may also be implemented in other ways different from those described herein; obviously, the embodiments in the specification are only some, and not all, of the embodiments of this disclosure.

[0028] A distributed task scheduling system is a system that runs on (or is part of) a cluster. It is responsible for receiving task requests, allocating resources, determining which node a task should execute on, and monitoring its execution status. It serves as the decision-making and coordination center for task execution. Traditional task scheduling systems are primarily designed for cloud computing center architectures, typically assuming centralized and homogeneous computing resources and stable and reliable network connections. However, with the development of the Internet of Things (IoT) and computer technology, computing demands have exploded. Traditional cloud computing architectures can no longer meet the needs of all application scenarios, especially in low-latency, high-real-time applications. Therefore, cloud-edge collaborative architectures have emerged, combining the powerful computing capabilities of cloud computing centers with the low-latency characteristics of edge devices to form a new computing model. Understandably, in a cloud-edge collaborative environment, task scheduling systems face complex operating environments and business scenarios. Computing resources are widely distributed across the cloud and edge, and edge devices are characterized by strong heterogeneity and unstable network connections. These characteristics make it difficult to directly apply traditional task scheduling methods.

[0029] Existing distributed task scheduling systems are primarily designed for timed tasks in cloud computing centers. Their core scheduling process is as follows: 1) Task registration: Users register tasks and triggers through a unified scheduler, and metadata is persisted to the task storage. 2) Trigger detection: The scheduler's internal threads continuously scan triggers to determine if the trigger time has arrived. 3) Task execution: When a trigger is triggered, the scheduler obtains a thread from the thread pool, instantiates the task, and executes it. 4) Distributed coordination: Task preemption in a distributed environment is achieved based on database locks (such as row locks), preventing the same task from being executed repeatedly on multiple nodes. The inventors have found that while the above scheduling process can meet basic distributed timed task requirements, it suffers from problems such as limited task types, lack of cloud-edge collaboration, and insufficient high availability in cloud computing environments and cloud-edge collaboration scenarios. Specifically, regarding the issue of limited task types, related task scheduling systems mainly support timed tasks and cannot handle complex business scenarios such as batch computing and graph computing tasks. This limitation is significant, requiring business systems to implement complex logic themselves, resulting in high development costs. Regarding the lack of cloud-edge collaboration, related task scheduling systems are primarily based on cloud computing center architecture, failing to consider the network instability of edge nodes, resulting in poor interaction between edge nodes and the cloud scheduling center. Regarding insufficient high availability, related task scheduling systems rely on manual switching of master nodes by the configuration center, have weak cross-data center deployment capabilities, and pose a high risk of task loss when the nodes used to execute tasks fail. To improve at least one of these problems, embodiments of this disclosure provide a task scheduling method, apparatus, device, and medium for a distributed cluster, which are described in detail below.

[0030] Figure 1 This is a flowchart illustrating a task scheduling method for a distributed cluster provided in an embodiment of this disclosure. This method can be executed by a task scheduling device for the distributed cluster, which can be implemented in software and / or hardware, and is generally integrated into an electronic device. Figure 1 As shown, the method mainly includes the following steps S102 to S106: Step S102: In response to detecting a target task event to be executed in the distributed cluster, determine the target event type to which the target task event belongs from a variety of preset task event types, and determine the target type scheduler corresponding to the target event type from a variety of task schedulers; wherein, the various types of task schedulers have a one-to-one correspondence with the various task event types, or it can be said that the various types of task schedulers have a one-to-one correspondence with the various task event types.

[0031] Any task event to be executed in a distributed cluster can be used as a target task event. In practical applications, users can directly initiate task requests through a client. The task metadata will change accordingly, and the change in task metadata will trigger the generation of corresponding task events. All of these can be used as task events to be executed. Task events can be newly created events or task change events; there are no restrictions here. In some specific examples, the above client can be a single client or multiple different types of clients, such as cloud service clients, edge node clients, and OpenAPI (Open Application Programming Interface) clients. Different types of clients can be used to selectively receive different types of task requests, such as receiving task requests related to cloud services or task requests related to edge node services.

[0032] This disclosure does not limit the types of task events. Exemplarily, various task event types include, but are not limited to, scheduled tasks, one-time tasks, graph computation tasks, and batch computation tasks. Scheduled tasks are tasks that need to be executed according to a preset trigger time, specifically periodic tasks. One-time tasks are tasks that only need to be executed once. Graph computation tasks can be tasks used to execute directed acyclic graphs, and batch computation tasks can be tasks that process data in batches, including but not limited to mapping and reduction tasks. Correspondingly, various types of task schedulers include, but are not limited to, scheduled task schedulers, one-time task schedulers, graph task schedulers, and batch task schedulers. There is a one-to-one correspondence between the above task event types and the types of task schedulers. For example, a scheduled task scheduler schedules scheduled tasks, a one-time task scheduler schedules one-time tasks, a graph task scheduler schedules computation tasks related to graph structures, and a batch task scheduler schedules batch computation tasks. These are merely examples; in practical applications, other types of tasks and corresponding task schedulers may also be included, which will not be elaborated upon here.

[0033] Step S104: Based on the target type scheduler, determine the target node from the nodes of the distributed cluster to execute the target task event.

[0034] The distributed cluster provided in this disclosure includes a central cluster (also known as a cloud cluster) and an edge cluster. The central cluster includes central nodes, and the edge cluster includes edge nodes. That is, the nodes of the distributed cluster include both central nodes and edge nodes. The distributed cluster provided in this disclosure can be implemented using a cloud-edge collaborative architecture. Cloud-edge collaboration refers to the collaborative allocation of tasks, collaborative processing of data, and collaborative scheduling of resources between the cloud and the edge under a unified scheduling and management framework. The cloud includes, but is not limited to, data centers and public cloud platforms. Cloud computing has powerful computing power, storage capabilities, and a rich service ecosystem. The edge includes, but is not limited to, edge servers and other electronic devices such as computers (i.e., edge nodes) that are close to the data source or end user. Edge computing has low latency, high bandwidth, and localized processing capabilities. Through cloud-edge collaboration, the advantages of both can be fully utilized to achieve resource complementarity, task collaboration, and efficient data processing.

[0035] In this embodiment of the disclosure, the target node for executing the target task event can be determined from the central node and the edge nodes. Alternatively, the advantages of the edge nodes can be fully utilized, and the target node for executing the target task event can be determined only from the edge nodes. The specific settings can be flexibly configured according to the business scenario, and no restrictions are imposed here. Step S106: Execute the target task event through the target node. In practice, the target task event can be executed through the task executor set on the target node.

[0036] In related technologies, a fixed task scheduler is typically used to determine whether the trigger time has been reached, and the scheduled task is executed after the trigger time is reached. The embodiments of this disclosure fully consider that the methods provided by related technologies can only meet the basic requirements of distributed scheduled tasks, which are limited and have a single applicable scenario. Therefore, the above-mentioned method can set up corresponding schedulers for various task event types and use an event-driven approach to perform targeted task scheduling, ensuring the reliability of task scheduling. It can be well applied to complex and diverse business scenarios, and various types of tasks can be uniformly scheduled based on the above scheduling logic, which has strong versatility. Business systems do not need to develop their own scheduling logic for different types of tasks, which can effectively reduce development costs.

[0037] In some implementation examples, the step of determining the target node for executing the target task event from the nodes of the distributed cluster based on the target type scheduler includes: if the primary scheduler node in the distributed cluster is not faulty, the target node for executing the task event is determined from the nodes of the distributed cluster through the target type scheduler on the primary scheduler node; if the primary scheduler node in the distributed cluster fails, the target scheduler node is determined from the backup scheduler nodes in the distributed cluster, and the target scheduler node on the target scheduler node determines the target node for executing the task event from the nodes of the distributed cluster. In practical applications, a primary scheduler node can be elected through a primary node election mechanism to enable timely fault migration when the primary scheduler node fails. Task scheduling is then implemented by the target scheduler node elected from the backup scheduler nodes, effectively ensuring the continuity and high availability of the scheduling service and preventing the entire system scheduling from paralyzing due to the failure of the primary scheduler node. In some implementation examples, the distributed cluster has at least one backup scheduling node, and the primary scheduling node and at least one backup scheduling node are distributed across at least two data centers. The data center where the central node is located can be called the central data center; the data center where the edge nodes are located can be called the edge data center. In practical applications, both the primary and backup scheduling nodes are located in the central data center. Specifically, the primary and backup scheduling nodes are located in different central data centers, and there can be one or more backup scheduling nodes, which can be located in multiple different central data centers. Both the central and edge nodes can serve as worker nodes for executing tasks. The central and edge data centers of the distributed cluster can also be uniformly regarded as worker data centers. In this unified architecture, the scheduling node located in the central data center can normally schedule edge nodes in the edge data centers, making full use of edge nodes and achieving high availability. By leveraging "primary-backup scheduling" and "multi-data center redundancy," disaster recovery and fault tolerance can be effectively achieved, comprehensively ensuring the high availability of the system. It also enables better cross-data center task scheduling. Nodes used to execute tasks can be deployed in the central or edge data centers, achieving a unified architecture and effectively reducing the cost of cloud-edge collaborative management.

[0038] In some implementation examples, the aforementioned determination of the target node for executing the target task event from the nodes of the distributed cluster includes: determining the target node for executing the target task event from the nodes of the distributed cluster based on a preset task distribution strategy; wherein, the task distribution strategy includes at least one or more of the following: a load balancing strategy and a node selection strategy based on node health status. The load balancing strategy refers to using a specific algorithm to reasonably distribute the tasks to be processed across multiple nodes to optimize resource utilization, maximize throughput, minimize response time, and avoid single-point overload; the specific algorithm includes, but is not limited to, round-robin, least connections, hash algorithm, dynamic feedback, etc. The node selection strategy based on node health status refers to checking the health status of candidate nodes before allocating tasks, such as determining whether the node is alive, whether resources are sufficient, and whether the service is normal, and only assigning tasks to healthy nodes that pass the health check, and promptly isolating and recovering nodes in case of abnormality. Using both load balancing and node selection strategies based on node health status helps optimize resource utilization and improves the reliability of task execution.

[0039] In some implementation examples, the above-mentioned execution of target task events through target nodes includes: executing the target task event through a target type executor in the target node corresponding to the target event type; wherein, the target node is configured with multiple types of task executors, and there is a one-to-one correspondence between the multiple types of task executors and the multiple task event types; in other words, there is a correspondence between the type of task executor and the type of task event. Through this method, different types of task events can be processed in a targeted manner using different types of task executors, enabling reliable scheduling and execution of different types of tasks in complex business scenarios.

[0040] In some specific examples, the above method also includes: delivering target task events to a preset task scheduling event queue via a target type scheduler; and executing the target task events via the target type executor corresponding to the target event type in the target node, including: pulling target task events from the task scheduling event queue and executing them via the target type executor corresponding to the target event type in the target node. By setting up a task scheduling event queue, and combining it with a push-pull mode, the task scheduler can deliver task events to the corresponding type of executor, or the task executor can actively pull tasks. This event-driven mode enables multiple types of tasks to be flexibly scheduled and executed under a unified architecture. By setting up different types of task schedulers, event queues, and different types of task executors, the components in the distributed scheduling system can interact loosely through events, improving the system's scalability and facilitating the addition of new task types or optimization of task execution logic.

[0041] In some specific examples, the above method further includes: in response to a failure of the target node, migrating the target task event to a healthy node in the distributed cluster for processing. The fault migration method provided in this disclosure can automatically migrate the target task event to a healthy node in the distributed cluster when the target node used to execute the target task event fails. In specific implementation, the distributed cluster provided in this disclosure can equip each node with a health check function by setting up a health check component, continuously monitoring whether each node's own operating status is normal, such as monitoring resource usage, service response speed, and whether it is disconnected. When an abnormal node operating status is detected, it is determined that the node has failed, and the node balancer can be triggered to initiate a task migration request to the task scheduler, and simultaneously execute the task migration operation to transfer unfinished or pending tasks on the failed node to other healthy nodes, ensuring that task execution is not affected by node failure, thereby achieving better task migration. In summary, the above methods can automatically migrate tasks when the nodes used to execute tasks fail, ensuring that task execution is not affected by node failure and avoiding task loss. This can effectively improve the high availability and fault tolerance of the system, and can be well applied to scenarios where edge nodes are used to execute tasks, even when the edge node network is unstable.

[0042] In some specific examples, the above method also includes managing node resources in a distributed cluster based on a lease mechanism, such as releasing expired resources. Specifically, the master node of the central cluster of the distributed cluster can manage node resources based on a lease mechanism. Node resources include, but are not limited to, resources of edge nodes, thereby enabling the timely release of expired edge resources and achieving reasonable allocation of edge resources. Here, a lease is an authorization certificate with a time limit. The lease mechanism means that resource managers such as the master node issue resources to resource users such as worker nodes according to the lease, allowing them to exclusively occupy or use a certain resource during the lease's validity period. If the lease expires and is not renewed, the authorization automatically expires, and the expired resource can be reclaimed or reallocated. This approach helps to automatically detect whether nodes are failing and release expired resources in a timely manner, and also helps to improve system fault tolerance and availability.

[0043] The task scheduling method provided in this disclosure can be executed by hardware and / or software, and is applicable to task scheduling systems. This task scheduling system is also well-suited for cloud-edge collaborative architectures. For ease of understanding, this disclosure provides a distributed task scheduling system applicable to the above task scheduling method; details can be found in [link to relevant documentation]. Figure 2The diagram illustrates the architecture of a distributed task scheduling system. It roughly divides the system into a client layer, an event-driven layer, a unified scheduling framework layer, a cloud-edge collaboration layer, a high-availability layer, and an observability layer. Each layer can contain multiple functional components, which can be implemented through software and / or hardware. The following provides a illustrative explanation of each layer: The client layer can be configured with one or more clients, such as cloud business clients, edge node clients, and OpenAPI clients, serving as the entry point for the system to interact with external business systems, edge nodes, and third-party systems. These clients are used to receive user cloud business task requests, edge node task requests, and task requests accessed through the OpenAPI interface, and generate corresponding task events.

[0044] The event-driven layer can trigger task scheduling and execution in an event-driven manner. Specifically, distributed task scheduling systems in related technologies mainly use a passive scanning method, where the scheduler's internal thread cyclically scans triggers to determine whether the task's trigger time has arrived. Figure 2 The task scheduling system in this system achieves a fundamental shift from passive scanning to proactive response through components such as event dispatchers, event listeners, and event queues set up in the event-driven layer. Specifically, the event-driven layer can generate task events when task metadata changes; the event bus can efficiently transmit task events based on a publish-subscribe pattern; event listeners can monitor task events to be executed, and the event dispatcher can distribute these events to the task scheduler. This event-driven layer can trigger task scheduling using an event-driven pattern. Compared to conventional passive scanning methods, it can execute on demand, avoid unnecessary overhead, and respond quickly once an event is detected, triggering subsequent task scheduling processes with strong immediacy.

[0045] The unified scheduling framework layer enables unified management and scheduling of different types of tasks. Specifically, it can include a task metadata management component, a scheduled task scheduler, a one-time task scheduler, a batch task scheduler, a graph task scheduler, and a task executor management component. The task metadata management component manages the metadata information of tasks; other types of task schedulers can obtain the required task metadata through this component. The scheduled task scheduler schedules timed tasks; the one-time task scheduler schedules one-time tasks; the batch task scheduler schedules batch computation tasks; the graph task scheduler schedules tasks related to graph structures; and the task executor management component manages the lifecycle and resource allocation of task executors.

[0046] The cloud-edge collaboration layer can be configured with components such as edge task executors and components for controlling task distribution based on cloud-edge task distribution strategies. Additionally, it can include API servers and state synchronization servers. Figure 2The details are not listed individually. The API server serves as the core hub for cloud-edge interaction, enabling cross-environment data synchronization. The state synchronization server specifically implements bidirectional event-driven command issuance and state callback, ensuring synchronization of instructions and states between the cloud and edge nodes. In the cloud-edge collaboration layer, the task scheduler can schedule nodes based on cloud-edge task distribution strategies. Both edge and cloud nodes support the same task types, achieving unified scheduling of different task types. Furthermore, the cloud-edge collaboration layer can manage edge resources based on a lease mechanism, automatically releasing expired resources and achieving edge fault tolerance. Through the aforementioned cloud-edge collaboration layer, a good collaborative working effect between the cloud and the edge can be achieved. It should also be noted that the cloud-edge collaboration architecture provided in this embodiment primarily utilizes edge nodes to execute tasks; therefore, the focus is on the edge task executor within the cloud-edge collaboration layer. In practical applications, the central node can also be configured with an executor, which should not be considered a limitation.

[0047] The high availability layer ensures the high availability of the distributed task scheduling system through scheduler failure migration, executor failure migration, executor leases, and master node election mechanisms. In specific implementations, a multi-location data center combined with a primary / standby scheduling mode can be used to guarantee availability. Edge data centers can be connected as ordinary data centers, unifying the cloud and edge architecture and reducing management costs. Furthermore, the master node election mechanism can automatically achieve primary / standby switching without manual intervention. A distributed storage cluster can also be used to share the state of the primary and standby schedulers. Task migration can be triggered when an executor fails, and a lease mechanism can be used to manage cluster nodes, such as managing worker nodes with executors configured. Through this high availability layer, the distributed task scheduling system can be effectively guaranteed to have high availability.

[0048] The observability layer, through components such as log collection, log backhaul, tracing, and monitoring / alerting, provides a good foundation for observing data in the distributed task scheduling system. The log collection component gathers logs from various layers, the log backhaul component sends collected logs back to a designated system, the tracing component tracks the call chain during task execution, and the monitoring / alerting component monitors system performance metrics and triggers alerts when metrics are abnormal. This observability layer helps to further ensure the reliability of the distributed task scheduling system.

[0049] Furthermore, taking the example of tasks primarily performed by edge nodes in a distributed cluster, see [link to relevant documentation]. Figure 3The diagram illustrates a distributed task scheduling process, primarily showcasing the core workflow. Specifically, it illustrates the main interactions between the task metadata unit, task scheduler, task instance unit, cloud-edge system components, and edge executor. It also demonstrates, to some extent, the interactions between the event-driven layer, unified scheduling framework layer, and cloud-edge collaboration layer. A detailed explanation follows: The task metadata unit can store metadata for various types of tasks, such as scheduled tasks, one-time tasks, batch calculation tasks, and graph calculation tasks. When the task metadata changes, a task event is generated.

[0050] The task scheduler, also known as the central task scheduler, is located in the cloud and can be used to schedule tasks executed by central nodes or edge nodes. The task scheduler can receive task events and schedule various types of tasks. In practical applications, a master node election mechanism can be used to elect a master scheduler node, enabling failover in the event of a master node failure and ensuring the continuity of scheduling services. Furthermore, the task scheduler can select available nodes to handle tasks based on functions such as load balancing, node discovery, node registration, and failover.

[0051] After task events are scheduled by the task scheduler, task instances are generated. Within the processing unit of each task instance, a task balancer can be used to achieve load balancing and dynamically adjust the distribution of task instances. Additionally, a log service component is included for processing task logs, which can be used to transmit and store task logs.

[0052] In the cloud-edge system components, the API server serves as the core hub for cloud-edge interaction, receiving requests from edge executors and interacting with other cloud-edge components such as the state synchronization server. The state synchronization server receives commands from the API server, enabling command issuance and state callbacks. Specifically, it can synchronize information reported by edge executors to the cloud, and vice versa, achieving synchronization of commands and states between the cloud and edge. The log server collects and stores task logs, providing data support for system observability (such as log queries and troubleshooting). The worker node server, also known as the compute server, manages the registration of worker nodes. Both cloud and edge worker nodes must register with it, enabling the system to be aware of the nodes' existence and status.

[0053] The types of edge executors correspond to the types of task schedulers, and they can work together with task schedulers in the cloud to complete tasks. Edge executors can achieve collaborative task scheduling between the cloud and the edge by interacting with API servers.

[0054] The worker node reconnection unit is responsible for re-establishing connections when edge nodes experience connectivity issues in complex edge network environments. Specifically, edge nodes register with the worker node server in the cloud-edge system component to ensure consistency in cloud-edge node management. Lease renewal and heartbeat keep-alive mechanisms maintain the activity between edge nodes and the system, ensuring that node status is promptly perceived by the system.

[0055] The above methods enable stable and reliable scheduling and execution of task events.

[0056] Figures 1-3 All of these are based on the event-driven pattern to achieve unified scheduling of multiple task types. For ease of understanding, please refer to [link / reference]. Figure 4 The diagram illustrates a distributed task scheduling process. It shows that various task types are first resolved by an event dispatcher and distributed to the corresponding task scheduler. The task scheduler then posts the task events to a pre-defined task scheduling event queue, where the corresponding executor consumes the events. In practice, a push-pull hybrid model can be used, supporting either posting task events to the corresponding executor or having the executor actively pull tasks; no restrictions are placed here. This event-driven model enables flexible scheduling and execution of various task types within a unified architecture. By setting different types of task schedulers, event queues, and task executors, loose coupling between components through events improves system scalability and facilitates the addition of new task types or optimization of task execution logic.

[0057] See Figure 5 The diagram illustrates a layout of scheduling nodes, showing that multiple worker nodes in a distributed cluster can be distributed across different data centers, and the primary and backup scheduling nodes can also be distributed across different central data centers. Additionally, Figure 5 This is for illustrative purposes only; in practical applications, the number of edge data centers far exceeds the number of central data centers. The aforementioned primary / standby mode and multi-data center redundancy effectively ensure the high availability of the distributed cluster's task scheduling system. Specifically, in Figure 5 In this distributed cluster, data centers can be deployed in multiple regions. Nodes in the central data center are central nodes, and nodes in edge data centers are edge nodes. Edge data centers can serve as task execution clusters. The primary and backup scheduling nodes are located in different central data centers. It should be noted that there can be one or more backup scheduling nodes, and these can be located in multiple different central data centers. The number of edge data centers is typically multiple. Figure 5 Only one is shown in the image.

[0058] exist Figure 5In this process, the main scheduling node is located in central data center A. The scheduler set up on the main scheduling node is the main scheduler. As the core scheduling component, the main scheduler is responsible for distributing tasks to worker nodes in central data centers such as central data center A and central data center B, as well as edge data centers, and coordinating task scheduling between data centers. The above steps are... Figure 5 The following is an illustration of interactive step 1. The backup scheduling node is located in the B central computer room. The scheduler configured on the backup scheduling node is the backup scheduler, which serves as a backup component for the primary scheduler. When the primary scheduling node fails, the backup scheduling node can take over the scheduling tasks, ensuring the continuity of scheduling services through the backup scheduler and preventing the entire system from paralyzing due to the failure of the primary scheduling node. The above steps are illustrated in... Figure 5 The process is illustrated in step 2 of the interaction diagram. Furthermore, worker nodes are deployed in both the central and edge data centers. The edge data centers can also function as regular worker clusters, receiving and executing tasks distributed by the scheduler. Worker nodes in different data centers can process corresponding tasks based on the data center's resource availability and task characteristics, achieving distributed task execution. Further... Figure 5 The diagram also illustrates a storage cluster, which can be used to persistently store task-related data, node status, and other information. The primary scheduling node, backup scheduling nodes, and worker nodes in each data center can all interact with the storage cluster, ensuring the scheduler obtains the latest task and node data. Simultaneously, worker nodes can perform data read and write operations while executing tasks, supporting the data requirements of task execution. Through this combination of "distributed nodes across multiple data centers in different locations + primary / backup scheduler + centralized storage cluster," distributed task scheduling and execution are achieved. Furthermore, the "primary / backup scheduling" and "multi-data center redundancy" effectively achieve disaster recovery and fault tolerance, ensuring high system availability. It also enables effective cross-data center task scheduling, allowing task nodes to be deployed in either the central or edge data center, achieving a unified architecture and effectively reducing cloud-edge collaborative management costs.

[0059] Building upon the aforementioned high availability of the scheduler, the distributed task scheduling system provided in this disclosure also possesses the characteristic of high availability of the executor. For ease of understanding, please refer to... Figure 6 The diagram illustrates a distributed task scheduling process, highlighting how this embodiment can ensure the continuity of task scheduling and execution through multiple mechanisms such as load balancing strategies, node health checks, and node balancers, effectively avoiding single points of failure and improving the overall high availability of the system. A detailed description follows: The scheduler can distribute pending task events to the load balancer, corresponding to Figure 6 In the interaction step 1, the load balancer can work in conjunction with the scheduler to provide load balancing for task distribution based on the load of nodes, ensuring that tasks are reasonably allocated to each node and avoiding situations where some nodes are overloaded and others are idle. Figure 6 Step 2 of the interaction. The task dispatcher can receive tasks from the scheduler and distribute the tasks to different nodes, corresponding to... Figure 6 Step 3 of the interaction. Through the node discovery component, the existence and status of nodes in the system can be detected, and information such as node connectability can be monitored in real time. Figure 6 In step 4 of the interaction, the health check component equips each node with a health check function to continuously monitor its own operational status, such as resource usage and service response speed, and reports this information to the node discovery component. Figure 6 Step 5 of the interaction. When the node discovery component detects that a node is disconnected (i.e., a node failure), the node balancer will be triggered. The node balancer will send a task migration request to the task scheduler and perform a task migration operation to transfer unfinished or pending tasks on the disconnected node to other healthy nodes, ensuring that task execution is not affected by the node failure, thereby realizing task migration.

[0060] The above methods can automatically migrate and protect all tasks in the event of node failure, avoiding task loss; they can also optimize migration based on task status and resource matching to achieve smooth task migration; they can also protect and restore the status of tasks in execution based on the breakpoint resume mechanism, and achieve dynamic load optimization during migration to achieve load self-balancing.

[0061] In summary, the distributed cluster task scheduling method provided in this disclosure supports unified scheduling of multiple task types, has strong versatility, decouples business logic from scheduling logic, and enables cloud-edge collaborative scheduling. It is well-suited to task execution scenarios on edge nodes and meets the task scheduling requirements of cloud-edge systems. Furthermore, by deploying the scheduler using a primary / backup mode and a multi-datacenter redundancy strategy, cluster nodes possess fault detection and automatic task migration capabilities. Additionally, edge resources can be managed through leases and other methods, effectively improving system fault tolerance and disaster recovery capabilities.

[0062] Corresponding to the aforementioned task scheduling method for distributed clusters, this disclosure further provides a task scheduling apparatus for distributed clusters. Figure 7 This is a schematic diagram of the structure of a distributed cluster task scheduling device provided in an embodiment of this disclosure. The device can be implemented by software and / or hardware, and is generally integrated into an electronic device, such as... Figure 7 As shown, the task scheduling device of the distributed cluster includes: The scheduler determination module 702 is used to respond to the detection of a target task event to be executed in the distributed cluster, determine the target event type to which the target task event belongs from a variety of preset task event types, and determine the target type scheduler corresponding to the target event type from a variety of task schedulers; wherein, the type of task scheduler and the type of task event have a one-to-one correspondence. The node determination module 704 is used to determine the target node for executing the target task event from the nodes of the distributed cluster based on the target type scheduler; wherein the nodes of the distributed cluster include central nodes and edge nodes; Event execution module 706 is used to execute target task events through the target node.

[0063] In related technologies, a fixed task scheduler is typically used to determine whether the trigger time has been reached, and then the scheduled task is executed after the trigger time is reached. The embodiments of this disclosure fully consider that the methods provided by related technologies can only meet the basic requirements of distributed scheduled tasks, which are limited and have a single applicable scenario. Therefore, the above-mentioned device can set up corresponding schedulers for various task event types and use an event-driven approach to perform targeted task scheduling, ensuring the reliability of task scheduling. It can be well applied to complex and diverse business scenarios, and various types of tasks can be uniformly scheduled based on the above scheduling logic, which has strong versatility. Business systems do not need to develop their own scheduling logic for different types of tasks, which can effectively reduce development costs.

[0064] In some implementations, the node determination module 704 is specifically used to: if the primary scheduling node in the distributed cluster does not fail, determine the target node for executing the task event from the nodes of the distributed cluster through the target type scheduler on the primary scheduling node; if the primary scheduling node in the distributed cluster fails, determine the target scheduling node from the backup scheduling nodes in the distributed cluster, and determine the target node for executing the task event from the nodes of the distributed cluster through the target type scheduler on the target scheduling node.

[0065] In some implementations, the distributed cluster has at least one backup scheduling node, and the primary scheduling node and at least one backup scheduling node of the distributed cluster are distributed in at least two data centers.

[0066] In some implementations, the node determination module 704 is specifically used to: determine the target node for executing the target task event from the nodes of the distributed cluster based on a preset task distribution strategy; wherein the task distribution strategy includes at least one or more of the following: a load balancing strategy and a node selection strategy based on node health status.

[0067] In some implementations, the event execution module 706 is specifically used to: execute the target task event through the target type executor in the target node corresponding to the target event type; wherein, the target node is provided with multiple types of task executors, and the multiple types of task executors have a one-to-one correspondence with the multiple types of task event.

[0068] In some embodiments, the device further includes a queue delivery module for delivering the target task event to a preset task scheduling event queue via the target type scheduler; the event execution module 706 is specifically used to: retrieve the target task event from the task scheduling event queue via the target type executor corresponding to the target event type in the target node, and execute the target task event.

[0069] In some embodiments, the apparatus further includes an event migration module for migrating the target task event to a healthy node in the distributed cluster for processing in response to a failure of the target node.

[0070] In some embodiments, the apparatus further includes an edge resource management module for managing node resources of the distributed cluster based on a lease mechanism.

[0071] In some implementations, the distributed cluster includes a central node and edge nodes.

[0072] The task scheduling device for distributed clusters provided in this disclosure can execute the task scheduling method for distributed clusters provided in any embodiment of this disclosure, and has the corresponding functional modules and beneficial effects of the execution method.

[0073] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the above-described device embodiments can be referred to the corresponding process in the method embodiments, and will not be repeated here.

[0074] This disclosure provides an electronic device, which includes: a storage device storing a computer program thereon; and a processing device for executing the computer program in the storage device to implement the steps of any method of this disclosure.

[0075] The following is for reference. Figure 8This document illustrates a structural schematic diagram of an electronic device 800 suitable for implementing embodiments of the present disclosure. The terminal devices in these embodiments may include, but are not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Devices), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital televisions and desktop computers. Figure 8 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0076] like Figure 8 As shown, electronic device 800 may include a processing device (e.g., a central processing unit, a graphics processing unit, etc.) 801, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 802 or a program loaded from storage device 808 into random access memory (RAM) 803. RAM 803 also stores various programs and data required for the operation of electronic device 800. The processing device 801, ROM 802, and RAM 803 are interconnected via bus 804. Input / output (I / O) interface 805 is also connected to bus 804.

[0077] Typically, the following devices can be connected to I / O interface 805: input devices 806 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 807 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 808 including, for example, magnetic tapes, hard disks, etc.; and communication devices 809. Communication device 809 allows electronic device 800 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 8 An electronic device 800 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively.

[0078] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 809, or installed from a storage device 808, or installed from a ROM 802. When the computer program is executed by a processing device 801, it performs the functions defined in the methods of embodiments of this disclosure.

[0079] In addition to the methods and devices described above, embodiments of this disclosure can also be computer program products, comprising computer program instructions that, when executed by a processor, cause the processor to perform the methods provided in the embodiments of this disclosure. The computer program product can be written in any combination of one or more programming languages ​​to perform the operations of the embodiments of this disclosure. These programming languages ​​include object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on a user computing device, partially on a user device, as a standalone software package, partially on a user computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0080] Furthermore, embodiments of this disclosure may also be computer-readable storage media storing computer program instructions that, when executed by a processor, cause the processor to perform the methods provided in embodiments of this disclosure.

[0081] The computer-readable storage medium may be any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may, for example, include, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: electrical connections having one or more wires, portable disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory, optical fibers, portable compact disk read-only memory, optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0082] This disclosure also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the methods described in this disclosure.

[0083] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0084] The above description is merely a specific embodiment of this disclosure, enabling those skilled in the art to understand or implement it. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this disclosure. Therefore, this disclosure is not to be limited to the embodiments described herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A task scheduling method for a distributed cluster, characterized in that, include: In response to detecting a target task event to be executed in a distributed cluster, the target event type to which the target task event belongs is determined from a variety of preset task event types, and a target type scheduler corresponding to the target event type is determined from a variety of task schedulers; wherein, the variety of task schedulers and the variety of task event types have a one-to-one correspondence. Based on the target type scheduler, a target node for executing the target task event is determined from the nodes of the distributed cluster; The target task event is executed through the target node.

2. The method according to claim 1, characterized in that, The step of determining the target node for executing the target task event from the nodes of the distributed cluster based on the target type scheduler includes: If the master scheduling node in the distributed cluster does not fail, the target node for executing the task event is determined from the nodes of the distributed cluster through the target type scheduler on the master scheduling node. If the primary scheduling node in the distributed cluster fails, a target scheduling node is determined from the backup scheduling nodes in the distributed cluster, and the target type scheduler on the target scheduling node is used to determine the target node for executing the task event from the nodes in the distributed cluster.

3. The method according to claim 2, characterized in that, The distributed cluster has at least one backup scheduling node, and the main scheduling node and at least one backup scheduling node of the distributed cluster are distributed in at least two data centers.

4. The method according to claim 1, characterized in that, Determining the target node from the nodes of the distributed cluster for executing the target task event includes: Based on a preset task distribution strategy, a target node for executing the target task event is determined from the nodes of the distributed cluster; wherein the task distribution strategy includes at least one or more of the following: a load balancing strategy and a node selection strategy based on node health status.

5. The method according to claim 1, characterized in that, The execution of the target task event through the target node includes: The target task event is executed through the target type executor in the target node that corresponds to the target event type; wherein, the target node is provided with multiple types of task executors, and the multiple types of task executors have a one-to-one correspondence with the multiple types of task event types.

6. The method according to claim 5, characterized in that, The method further includes: The target task event is delivered to a preset task scheduling event queue through the target type scheduler. The step of executing the target task event through the target type executor corresponding to the target event type in the target node includes: retrieving the target task event from the task scheduling event queue through the target type executor corresponding to the target event type in the target node, and executing the target task event.

7. The method according to claim 1, characterized in that, The method further includes: In response to a failure of the target node, the target task event is migrated to a healthy node in the distributed cluster for processing.

8. The method according to claim 1, characterized in that, The method also includes managing the node resources of the distributed cluster based on a lease mechanism.

9. The method according to any one of claims 1 to 8, characterized in that, The distributed cluster includes a central node and edge nodes.

10. A task scheduling device for a distributed cluster, characterized in that, include: The scheduler determination module is used to respond to the detection of a target task event to be executed in a distributed cluster, determine the target event type to which the target task event belongs from a preset variety of task event types, and determine the target type scheduler corresponding to the target event type from a variety of task schedulers; wherein, the variety of task schedulers and the variety of task event types have a one-to-one correspondence. A node determination module is used to determine, based on the target type scheduler, a target node for executing the target task event from the nodes of the distributed cluster; wherein the nodes of the distributed cluster include central nodes and edge nodes; The event execution module is used to execute the target task event through the target node.

11. An electronic device, characterized in that, The electronic device includes: A storage device on which computer programs are stored; A processing device for executing the computer program in the storage device to implement the steps of the task scheduling method for a distributed cluster according to any one of claims 1-9.

12. A computer-readable storage medium, characterized in that, The storage medium stores a computer program for executing the task scheduling method of the distributed cluster as described in any one of claims 1-9.

13. A computer program product, characterized in that, It includes a computer program that, when executed by a processor, implements the task scheduling method for a distributed cluster as described in any one of claims 1-9.

Images