WO2025256261A1 - 任务处理方法、装置和设备及计算机存储介质 - Google Patents

任务处理方法、装置和设备及计算机存储介质

Info

Publication number
WO2025256261A1
WO2025256261A1 PCT/CN2025/089242 CN2025089242W WO2025256261A1 WO 2025256261 A1 WO2025256261 A1 WO 2025256261A1 CN 2025089242 W CN2025089242 W CN 2025089242W WO 2025256261 A1 WO2025256261 A1 WO 2025256261A1
Authority
WO
WIPO (PCT)
Prior art keywords
task
instance
server
resource information
run
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
PCT/CN2025/089242
Other languages
English (en)
French (fr)
Inventor
王论建
陈煜东
戚元觐
杜勃勃
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tencent Technology (Shenzhen) Co Ltd
Original Assignee
Tencent Technology (Shenzhen) Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tencent Technology (Shenzhen) Co Ltd filed Critical Tencent Technology (Shenzhen) Co Ltd
Publication of WO2025256261A1 publication Critical patent/WO2025256261A1/zh
Pending legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0793—Remedial or corrective actions
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5038—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the execution order of a plurality of tasks, e.g. taking priority or time dependency constraints into consideration
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5083—Techniques for rebalancing the load in a distributed system
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Definitions

  • This application relates to the field of computer technology, specifically to a task processing method, apparatus, device, and computer storage medium.
  • cluster servers With the continuous development of internet science and technology, the concept of cluster servers is increasingly impacting all aspects of internet technology. There are now more and more large-scale system tasks that require cluster servers for execution. In processing large-scale system tasks, task scheduling and execution are crucial issues. Especially in scenarios where tasks have dependencies, the success or failure of one task can significantly affect the smooth progress of the entire system's task flow.
  • This application provides a task processing method, apparatus, device, and computer storage medium to improve task error correction efficiency.
  • This application provides a task processing method, executed by a cluster server, including:
  • Receive a task execution instruction which includes at least: task information related to at least one task instance of the first task, and resource information required to run the first task;
  • a first server node in the cluster server is assigned to each task instance in at least one task instance to run the corresponding task instance.
  • a second server node in the cluster server is allocated to the first task instance to run the first task instance again.
  • the result of the first task is determined when the execution status of at least one task instance meets the preset termination condition.
  • This application also provides a task processing apparatus applied to a cluster server, comprising:
  • the receiving module is used to receive a task execution instruction, which includes at least: task information related to at least one task instance of the first task, and resource information required to run the first task;
  • the allocation module is used to allocate a first server node in the cluster server for running the corresponding task instance, based on resource information, for each task instance in at least one task instance.
  • the processing module is configured to allocate a second server node in the cluster server to run the first task instance again when it is determined that the first task instance among the at least one task instance has failed to run; and to determine the running result of the first task when the running status of at least one task instance meets the preset termination conditions.
  • This application also 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 computer program to implement the steps of any of the above methods.
  • This application also provides a computer storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of any of the above methods.
  • This application also proposes a computer program product, including a computer program, wherein the computer program, when executed by a processor, implements any of the above methods.
  • This application provides a task processing method applied to a cluster server.
  • server nodes By assigning server nodes to task instances corresponding to tasks, the running status of each task instance can be monitored in real time.
  • a second server node is reassigned to run the task instance again, thus eliminating task failures caused by occasional factors and improving the success rate of task execution.
  • error retries are performed at the task instance level, eliminating the need to wait for the entire task to complete before retrying, shortening the retry time for task failures and improving task execution efficiency.
  • FIG. 1A is an overview flowchart of the task processing methods of various embodiments
  • Figure 1B is a schematic diagram of the application scenario provided by the embodiments of this application.
  • Figure 2 is a flowchart illustrating a method for handling task failures according to an embodiment of this application
  • Figure 3 is a logical schematic diagram of a method for allocating server nodes to task instances according to an embodiment of this application;
  • Figure 4 is a logical schematic diagram of a method for reallocating server nodes for a failed task instance provided in an embodiment of this application;
  • Figure 5 is a logical diagram of a method for confirming the failure of a task instance according to an embodiment of this application
  • Figure 6 is a schematic diagram of the dependencies between tasks provided in an embodiment of this application.
  • Figure 7 is a flowchart of a method for running a task instance according to an embodiment of this application.
  • Figure 8 is a logical schematic diagram of a method for determining the execution order of tasks provided in an embodiment of this application.
  • Figure 9 is a logical diagram of another method for determining the execution order of tasks provided in an embodiment of this application.
  • Figure 10 is a logical schematic diagram of a method for allocating server resources for a task according to an embodiment of this application;
  • Figure 11 is a schematic diagram of a directed acyclic graph representing the dependencies between tasks according to an embodiment of this application;
  • Figure 12 is a schematic diagram of another directed acyclic graph representing the dependencies between tasks provided in an embodiment of this application.
  • Figure 13 is a structural diagram of the relationship between an operation, a task, and a task instance provided in an embodiment of this application;
  • Figure 14 is a structural relationship diagram between operations and tasks provided in an embodiment of this application.
  • Figure 15 is a schematic diagram of a display interface for creating jobs and tasks provided in an embodiment of this application.
  • Figure 16 is a logical schematic diagram of a task failure handling method provided in an embodiment of this application.
  • Figure 17 is a schematic diagram of a task failure handling device provided in an embodiment of this application.
  • Figure 18 is a schematic diagram of the composition structure of the computer device provided in an embodiment of this application.
  • Figure 19 is a schematic diagram of the composition structure of another computer device using an embodiment of this application.
  • module refers to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof.
  • a processor or multiple processors or memory
  • each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.
  • task scheduling and execution are critical issues, especially in scenarios where tasks have dependencies.
  • the success or failure of a single task can significantly impact the smooth operation of the entire system's task flow.
  • failed tasks are typically rerun.
  • this approach requires determining task failure based on the results of all task instances within the task. This means that a failure can only be determined after the results of all task instances have been determined, resulting in a significant waiting time.
  • rerunning a task requires re-running all its instances, leading to a waste of computing resources.
  • FIG. 1A is an overview flowchart of the task processing method of each embodiment.
  • the cluster server Upon receiving a task execution instruction (S11), the cluster server can obtain at least one task instance corresponding to the first task based on the task information and resource information of the target task (i.e., the task to be executed, hereinafter also referred to as the current task or the first task) included in the instruction, and allocate a first server node in the cluster server for each task instance (S12), so that each first server node corresponds to a task instance, and the task instance is run on the corresponding first server node.
  • the target task i.e., the task to be executed, hereinafter also referred to as the current task or the first task
  • a task refers to a task that performs specified processing on specified data, particularly batch processing of large amounts of data.
  • a task may include image data processing (such as real-time analysis and recognition of images captured by vehicle-mounted cameras for autonomous driving, analysis of medical image data and lesion identification, etc.), user data processing (such as analysis of behavioral data of a large number of users on an e-commerce platform, etc.), and log data processing (such as real-time analysis and fault identification of a large amount of application operation log data collected by an application's server from a large number of devices, etc.).
  • image data processing such as real-time analysis and recognition of images captured by vehicle-mounted cameras for autonomous driving, analysis of medical image data and lesion identification, etc.
  • user data processing such as analysis of behavioral data of a large number of users on an e-commerce platform, etc.
  • log data processing such as real-time analysis and fault identification of a large amount of application operation log data collected by an application's server from a large number of devices, etc.
  • a task instance is the instantiated representation of a task during execution.
  • a task typically involves performing the same series of processes on a large amount of data. When a task is actually executed, performing this series of processes on a specific piece of data constitutes an instance of that task.
  • multiple task instances can be created, each responsible for processing a portion of the image data.
  • each task instance is responsible for processing a portion of the user behavior data.
  • each task instance is responsible for processing a portion of the log data.
  • a server node also known as a compute node, refers to a software unit used to execute a specific task instance.
  • compute nodes are allocated according to the needs of the task instance, and each compute node can execute one task instance.
  • various required resources such as CPU resources, storage space, and network resources, can be allocated to the compute nodes according to the needs of the task instance.
  • the compute node can be released or destroyed.
  • a compute node can be a virtual machine in cloud computing technology.
  • Another example is a container in cloud computing technology.
  • a container in cloud computing technology is a lightweight, portable, self-contained software deployment unit that can package applications and their dependencies together, achieving isolation and efficient operation of different applications in the same environment.
  • a container encapsulates an application and its required dependencies, such as libraries, configuration files, and runtime environments, into an independent unit with an independent runtime environment.
  • a corresponding second server node can be reassigned within the cluster server (S13) so that the second server node can run the failed task instance again.
  • the cluster server can immediately rerun the corresponding task instance, thereby eliminating task failures caused by occasional factors and reducing the probability of the first task failing. This continues until the running status of at least one task instance corresponding to the first task meets the preset termination condition, at which point the cluster server can determine the running result of the first task (S14).
  • the cluster server nodes to run task instances corresponding to tasks the running status of each task instance can be checked in real time.
  • a second server node When a task instance fails, a second server node is reassigned to run the task instance again, thereby eliminating task failures caused by occasional factors and improving the success rate of task execution. Furthermore, error retries are performed at the task instance level, eliminating the need to wait for the entire task to complete before retrying, shortening the task failure retry time and improving task execution efficiency.
  • Server 101 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, i.e., Content Delivery Network (CDN), as well as big data and artificial intelligence platforms, but it is not limited to these.
  • cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, i.e., Content Delivery Network (CDN), as well as big data and artificial intelligence platforms, but it is not limited to these.
  • CDN Content Delivery Network
  • Server 101 may include one or more processors, memory, and I/O interfaces for interaction. Furthermore, server 101 is configured with a database to store the program instructions required for execution in the task failure handling methods provided in this application embodiment. These program instructions, when executed by the processor, can be used to implement the task failure handling process provided in this application embodiment.
  • the servers 101 can communicate with each other via cables, or they can communicate directly or indirectly via one or more communication networks 102.
  • the communication network 102 can be a mobile cellular network, or a Wireless-Fidelity (WIFI) network, or other possible networks. This embodiment does not limit the types of networks used.
  • WIFI Wireless-Fidelity
  • Figure 1 is only an example, and the actual number of servers is not limited, nor is it specifically limited in this embodiment.
  • the method can be executed by the cluster server shown in Figure 1.
  • any server in the cluster server can act as the execution subject to complete the method shown in Figure 2.
  • the method is as follows.
  • Step S201 Receive a task execution instruction, which includes at least the task information of the first task to be executed and the resource information required to run the first task.
  • the task failure handling method is executed by the cluster server. Therefore, when receiving a task execution instruction, any server node in the cluster server can accept the instruction, or there can be one server node in the cluster server to receive all task execution instructions.
  • This application does not impose any restrictions on this. For the sake of clarity, the following description will use the cluster server as the main body for method execution.
  • the task execution instruction includes at least the task information of the first task.
  • This task information is related to at least one task instance of the first task.
  • This task information includes: information describing the number of replicas required to run the first task, and information about the corresponding task instances that the first task needs to generate.
  • the cluster server can generate the corresponding number of task instances for the first task based on the number of replicas in this task information. Additionally, this task information also includes some necessary information about the first task, such as task identifiers and task descriptions, which are not limited in this application.
  • the task execution instructions also include the resource information required to run the first task.
  • the cluster server can use this resource information to allocate server nodes with computing resources that meet the requirements of the first task to each task instance corresponding to the first task, so as to run each task instance.
  • the cluster server After receiving the task execution command, the cluster server can perform the following operations:
  • Step S202 Based on the task information, obtain at least one task instance corresponding to the first task.
  • the first task is a task created by the developer on the task development interface.
  • Examples include Spark tasks for cluster management, Spark SQL tasks for processing structured data, or data synchronization tasks. When these tasks are generated, the most important information describes the application's configuration, runtime environment, startup commands, and output configuration.
  • the first task is a static script during development; when it is submitted to the server for execution, it needs to be abstracted into a task instance during execution. Therefore, it can be understood that a task instance is an object created based on the task and that actually executes the application.
  • the number of task instances i.e., the number of replicas
  • all task instances create and execute the application using the information in the first task.
  • the cluster server can generate a corresponding number of task instances for the first task based on the task information, such as the number of task replicas indicated in the instruction. These task instances are used to run the replicas of the first task in parallel, thereby achieving the overall execution goal of the first task.
  • Step S203 Based on resource information, allocate a corresponding first server node in the cluster server to each of at least one task instance, so that each first server node runs the corresponding task instance; wherein, the first server node corresponds one-to-one with the task instance.
  • the cluster server after the cluster server obtains the task instance, it can allocate the corresponding first server node in the cluster server to each task instance based on the performance requirements of computing resources included in the resource information. These first server nodes must first meet the running performance requirements of the task instance, and secondly, they must be bound one-to-one with each task instance. In this way, only one task instance runs in a first server node, so as to achieve the requirement of one-to-one correspondence between the first server node and the task instance.
  • each first server node in the cluster server can run the respective task instance.
  • the cluster server can monitor the running status of all first server nodes in real time and determine the next execution steps based on the running status of each first server node.
  • the server can determine the running status of the task instances running on each first server node. When it is determined that a task instance corresponding to a first server node has failed to run, the following operations are performed on the first server node where the task instance has failed.
  • Step S204 In the cluster server, reallocate the corresponding second server node for the failed task instance so that the second server node can rerun the corresponding failed task instance.
  • the cluster server can directly reassign a server node to the failed task instance without waiting for feedback from other task instances, and then run the task instance again, thus eliminating the possibility that the task instance failed due to accidental factors.
  • the cluster server can use different methods to re-run the task instance, depending on the reason for the task instance failure.
  • the cluster server can initially assign the same server node as the first server node as a second server node, allowing the task instance to restart on the same first server node. Only if it fails again after this second attempt will the cluster server assign a new second server node to the task instance; this new second server node will be different from the first server node.
  • the cluster server can allocate a third server node to the task instance, different from the original first server node. This allows the task instance to restart on the new third server node.
  • the cluster server first determines the cause of the task instance's failure and then specifically reallocates a new third server node, increasing the probability of successful execution after a retrieval.
  • the cluster server receiving the task execution instruction is a cloud server cluster
  • the first server node allocated to the task instance may be unable to provide a running environment for the task instance due to network fluctuations, or may be unable to be directly allocated to the task instance due to insufficient computing resources of the current cloud server cluster.
  • the cloud server cluster can create a new server node as the third server node allocated to the task instance for the task instance to run.
  • the cluster server selects different methods to reallocate server nodes to the task instance based on the different failure situations of the task instance. That is, when the error of running failure is expected, the reallocation is performed, which further increases the probability of the task instance running successfully after retrying the error.
  • the cluster server For a second task instance within at least one task instance, the cluster server also needs to perform corresponding check operations and possible reassignment of server nodes.
  • the cluster server can execute step S205: obtain the running result of the first task when it determines that the running status of at least one task instance meets the preset termination condition.
  • the execution results are divided into two categories: those indicating the success of the first task and those indicating its failure.
  • the methods for obtaining these two types of results are as follows.
  • the cluster server can obtain the running result of the first task based on the running results of all task instances running on the cluster server.
  • the cluster server can obtain the execution results of all task instances.
  • the cluster server determines that the execution results for all task instances are successful, it can obtain the execution result indicating that the first task ran successfully; otherwise, it obtains the execution result indicating that the first task failed.
  • This method obtains the running result of the first task by acquiring the running results of all task instances.
  • the cluster server needs to confirm that all task instances corresponding to the first task have run successfully before it can determine that the first task has run successfully. If at least one running result of failure exists among the running results of all task instances, the cluster server can determine that the first task has failed based on this situation.
  • the cluster server can directly determine the overall running result of the first task based on whether some task instances among all task instances meet the preset termination conditions.
  • the cluster server when the cluster server determines that a task instance has been rerun a certain number of times, it can mark the task instance as failed and obtain the running result indicating that the first task has failed.
  • instance 1, instance 2, instance 3, and instance 4 For example, as shown in Figure 5, suppose the cluster server is executing a first task corresponding to multiple task instances (i.e., instance 1, instance 2, instance 3, and instance 4).
  • the running status of these four task instances is as follows: task instances 1, 2, and 3 are running normally and have not yet completed their execution, while the number of times instance 4 has been re-run has reached a preset threshold.
  • the cluster server determines that the number of re-runs for instance 4 has reached the threshold, and can mark instance 4 as having failed.
  • the cluster server can also simultaneously determine that the first task has failed without waiting for the other three task instances (instance 1, instance 2, and instance 3) to complete their execution.
  • the cluster server can determine the overall running status of a task by observing the running status of a subset of task instances, eliminating the need to wait for all task instances to complete and improving the efficiency of confirming task failures.
  • the cluster server determines that the ratio between the rerunning task instance and the normally running task instance in the task instance corresponding to the first task reaches a preset ratio threshold, the running result representing the failure of the first task can be obtained.
  • the cluster server can directly determine that the first task has failed, without waiting for all task instances to complete running and for the running status to be collected.
  • the cluster server first determines that there is a task instance whose rerun count has reached a threshold. In this case, the cluster server can obtain the result of the first task based on the task instance whose rerun count has reached the threshold.
  • the cluster server can determine that the result of the first task is a failure.
  • the cluster server can determine the result of the first task based on the results of all task instances.
  • the specific settings for the above-mentioned threshold values such as the number of times and the proportion threshold can be set according to the developer's needs in actual applications, and this application does not impose any restrictions on this.
  • the method is applied to a cluster server.
  • the method By allocating the task instance corresponding to the first task included in the task execution instruction to different first server nodes for execution, it ensures that each task instance has its own corresponding server node for execution, thereby distributing the computing resources required when running tasks on individual servers and achieving the purpose of balancing computing resources in the cluster server.
  • each task instance on the first server node its running status needs to be checked.
  • a second server node can be reassigned within the cluster server to rerun the failed task instance. Therefore, whenever any task instance corresponding to the first task fails, the cluster server can immediately rerun the corresponding task instance, thereby eliminating task failures caused by occasional factors and reducing the likelihood of the first task failing.
  • the cluster server can obtain the running result of the first task when the running status of at least one task instance corresponding to the first task meets the preset termination condition.
  • the cluster server can quickly determine the occurrence of errors in task instances by viewing the running status of each task instance in real time. Furthermore, when an error is determined to have occurred, error retrying is performed at the task instance level, which can quickly eliminate intermittent errors and improve the success rate of task execution.
  • the cluster server can also perform the following operations.
  • a task execution instruction When a task execution instruction includes at least one second task in addition to the first task, the task execution instruction will also include: task information of the second task and resource information required to run the second task.
  • the runtime dependencies between the first task and at least one second task are also included in the task execution instructions.
  • Task dependencies refer to whether a task requires the result of a preceding task to begin execution. For example, as shown in Figure 6, assuming there are six tasks, task 1 through task 6, the dependencies between these six tasks are as follows: task 1 depends on task 2 and task 5; task 2 depends on task 3 and task 4; task 3 has no dependencies; task 4 has no dependencies; task 5 has no dependencies; and task 6 depends on task 2.
  • Step S701 Based on the task information of the first task and the task information of at least one second task, obtain at least two task instances corresponding to the first task and at least one second task.
  • the cluster server can allocate its corresponding first server node to each task instance.
  • the cluster server needs to determine the execution order of task instances based on these dependencies. For example, the cluster server can perform the following operations.
  • Step S702 Based on the runtime dependency between the first task and at least one second task, obtain the running order of at least two task instances corresponding to the first task and at least one second task.
  • the cluster server can determine the execution order between the first task and the second task based on the dependency relationship between the first task and the second task, and then superimpose this execution order onto the task instances corresponding to each task, so as to determine the execution order between task instances based on the execution order between tasks.
  • the task execution instruction contains six tasks as shown in Figure 6, where the first task is Task 1 and the second tasks are Tasks 2 through 6. Then, for the first and second tasks, the task execution order is as follows: first, Tasks 3, 4, and 5 are executed in parallel; then, based on the results of Tasks 3 and 4, Task 2 is executed; finally, based on the results of Tasks 2 and 5, Tasks 6 and 1 are executed.
  • the execution order between the task instances is determined according to the above-mentioned task execution order.
  • task instances that can run in parallel, such as multiple task instances corresponding to the same task, or multiple task instances corresponding to multiple tasks that can run in parallel.
  • Step S703 Based on the running order, run the first task and at least two task instances corresponding to at least one second task in sequence.
  • the cluster server can complete the execution of each task instance according to this order.
  • the above method directly determines the execution order of task instances and thus judges the execution time of each task instance based on the execution order between the first and second tasks.
  • the runtime of a task instance can be determined directly through the task instance's identification information. It should be noted that the distinction between the first and second tasks mentioned above is merely a name difference; both are types of tasks to be run. Therefore, they will be collectively referred to as "tasks" below.
  • the cluster server can first determine whether each task has a prerequisite task; wherein, the prerequisite task is: when the task to be run needs the execution result of the second task as a running condition, the task that provides the execution result for the task to be run is the prerequisite task of the task to be run.
  • tasks with prerequisite tasks can be marked as "preparing,” while tasks without prerequisite tasks can be marked as “runnable.”
  • each task instance can inherit the execution marker of its corresponding task. That is, task instances corresponding to tasks marked as "preparing” need to be marked as "preparing,” and task instances corresponding to tasks marked as "runnable” need to be marked as "runnable.”
  • each server node can run each task instance according to the execution markers corresponding to the task instances.
  • the cluster server when a task has subsequent tasks that need to wait for its execution result as a condition for execution, the cluster server, after determining that the task's execution result is successful, can transmit the task's execution result to the corresponding subsequent task and modify the execution flag of the subsequent task to be executable.
  • the server node corresponding to the task instance can start running the corresponding task instance based on the change in the task instance's execution flag.
  • the cluster server can also perform the following operations to allocate server nodes.
  • the cluster server can allocate associated server resources in the cluster server for the first task and at least one second task based on the resource information corresponding to the first task and at least one second task in the task execution instruction.
  • associated server resources refer to server resources that have related hardware resources, software resources, or configuration resources. For example, server resources in the same region's high-availability cluster or directly connected server cluster, server resources with the same network bandwidth resources, server resources with the same operating system, server resources with the same security settings, etc.
  • the cluster server when the cluster server allocates corresponding server resources for each task, it can perform different operations based on whether the resource information corresponding to the task specifies a preset running environment.
  • the cluster server determines that a preset operating environment has been specified in the resource information corresponding to the first task and the at least one second task, it allocates server resources corresponding to the preset operating environment in the cluster server to the first task and the at least one second task respectively.
  • the dependencies between tasks can be recorded separately in the configuration information of each task. For example, when a task has prerequisite and subsequent tasks, the task identifiers of the prerequisite tasks and the corresponding subsequent tasks can be recorded in the task information of the task. In this way, after receiving the task execution instruction, the cluster server can determine the dependencies between the tasks in the task execution instruction based on the task information of each task.
  • the dependencies between tasks can be recorded separately, and then the task execution instructions can include the separately recorded dependencies between tasks.
  • the cluster server can directly determine the dependencies between tasks in the task execution instructions based on the content contained in the task execution instructions, and thus determine the order of execution of task instances.
  • a DAG is a data structure consisting of a series of vertices and edges connecting them.
  • Directed means that the edges in the graph have a direction; that is, the edge A->B and B->A are two different edges.
  • undirected means that A->B and B->A share a single edge.
  • Acyclic means that starting from any point and traversing along the direction of an edge, one will not return to the original point.
  • the DAG When a directed acyclic graph (DAG) is used to represent the dependencies between tasks, the DAG will include at least two target nodes and at least one edge. Each target node corresponds to one of the first task and at least one of the second tasks, and each edge corresponds to the dependency between the two tasks in the first task and at least one of the second tasks.
  • DAG directed acyclic graph
  • Figure 12 includes tasks A through E, where tasks A, B, D, and E each correspond to only one task instance, while task C corresponds to several task instances. Therefore, in the execution order shown in Figure 12, the task execution sequence starts with task A, executing each task sequentially, and several task instances can run in parallel while running task C.
  • a job layer containing one or more tasks is added to the two-layer architecture of task-task instance, thus forming a three-layer architecture of job-task-task instance.
  • a job can include one or more tasks, and each task can correspond to one or more task instances.
  • the job information corresponding to the job includes the resources required by the tasks contained in the job, the number of replicas, and the dependencies between multiple tasks, determining the execution order of each task.
  • a job can contain tasks in three ways: single-task, concurrent tasks, or multi-task with an execution order.
  • the information contained in the task execution instruction can be the job information corresponding to the aforementioned job.
  • This job information includes the task information and resource information of the first task, as well as the task information and resource information of any possible second task.
  • both the first task and at least one second task correspond to a job. Therefore, the job information corresponding to a job can also include information indicating the preset operating environment corresponding to each task in the job.
  • the cluster server After receiving a task execution instruction containing job information, the cluster server first decomposes the job into corresponding tasks in the scheduling system. Then, each task generates a corresponding number of instances based on its replica count, and binds these task instances to server nodes to establish a correspondence. Finally, the corresponding task instances are run on each server node to obtain the task execution results.
  • the cluster server before the cluster server receives the task execution instruction, can provide the user with several corresponding job creation methods.
  • the cluster server can generate descriptive data of a directed acyclic graph representing the runtime dependencies between the first task and the at least one second task based on user input information.
  • the cluster server can provide users with a display interface as shown in Figure 15.
  • This interface is a primary interface.
  • the task icons displayed on the left can be clicked by the user to enter the corresponding secondary interface.
  • the secondary interface the user can enter the corresponding task information and resource information according to the prompts to complete the task creation.
  • the right side of the primary interface is used to create dependencies between tasks for the user.
  • users can drag and drop different tasks on the creation interface based on pre-created task templates, connect the tasks according to actual needs, and specify the order of the tasks to form a corresponding directed acyclic graph (DAG).
  • DAG directed acyclic graph
  • users can generate a DAG on the interface through input selection and/or drag-and-drop operations, including two first graphical display elements representing the first task and the second task, and a second graphical display element between the two first graphical display elements to represent the dependencies between the tasks.
  • the cluster server can generate descriptive data for the DAG based on the user-input DAG.
  • the cluster server can directly provide a parameter input interface for users.
  • users can directly add the corresponding task parameters to the submission parameters according to a specified template.
  • the cluster server generates the corresponding directed acyclic graph (DAG) based on the task parameters. For example, by inputting the value of at least one parameter from a preset template describing a DAG in the interface, the cluster server can generate descriptive data for the DAG based on the user-input parameter values.
  • DAG directed acyclic graph
  • Cluster servers can use various feasible methods to record directed acyclic graphs, such as using text, tables, arrays, etc. as descriptive data for directed acyclic graphs, which will not be elaborated here.
  • the cluster server After the cluster server completes the above-mentioned task execution operations and obtains the result of the first task, the following operations can be performed:
  • the cluster server can store the result of the first task. Since the error retry process has already been completed at the task instance level, when faced with a first task that has already obtained a result, regardless of whether the result indicates success or failure, the cluster server can terminate the execution of the first task and release the server resources occupied by at least one task instance included in the first task.
  • Figure 16 is a logical schematic diagram of a task failure handling method provided in an embodiment of this application, as shown in Figure 16, in a cluster environment, when a user needs the cluster server to run multiple tasks, the user can pre-create job resources, and then create each task to be run in sequence in the job resources according to the method shown in Figure 15, and finally create the dependency relationship between multiple tasks to complete the creation of job resources, and upload the created jobs to the cluster server, which serves as the task run instruction sent to the cluster server.
  • the cluster server needs to first obtain the task information, resource information, and dependencies between the multiple tasks included in the job from the task execution instruction. Then, according to the instructions in the task information, it allocates corresponding server resources for tasks with preset running environments and creates suitable server resources for tasks without preset running environments.
  • the cluster server generates a task instance for each task based on the task information, and allocates a suitable first server node from the corresponding server resources for each task instance based on the resource information of each task.
  • the cluster server can determine the execution order of multiple tasks and extend this order to each task instance, so that each task instance can complete its execution according to the dependencies between tasks.
  • the cluster server can view the running status of task instances on each server node. Whenever a task instance corresponding to a first server node is found to have failed, the cluster server will reallocate a corresponding second server node for the failed task instance, so that the second server node can rerun the corresponding failed task instance.
  • the cluster server needs to continuously perform these viewing operations on the server nodes and the corresponding retry operations until the running status of at least one task instance meets the preset termination conditions, at which point the cluster server can obtain the running result of the first task.
  • this application also provides a task failure handling device.
  • a task failure handling device Referring to Figure 17, which is a structural schematic diagram of a task failure handling device provided in this application, the device is applied to a cluster server, which may be the aforementioned server or a chip or integrated circuit therein.
  • the device includes modules/units/technical means for executing the method executed by the server in the above method embodiments.
  • the device 1700 includes:
  • the receiving module 1701 is used to receive a task execution instruction, which includes at least: task information of the first task and resource information required to run the first task;
  • the allocation module 1702 is used to obtain at least one task instance corresponding to the first task based on task information; and to allocate corresponding first server nodes in the cluster server to the at least one task instance based on resource information, so that each first server node runs the corresponding task instance; wherein, the first server node corresponds one-to-one with the task instance.
  • the processing module 1703 is used to, when each task instance corresponding to a first server node fails to run, reallocate a corresponding second server node to the failed task instance in the cluster server so that the second server node can rerun the corresponding failed task instance until the running status of at least one task instance meets the preset termination condition, and obtain the running result of the first task.
  • the task execution instruction further includes: task information for at least one second task, resource information required to run at least one second task, and runtime dependencies between the first task and at least one second task; the allocation module 1702, when obtaining at least one task instance corresponding to the first task based on the task information, is specifically used for:
  • the allocation module 1702 is also used for:
  • the first task and at least two task instances corresponding to at least one second task are executed sequentially.
  • the allocation module 1702 before the allocation module 1702 obtains at least one task instance corresponding to the first task based on task information, it is specifically used for:
  • the allocation module 1702 when allocating the corresponding first server node in the cluster server for at least one task instance based on resource information, is specifically used for:
  • the allocation module 1702 when allocating server resources in the cluster server for the first task and at least one second task based on resource information corresponding to the first task and at least one second task, specifically performs the following:
  • the server resources corresponding to the preset running environment in the cluster server are allocated to the first task and at least one second task respectively.
  • the corresponding server resources are created in the cluster server, and server resources are allocated for the first task and at least one second task.
  • the runtime dependencies between the first task and at least one second task are represented by a directed acyclic graph.
  • the directed acyclic graph contains at least two target nodes and at least one edge; each target node corresponds to one of the first task and at least one of the second tasks, and each edge corresponds to the dependency relationship between the two tasks in the first task and at least one of the second tasks.
  • the processing module 1703 when obtaining the running result of the first task until the running status of at least one task instance meets a preset termination condition, is specifically used for:
  • the task instance When the number of reruns of a task instance reaches the threshold, the task instance is marked as failed, and the running result representing the failure of the first task is obtained.
  • each time a task instance is run the processing module 1703 is further configured to:
  • a third server node is allocated to the task instance so that the third server node can run the task instance; wherein, the third server node is a server node in the cluster server other than the first server node corresponding to the task instance.
  • the processing module 1703 is further configured to:
  • Release server resources occupied by at least one task instance included in the first task are Release server resources occupied by at least one task instance included in the first task.
  • This device can be used to execute the methods shown in the various embodiments of this application. Therefore, the functions that each functional module of this device can achieve can be referred to the description of the foregoing embodiments, and will not be repeated here.
  • the computer device can be the server shown in Figure 1.
  • the computer device includes a memory 1801, a communication module 1803, and one or more processors 1802.
  • the memory 1801 is used to store computer programs executed by the processor 1802.
  • the memory 1801 may mainly include a program storage area and a data storage area.
  • the program storage area may store the operating system and programs required to run the functions of the embodiments of this application;
  • the data storage area may store various instant messaging information and operation instruction sets.
  • Memory 1801 may be volatile memory, such as random-access memory (RAM); memory 1801 may also be non-volatile memory, such as read-only memory, flash memory, hard disk drive (HDD), or solid-state drive (SSD); or memory 1801 may be any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but is not limited thereto. Memory 1801 may be a combination of the above-described memories.
  • RAM random-access memory
  • memory 1801 may also be non-volatile memory, such as read-only memory, flash memory, hard disk drive (HDD), or solid-state drive (SSD); or memory 1801 may be any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but is not limited thereto.
  • Memory 1801 may be a combination of the above-described memories.
  • Processor 1802 may include one or more central processing units (CPUs) or digital processing units, etc. Processor 1802 is used to implement the above-mentioned task failure handling method when calling a computer program stored in memory 1801.
  • CPUs central processing units
  • Digital processing units etc.
  • Processor 1802 is used to implement the above-mentioned task failure handling method when calling a computer program stored in memory 1801.
  • the communication module 1803 is used to communicate with terminal devices and other servers.
  • This application embodiment does not limit the specific connection medium between the memory 1801, communication module 1803, and processor 1802.
  • the memory 1801 and processor 1802 are connected via a bus 1804, which is depicted as a thick line.
  • the connection methods between other components are merely illustrative and not intended to be limiting.
  • the bus 1804 can be an address bus, data bus, control bus, etc. For ease of description, only one thick line is used in Figure 18, but this does not imply that there is only one bus or one type of bus.
  • the memory 1801 stores a computer storage medium, which stores computer-executable instructions.
  • the computer-executable instructions are used to implement the task failure handling method of the embodiments of this application, and the processor 1802 is used to execute the task failure handling method of the above embodiments.
  • the computer device can also be a terminal device, as shown in FIG1.
  • the structure of the computer device can be as shown in FIG19, including: a communication component 1910, a memory 1920, a display unit 1930 (e.g., a display screen 1932, a touch screen 1931), a camera 1940, sensors 1950 (e.g., an accelerometer 1951, a proximity sensor 1952, a fingerprint sensor 1953, a temperature sensor 1954), an audio circuit 1960 (e.g., connected to a speaker 1961, a microphone 1962), a Bluetooth module 1970, a processor 1980, and other components.
  • a communication component 1910 e.g., a memory 1920, a display unit 1930 (e.g., a display screen 1932, a touch screen 1931), a camera 1940, sensors 1950 (e.g., an accelerometer 1951, a proximity sensor 1952, a fingerprint sensor 1953, a temperature sensor 1954), an audio circuit 1960 (e.g., connected to a speaker 1961, a microphone 1962), a Bluetooth module 1970, a processor 1980
  • embodiments of this application also provide a storage medium storing a computer program that, when run on a computer, causes the computer to execute the steps of the task failure handling method described above according to various exemplary embodiments of this application.
  • various aspects of the task failure handling method provided in this application can also be implemented in the form of a computer program product, which includes a computer program that, when run on a computer device, causes the computer device to perform the steps in the task failure handling method according to various exemplary embodiments of this application described above.
  • the computer device can perform the steps of the various embodiments.
  • the program product may employ 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 be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of readable storage media include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.
  • the program product of the embodiments of this application may employ a portable compact disc read-only memory (CD-ROM) and include a computer program, and may run on a computer device.
  • CD-ROM portable compact disc read-only memory
  • the program product of this application is not limited thereto.
  • the readable storage medium may be any tangible medium that contains or stores a program, and the computer program included therein may be used by or in conjunction with a command execution system, apparatus, or device.
  • a readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying a readable computer program. This propagated data signal may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof.
  • a readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting a program for use by or in conjunction with a command execution system, apparatus, or device.
  • Computer programs contained on readable media may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.
  • Computer programs for performing the operations of this application can be written in any combination of one or more programming languages, including object-oriented programming languages such as Java and C++, as well as conventional procedural programming languages such as the "C" language or similar programming languages.
  • this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
  • computer-usable storage media including but not limited to disk storage, CD-ROM, optical storage, etc.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Debugging And Monitoring (AREA)
  • Hardware Redundancy (AREA)

Abstract

本申请公开了一种任务处理方法、装置和设备及计算机存储介质，应用于计算机技术领域。该方法由集群服务器执行，包括：接收任务运行指令，任务运行指令包括：第一任务的至少一个任务实例相关的任务信息，以及运行第一任务所需的资源信息；基于资源信息，分别为至少一个任务实例中的每个任务实例分配集群服务器中的一个第一服务器节点；当确定第一任务实例运行失败时，为第一任务实例分配集群服务器中的第二服务器节点，用于再次运行第一任务实例；当至少一个任务实例的运行情况满足预设的结束条件时，确定第一任务的运行结果。

Description

任务处理方法、装置和设备及计算机存储介质
本申请要求于2024年06月12日提交中国专利局、申请号为202410753804.2、发明名称为“任务失败处理方法、装置和设备及计算机存储介质”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及计算机技术领域，具体涉及一种任务处理方法、装置和设备及计算机存储介质。
发明背景
在互联网科学技术的不断发展下，集群服务器这一概念越来越深入的影响到互联网技术的方方面面，已然存在越来越多的大规模的系统任务，需要集群服务器来执行。在大规模的系统任务的处理中，针对任务的调度与执行是一个重要的问题。特别是在任务之间存在依赖关系的场景下，某一个任务执行的顺利与否，会极大的影响整个系统任务流程是否能够顺利进行。
发明内容
本申请提供一种任务处理方法、装置和设备及计算机存储介质，用以提高任务纠错效率。
本申请实施例提供了一种任务处理方法，由集群服务器执行，包括：
接收任务运行指令，该任务运行指令至少包括：第一任务的至少一个任务实例相关的任务信息，以及运行第一任务所需的资源信息；
基于资源信息，分别为至少一个任务实例中的每个任务实例分配集群服务器中的一个第一服务器节点用于运行相应的任务实例；
当确定所述至少一个任务实例中的第一任务实例运行失败时，为第一任务实例分配集群服务器中的第二服务器节点用于再次运行第一任务实例；
当至少一个任务实例的运行情况满足预设的结束条件时，确定第一任务的运行结果。
本申请实施例还提供了一种任务处理装置，应用于集群服务器，包括：
接收模块，用于接收任务运行指令，该任务运行指令至少包括：第一任务至少一个任务实例相关的任务信息，以及运行第一任务所需的资源信息；
分配模块，用于基于资源信息，分别为至少一个任务实例中的每个任务实例分配集群服务器中的一个第一服务器节点用于运行相应的任务实例；
处理模块，用于当确定所述至少一个任务实例中的第一任务实例运行失败时，为第一任务实例分配集群服务器中的第二服务器节点用于再次运行第一任务实例；当至少一个任务实例的运行情况满足预设的结束条件时，确定第一任务的运行结果。
本申请实施例还提供一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时实现上述任一种方法的步骤。
本申请实施例还提供一种计算机存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述任一种方法的步骤。
本申请实施例还提出一种计算机程序产品，包括计算机程序，计算机程序被处理器执行时实现上述任一项的方法。
本申请实施例提供了一种任务处理方法，该方法应用于集群服务器，通过为任务对应的任务实例分配各自的服务器节点来运行，使得各个任务实例的运行状态都能被实时检查。当某个任务实例运行失败时，重新分配第二服务器节点再次运行该任务实例，以此排除偶发性因素导致的任务失败的情况，提高了任务运行的成功率。并且，在任务实例这一层级中进行错误重试工作，不必等整个任务执行完毕再进行重试，缩短了任务失败重试的时间，提高了任务执行效率。
附图简要说明
为了更清楚地说明本申请实施例或相关技术中的技术方案，下面将对实施例或相关技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。
图1A为各实施例的任务处理方法的概述流程图；
图1B为本申请实施例提供的应用场景示意图；
图2为本申请实施例提供的一种任务失败处理的方法的流程示意图；
图3为本申请实施例提供的一种为任务实例分配服务器节点的方法的逻辑示意图；
图4为本申请实施例提供的一种为运行失败的任务实例重新分配服务器节点的方法的逻辑示意图；
图5为本申请实施例提供的一种确认任务实例运行失败的方法的逻辑示意图；
图6为本申请实施例提供的一种任务之前存在的依赖关系的示意图；
图7为本申请实施例提供的一种运行任务实例的方法的流程图；
图8为本申请实施例提供的一种确定任务执行顺序的方法的逻辑示意图；
图9为本申请实施例提供的另一种确定任务执行顺序的方法的逻辑示意图；
图10为本申请实施例提供的一种为任务分配服务器资源的方法的逻辑示意图；
图11为本申请实施例提供的一种表征任务之间依赖关系的有向无环图的示意图；
图12为本申请实施例提供的另一种表征任务之间依赖关系的有向无环图的示意图；
图13为本申请实施例提供的一种作业、任务、任务实例之间的关系的结构图；
图14为本申请实施例提供的一种作业与任务之间的结构关系图；
图15为本申请实施例提供的一种创建作业与任务的展示界面的示意图；
图16为本申请实施例提供的一种任务失败处理方法的逻辑示意图；
图17为本申请实施例提供一种任务失败处理的装置的一种结构示意图；
图18为本申请实施例提供的计算机设备的组成结构示意图；
图19为应用本申请实施例的另一种计算机设备的组成结构示意图。
实施本发明的方式
为使本申请的目的、技术方案和优点更加清楚明白，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互任意组合。并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。
本申请实施例中，术语“模块”或“单元”是指有预定功能的计算机程序或计算机程序的一部分，并与其他相关部分一起工作以实现预定目标，并且可以通过使用软件、硬件(如处理电路或存储器)或其组合来全部或部分实现。同样的，一个处理器(或多个处理器或存储器)可以用来实现一个或多个模块或单元。此外，每个模块或单元都可以是包含该模块或单元功能的整体模块或单元的一部分。
在大规模的集群服务器中，任务的调度与运行是一个重要的问题，特别是在任务之间存在依赖关系的场景下，某一个任务执行的顺利与否，会极大的影响整个系统任务流程是否能够顺利进行。为了最大程度的避免一些偶发因素导致的任务运行失败的情况，通常情况下会将运行失败的任务重新运行。然而，这样的处理方式中，任务运行失败的判定需要依据任务中包含的若干任务实例的运行结果来作出，这就导致只有确定了所有任务实例的运行结果后，才能根据这些结果判断任务运行是否失败。因此，在相关技术中，需要耗费较长的等待时间，才能确定任务运行失败。另一方面，在重新运行任务时，该任务中的全部任务实例都需要再次运行，而第一次运行过程中运行成功的任务实例的再次运行，会导致较多计算资源被浪费。
有鉴于此，本申请实施例提供了一种任务处理方法(后文也称任务失败处理方法)，由集群服务器执行。图1A为各实施例的任务处理方法的概述流程图。当接收到任务运行指令(S11)后，集群服务器就可以根据指令中包括的目标任务(也即，待执行的任务，后文也称为当前任务或第一任务)的任务信息以及资源信息，获取第一任务所对应的至少一个任务实例，并分别为每个任务实例分配集群服务器中一个第一服务器节点(S12)，使得每个第一服务器节点对应一个任务实例，并在相应的第一服务器节点运行该任务实例。
各实施例中，任务是指对指定数据执行指定处理的工作，尤其是，大量数据的批处理工作。例如，在不同的场景下，任务可以包括图像数据处理(如用于自动驾驶的车载摄像头拍摄图像的实时分析和识别、医疗影像数据的分析和病变识别等)，用户数据处理(例如，电商平台的大量用户的行为数据分析，等)，日志数据处理(例如，某应用的服务器收集的大量设备中该应用的运行日志数据的实时分析和故障识别，等)。
任务实例是任务在执行时的实例化体现。任务通常包括对大量数据执行相同的一系列处理，任务在实际执行时，对某个数据执行这一系列处理就是该任务的一个实例。例如，批量图像数据处理任务中，可以创建多个任务实例，每个任务实例负责处理一部分图像数据。又例如，批量用户的行为数据分析任务中，每个任务实例负责处理一部分用户的行为数据。又例如，批量日志数据分析任务中，每个任务实例负责处理一部分日志数据。
各实施例中，服务器节点，也称为计算节点，是指用于执行特定任务实例的软件单元。在部署任务时，根据任务实例的需要分配计算节点，每个计算节点可以执行一个任务实例。分配计算节点时，可以根据任务实例的需要，为计算节点分配各种需要的资源，例如CPU资源、存储空间、网络资源，等。在任务实例执行完毕后，计算节点可以被释放或销毁。例如，计算节点可以是云计算技术中的虚拟机。又例如，计算节点可以是云计算技术中的容器。云计算技术中的容器是一种轻量级、可移植、自包含的软件部署单元，能将应用程序及其依赖项打包在一起，实现不同应用在同一环境中的隔离与高效运行。容器将应用程序及其运行所需的依赖项，如库、配置文件和运行时环境等，封装在一个独立的单元中，具有独立的运行环境。
在第一服务器节点运行各任务实例时，当确定一个第一服务器节点对应的第一任务实例运行失败时，就可以在集群服务器中，为运行失败的任务实例重新分配对应的第二服务器节点(S13)，以使该第二服务器节点再次运行相应的运行失败的任务实例。如此，每当该第一任务对应的任意一个任务实例出现运行失败的情况时，集群服务器就可以立刻重新运行相应的任务实例，以此排除偶发性因素导致的任务失败的情况，并且降低第一任务运行失败的可能性。这样，直到第一任务对应的至少一个任务实例的运行情况满足预设的结束条件时，集群服务器就可以确定第一任务的运行结果(S14)。在该方案中，通过为任务对应的任务实例分配各自的服务器节点来运行，使得各个任务实例的运行状态都能被实时检查。当某个任务实例运行失败时，重新分配第二服务器节点再次运行该任务实例，以此排除偶发性因素导致的任务失败的情况，提高了任务运行的成功率。并且，在任务实例这一层级中进行错误重试工作，不必等整个任务执行完毕再进行重试，缩短了任务失败重试的时间，提高了任务执行效率。
下面对本申请实施例的技术方案能够适用的应用场景做一些简单介绍，需要说明的是，以下介绍的应用场景仅用于说明本申请实施例而非限定。在具体实施过程中，可以根据实际需要灵活地应用本申请实施例提供的技术方案。
参见图1，为本申请实施例提供的一种应用场景示意图。如图1所示，在该场景中，可以包括了由多个服务器101构成的集群服务器。
服务器101可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、即内容分发网络(Content Delivery Network，CDN)、以及大数据和人工智能平台等基础云计算服务的云端服务器，但并不局限于此。
服务器101可以包括一个或多个处理器、存储器以及与用于进行交互的I/O接口等。此外，服务器101还配置数据库，可以用于存储本申请实施例提供的任务失败处理的方法中各自所需执行的程序指令，这些程序指令被处理器执行时能够用以实现本申请实施例提供的任务失败处理的过程。
本申请实施例中，各服务器101之间可以通过线缆连接完成通信操作，也可以通过一个或者多个通信网络102进行直接或间接的通信连接。该通信网络102可以是移动蜂窝网络，或者可以是无线保真(Wireless-Fidelity，WIFI)网络，当然还可以是其他可能的网络，本申请实施例对此不做限制。
需要说明的是，图1所示只是举例说明，实际上服务器的数量不受限制，在本申请实施例中不做具体限定。
参见图2，为本申请实施例提供的一种任务处理方法的流程图，该方法可以由如图1所示的集群服务器执行，例如由集群服务器中的任意服务器作为执行主体完成以下如图2所示的方法。该方法如下。
步骤S201：接收任务运行指令，该任务运行指令至少包括待执行的第一任务的任务信息，以及运行第一任务所需的资源信息。
如上所述，该任务失败处理方法由集群服务器执行，因此，在接收任务运行指令时，集群服务器中的任意一个服务器节点都可以接受该任务运行指令，或者集群服务器中可以存在一个服务器节点用于接收所有的任务运行指令，本申请对此不做限制。而为了更清晰地对本方案进行介绍，以下说明中将均会以集群服务器作为方法执行主体。
需要说明的是，任务运行指令中至少包括了第一任务的任务信息。该任务信息是第一任务的至少一个任务实例相关的信息。该任务信息中包括了：描述第一任务需要运行的副本数的信息，以及第一任务所需要对应生成的任务实例的信息。集群服务器可以根据该任务信息中副本数，为该第一任务生成对应数量的任务实例。同时，该任务信息中还包括有第一任务的一些必要信息等内容，例如，任务标识、任务描述等等，本申请对此不做限制。
另一方面，任务运行指令也包括了运行第一任务所需要的资源信息，集群服务器通过该资源信息可以为第一任务对应的各个任务实例分配计算资源满足第一任务要求的服务器节点，以运行各任务实例。
完成该任务运行指令的接收后，集群服务器即可执行如下操作：
步骤S202：基于任务信息，获取第一任务对应的至少一个任务实例。
为了便于理解第一任务与任务实例，以下将介绍第一任务与任务实例之间的关系。
一些实施例中，第一任务是开发者在任务开发界面上创建的任务，例如，用于集群管理的Spark任务，用于处理结构化数据的SparkSQL任务，或者数据同步任务等。这些任务在生成时，最主要的信息是描述应用程序的配置信息、运行环境、启动指令、信息输出配置等等。第一任务在开发过程中是静态的脚本，当其被提交到服务器执行时，在执行过程中就需要被抽象为任务实例。因此，可以明白，任务实例是根据任务创建出来并真正执行应用程序的对象，在第一任务中可以指定需要并发启动的任务实例的数量(也就是副本数)，并且所有的任务实例都以第一任务中的信息来创建和执行应用程序。
当集群服务器在接收到任务运行指令后，即可根据任务运行指令中的任务信息指示的任务副本数等信息，为第一任务生成对应数量的任务实例。这些任务实例用于并行运行第一任务的副本，以此实现第一任务整体的运行目标。
步骤S203：基于资源信息，分别为至少一个任务实例分配集群服务器中对应的第一服务器节点，以使各第一服务器节点运行相应的任务实例；其中，第一服务器节点与任务实例一一对应。
如图3所示，集群服务器获取到任务实例后，就可以基于资源信息中包括的对计算资源性能的要求，分别为各任务实例分配集群服务器中对应的第一服务器节点，这些第一服务器节点首先需要满足任务实例的运行性能要求，其次需要和各个任务实例一对一绑定，如此，在一个第一服务器节点中只运行一个任务实例，以达到第一服务器节点与任务实例一一对应的要求。
在为各个任务实例分配了合适的第一服务器节点后，集群服务器中的各第一服务器节点即可运行各个任务实例。在这些运行过程中，集群服务器可以对所有的第一服务器节点的运行状态进行实时检查，并根据每个第一服务器节点的运行状态，来判断接下来的执行步骤。
例如，服务器可以对各第一服务器节点运行的任务实例的运行状态进行判断，每确定一个第一服务器节点对应的任务实例运行失败时，针对运行任务实例失败的第一服务器节点执行如下操作。
步骤S204：在集群服务器中，为运行失败的任务实例重新分配对应的第二服务器节点，以使第二服务器节点重新运行相应的运行失败的任务实例。
在确定某个第一服务器节点的任务实例运行失败后，无需等待其它任务实例的结果反馈，集群服务器可以直接为该运行失败的任务实例重新分配服务器节点，进而再次运行该任务实例，以排除偶发性因素导致的任务实例运行失败的可能。
一些实施例中，对于任务实例运行失败后重新分配服务器节点这一步骤，根据任务实例运行失败的原因，集群服务器可以采用不同的方式实现任务实例的重新运行。
一种情况下，当任务实例已然在第一服务器节点开始运行，但是在运行过程中出现错误导致运行结果为运行失败时，集群服务器可以首先为该任务实例分配与第一服务器节点相同的服务器节点作为第二服务器节点，使得该任务实例重新在同一个第一服务器节点上重新运行。只有当再次运行后仍旧失败时，集群服务器才会再为该任务实例重新分配新的第二服务器节点，此时，该第二服务器节点为不同于第一服务器节点的新的服务器节点。
一种情况下，由于服务器资源分配失败导致该任务运行实例无法获得匹配的第一服务器节点，或者由于分配的服务器资源不匹配而导致任务实例未能开始运行，使得任务实例在运行开始之前就已然确定运行结果为运行失败时，集群服务器就可以为该任务实例分配一个不同于原第一服务器节点的第三服务器节点，使得该任务实例在新的第三服务器节点重新开始运行。该方式中，集群服务器首先确定了任务实例运行失败的原因，进而针对性地做出了重新分配新的第三服务器节点的方式，提高了任务错误重试后运行成功的概率。
例如，如图4所示，当接收任务运行指令的集群服务器为云服务器集群时，为任务实例分配的第一服务器节点可能因为网络波动的原因导致无法为任务实例提供运行环境，或者因为当前云服务器集群计算资源不足的原因而导致无法为任务实例直接分配第一服务器节点时，云服务器集群都可以创建新的服务器节点，作为分配至任务实例的第三服务器节点，以供该任务实例运行。
如此，集群服务器根据任务实例运行失败的不同情况，选择不同的方式为任务实例重新分配服务器节点，即为在对运行失败的错误有着预期的情况下，执行重分配，进一步地提高了任务实例错误重试后成功运行的概率。
以上介绍了集群服务器在针对一个任务实例执行的检查操作，而对于至少一个任务实例中的第二任务实例而言，集群服务器同样需要执行相应的查看操作以及可能的重新分配服务器节点的操作。
如此，直到集群服务器确定至少一个任务实例的运行情况满足了预设的结束条件时，集群服务器即可执行步骤S205：获得第一任务的运行结果。
其中，运行结果分为表征第一任务运行成功的运行结果，以及表征第一任务运行失败的运行结果。获得这两种运行结果的方式如下。
一些实施方式中，集群服务器可以根据第一任务在集群服务器中运行的全部任务实例的运行结果，获取第一任务的运行结果。
例如，集群服务器可以获取所有的任务实例的运行结果。当集群服务器确定所有的任务实例对应的运行结果均为成功运行，即可获得表征第一任务运行成功的运行结果；否则，获得表征第一任务运行失败的运行结果。
该方式是通过获取所有任务实例的运行结果来获取第一任务的运行结果，需要集群服务器确定第一任务对应的所有任务实例均成功运行后，才可以确定第一任务成功运行，而当所有的任务实例的运行结果中存在至少一个运行失败的结果时，集群服务器可以根据该情况确定第一任务运行失败。
另一些实施方式中，集群服务器可以根据所有的任务实例中的部分任务实例是否满足预设的结束条件，来直接对第一任务的整体运行结果进行判断。
一些实施例中，当集群服务器确定存在一个任务实例的重新运行次数达到次数阈值时，即可将该任务实例标记为运行失败，并获得表征第一任务运行失败的运行结果。
示例性的，如图5所示，假设集群服务器正在执行第一任务对应多个任务实例(即实例1、实例2、实例3以及实例4)，这4个任务实例的运行状态分别是：实例1、实例2、实例3三个任务实例在正常运行，且并没有完成运行结果，而实例4重新运行的次数已然达到了预设的次数阈值。此时，集群服务器确定该实例4的重新运行次数达到了次数阈值，就可以将该实例4标记为运行失败，同时，由于数据同步任务的4个实例中已然出现了运行失败的任务实例(即实例4)，集群服务器也可以同时确定该第一任务运行失败，而无需等待其它三个任务实例(实例1、实例2、实例3)完成运行。
在该方式中，集群服务器通过部分任务实例的运行情况即可确定任务的整体运行情况，无需较长的等待所有任务实例完成运行，提高了任务运行失败的确认效率。
一些实施例中，当集群服务器确定在第一任务对应的任务实例中，重新运行的任务实例与正常运行的任务实例的之间的比例，达到预设的比例阈值时，即可获得表征第一任务运行失败的运行结果。
示例性的，与上述类似，假设集群服务器正在运行的第一任务对应10个任务实例(即实例1-实例10)，这10个任务实例的运行状态为：存在6个任务实例已然重新运行了至少一次，此时任务重新运行的任务实例与正常运行的任务实例之间的比例，已然达到了比例阈值。因此，集群服务器即可直接确定该第一任务运行失败，进而无需等待全部的任务实例完成运行，并完成运行状态收集。
需要说明的是，上述几种第一任务的运行结果的获取方式可以同时存在，而具体的判断方式的确定，则可以通过触发速度的快慢确定。例如，假设集群服务器在确定所有的任务实例的运行结果之前，首先确定了存在一个任务实例的重新运行次数达到了次数阈值，此时集群服务器即可根据该重新运行次数打到了次数阈值的任务实例，来获取第一任务的运行结果。又例如，假设集群服务器首先确定了所有的任务实例中，重新运行了至少一次的任务实例与正常运行的任务实例的比例达到了比例阈值，集群服务器即可确定该第一任务的运行结果为表征第一任务运行失败。还例如，在集群服务器获取第一任务的全部任务实例的运行结果之前，既不存在达到次数阈值的任务实例，也不存在超过比例阈值的情况时，集群服务器即可根据全部任务实例的运行结果确定第一任务的运行结果。
另一方面，对于上述提出的次数阈值、比例阈值等数值的具体设置，都可以根据实际应用中开发者的需求进行设定，本申请对此不做限制。
在本方案中，该方法应用于集群服务器，通过将任务运行指令中包括的第一任务对应的任务实例，分配到不同的第一服务器节点进行运行，以确保每个任务实例都有各自对应的服务器节点进行运行，分担了单独服务器运行任务时所需的计算资源，在集群服务器中起到了平衡计算资源的目的。
同时，各个任务实例在第一服务器节点运行的过程中，其各自的运行状态都需要被检查，如此，每当确定某个第一服务器节点上运行的任务实例运行失败时，就可以在集群服务器中重新为运行失败的任务实例重新分配第二服务器节点，以使该第二服务器节点重新运行相应的运行失败的任务实例。因此，每当第一任务对应的任意一个任务实例出现运行失败的情况时，集群服务器就可以立刻重新运行相应的任务实例，以此排除偶发性因素导致的任务失败的情况，并且降低第一任务运行失败的可能性。
各实施例中，直到第一任务对应的至少一个任务实例的运行情况满足预设的结束条件时，集群服务器就可以获得第一任务的运行结果。在该方案中，集群服务器通过实时查看各个任务实例的运行状态，能够快速确定任务实例的错误的发生，并且，当确定错误发生时，在任务实例这一层级中进行错误重试工作，也能够快速的对偶发性错误进行排除，提高了任务运行的成功率。
以上介绍了针对任务运行指令中包含的一个第一任务可以执行的任务运行失败的方法。而当任务运行指令中包括了除第一任务以外的至少一个第二任务时，集群服务器还可以执行如下操作。
当任务运行指令中包括了除第一任务之外的至少一个第二任务时，该任务运行指令中还会包括：第二任务的任务信息以及运行第二任务需要的资源信息。
同时，第一任务以及至少一个第二任务之间运行时的依赖关系，也会包含在任务运行指令中。任务之间的依赖关系指的是一个任务在运行时，是否需要前置任务的运行结果，才能开始运行。示例性的，如图6所示，假设存在6个任务，分别为任务1-任务6，这6个任务之间的依赖关系就如图所示：任务1依赖任务2和任务5，任务2依赖任务3和任务4，任务3无依赖关系，任务4无依赖关系，任务5无依赖关系，任务6则依赖任务2。
在明确任务运行指令所包含的内容后，以下将继续介绍集群服务器所要执行的步骤。
参见图7，为本申请实施例提供的一种运行任务实例的方法的流程图，如图7所示，该方法具体实施步骤如下：
步骤S701：基于第一任务的任务信息以及至少一个第二任务的任务信息，获取第一任务以及至少一个第二任务对应的至少两个任务实例。
当任务运行指令中包含了多个任务之间的依赖关系时，在集群服务器的运行多个任务的过程中，可以首先获取各个任务对应的任务实例，如此，通过步骤S203，集群服务器即可为每个任务实例都分配其各自对应的第一服务器节点。
此时，由于各任务之间存在运行时的依赖关系，因此，集群服务器需要根据任务之间的依赖关系，来判断任务实例的先后运行顺序。例如，集群服务器可以执行如下操作。
步骤S702：基于第一任务与至少一个第二任务之间运行时的依赖关系，获取第一任务与至少一个第二任务对应的至少两个任务实例的运行顺序。
如图8所示，在获取到各个任务对应的任务实例后，集群服务器可以根据第一任务与第二任务之间的依赖关系，确定第一任务与第二任务之间的运行顺序，进而将该运行顺序叠加至各任务对应的任务实例中，以任务之间的执行顺序确定任务实例之间的执行顺序。
例如，假设任务运行指令中包含的第一任务与第二任务为图6中所示的6个任务，其中，第一任务为任务1，第二任务为任务2-任务6。那么对于第一任务与第二任务而言，其任务运行顺序即为：先并行运行任务3、任务4与任务5，然后基于任务3与任务4的结果再运行任务2，最后基于任务2与任务5的结果运行任务6与任务1。如此，在运行各个任务对应的任务实例时，则是依据上述任务之间的运行顺序，确定任务实例之间的运行顺序。
需要说明的是，在运行顺序中，除了存在依赖关系的任务实例外，还有可以并行运行的任务实例，例如，同一个任务对应的多个任务实例，或者可以并行运行的多个任务对应的多个任务实例。
步骤S703：基于运行顺序，依次运行第一任务以及至少一个第二任务对应的至少两个任务实例。
在确定了任务实例之间对应的运行顺序后，集群服务器即可根据该运行顺序，完成各任务实例的运行。
以上是根据第一任务与第二任务之间的运行顺序来直接确定任务实例的运行顺序进而判断各任务实例的运行时机。
在另一种可能的实施方式中，对于任务实例的运行时机，还可以直接通过任务实例的标识信息来确定。需要说明的是，在上述提出的第一任务与第二任务仅为名称上的区别，对于第一任务与第二任务而言，均是待运行任务中的一种，因此，以下将以任务统称第一任务与第二任务。
一些实施例中，在获取到任务运行指令中的第一任务与第二任务之间的依赖关系后，集群服务器即可首先判断每个任务是否存在前置任务；其中，前置任务为：当待运行任务需要第二任务的运行结果作为运行条件时，为待运行任务提供运行结果的任务即为该待运行任务的前置任务。
如图9所示，对于存在前置任务的任务而言，其可以被标记为准备中，对于不存在前置任务的任务而言，则可以将其标记为可运行。如此，确定了各个任务的执行标记后，每个任务对应的任务实例就可以继承对应任务的执行标记。即，被标记为准备中的任务对应的任务实例，需要被标记为准备中，被标记为可运行的任务对应的任务实例，则需要被标记为可运行。
在完成各个任务实例的执行标记的确定后，各服务器节点即可按照任务实例对应的执行标记，完成对各个任务实例的运行。
一些实施例中，当一个任务存在需要等待该任务的运行结果作为运行条件的后续任务时，集群服务器在确定该任务的运行结果为成功运行后，即可将该任务的运行结果传输至对应的后续任务，并将后续任务的执行标记修改为可执行。如此，后续任务对应的任务实例在继承了任务的执行标记后，任务实例对应的服务器节点即可基于任务实例执行标记的改变，开始运行对应的任务实例。
以上介绍了任务运行指令中存在多个任务时，运行任务实例的方式。而针对存在多个任务的任务运行指令，集群服务器还可以执行以下操作，来完成服务器节点的分配。
如图10所示，集群服务器在接收到任务运行指令后，即可基于任务运行指令中，第一任务以及至少一个第二任务对应的资源信息，分别为第一任务以及至少一个第二任务分配集群服务器中相关联的服务器资源。
如此，当集群服务器获取到各任务对应的任务实例后，针对第一任务与第二任务中的每个任务，集群服务器都可以继续执行以下操作：
获取至少一个任务实例对应的第一任务的服务器资源，并基于任务运行指令中，第一任务对应的资源信息，从上述相关联的服务器资源中分别为至少一个任务实例分配第一服务器节点。
这里，相关联的服务器资源是指硬件资源、软件资源或配置资源具有联系的服务器资源，例如，同区域高可用集群或直连服务器集群中的服务器资源，具有相同网络带宽资源的服务器资源，具有相同操作系统的服务器资源，具有相同安全设置的服务器资源，等。
通过为具有相互依赖关系的任务分配相关联的服务器资源，可以提高这些任务的执行效果，例如提高执行速度和效率，节约处理资源等。
需要说明的是，以上是为了便于说明，以第一任务对应的任务实例为例进行介绍。在实际应用中，上述方式可以应用于任务运行指令中的每一任务。
各实施例中，集群服务器为每个任务分配对应的服务器资源时，可以根据任务对应的资源信息中是否指定了预设运行环境这一内容，来执行不同的操作。
例如，当集群服务器确定第一任务以及所述至少一个第二任务对应的资源信息中，已指定预设运行环境时，分别为第一任务以及至少一个第二任务分配集群服务器中，预设运行环境对应的服务器资源。
当集群服务器确定第一任务以及所述至少一个第二任务对应的资源信息中，未指定预设运行环境时，则需要在集群服务器中创建对应的服务器资源，并为第一任务以及至少一个第二任务分配该新创建的服务器资源。
以上介绍了集群服务器接收到的任务指令中包含多个任务之间存在依赖关系集群服务器执行任务运行指令时的几种可能实施方式，而对于具体依赖关系的表现形式，则可以存在多种类型。
一些实施例中，任务之间的依赖关系可以分别记录在每个任务的配置信息中。例如，当一个任务存在前置任务以及后续任务时，可以在任务对应的任务信息中，记录该任务所需的前置任务的任务标识以及对应的后续任务的任务标识。如此，集群服务器在接收到任务运行指令后，即可根据各任务的任务信息，确定任务运行指令中的各任务之间的依赖关系。
另一些实施例中，任务之间的依赖关系可以单独地记录，然后使得任务运行指令包含该独立记录的任务之间的依赖关系，如此，集群服务器可以根据任务运行指令中包含的该内容直接确定任务运行指令中，各任务之间的依赖关系，进而确定执行任务实例的顺序。
示例性的，对于单独记录任务之间的依赖关系的内容，其形式可以采用有向无环图(DAG)这种数据结构。其中，有向无环图是由一系列顶点和连接顶点的边组成的数据结构；有向指的是：图中的边是有方向的，即A->B这条边和B->A是两条不同的边，而与之相对的无向则指的是：A->B和B->A是共用一条边的。无环指的是，从任意一个点出发，沿边的方向走下去时，不会回到原点。
当通过有向无环图表征任务之间的依赖关系时，有向无环图会包括至少两个目标节点以及至少一条边，且每个目标节点对应了第一任务和至少一个第二任务中的一个任务，每条边对应第一任务和至少一个第二任务中的两个任务之间的依赖关系。
示例性的，假设由通过有向无环图表征图6所示的6个任务之间的依赖关系，此时，有向无环图的具体表现形式如图11所示。其中，任务1-任务6每个任务都对应一个目标节点，而没有被连接的目标节点则表征了该目标节点对应的任务并无依赖关系。并且，图11中的每条边表征了两个任务之间存在依赖关系，其中每条边上的箭头表征了两个任务之间的依赖方向。
当集群服务器将任务的执行顺序延伸到任务对应的任务实例上时，任务运行指令所指示的多个任务之间的运行情况即可如图12所示。在图12中，包括了任务A-任务E，其中，任务A、任务B、任务D、和任务E均只对应了一个任务实例，任务C则对应了若干任务实例。因此，在图12所示的运行顺序中，任务运行的顺序从任务A开始，依次运行各个任务，且在运行任务C时可以并行运行若干任务实例。
以上介绍了任务运行指令包括多个任务时本申请实施例针对任务失败处理方法提供的一些可能的实施方式。为了集群服务器能够更加快速便捷的处理多个任务时的任务失败处理方法，本申请实施例还提供了以下针对多个任务运行时的处理方式。
各实施例中，如图13所示，在任务-任务实例这样的双层架构中，增加包含一个或多个任务的作业层级，从而形成作业-任务-任务实例这样的三层架构。在三层架构中，一个作业可以包括一个或多个任务，每个任务可以对应一个或多个任务实例。并且，作业对应的作业信息中，包括了作业中包含的任务所需的资源、副本数，同时还包括多个任务之间的依赖关系，确定各个任务的先后执行顺序。
需要说明的是，一个作业中所包含的任务的数量是不固定的，其中包含的任务之间运行顺序的关系也是不固定的，都可以由使用者的使用需求确定，本申请对此不做限制。示例性的，如图14所示，以多个作业中的一个为例，作业中包含任务的情况可以分别是单任务、并发任务或者是有执行顺序的多任务这三种。
如此，任务运行指令所包含的信息即可为上述作业对应的作业信息，该作业信息中包括了第一任务的任务信息与资源信息，以及可能存在的第二任务的任务信息与资源信息。并且，在该任务运行指令中，包含的第一任务与至少一个第二任务均对应一个作业。因此，在作业对应的作业信息中，还可以包括用于指示作业中的各任务对应的预设运行环境的信息。
而集群服务器在接收到包含作业的作业信息的任务运行指令后，在调度系统中先分解作业，形成对应的任务，然后每个任务根据各自的副本数生成对应数量的实例，并且将任务实例与服务器节点绑定，形成对应关系。然后通过各服务器节点运行相应的任务实例，最终获取到任务的运行结果。
各实施例中，在集群服务器接收上述任务运行指令之前，集群服务器可以为使用者提供几种对应的作业创建方式。集群服务器可以根据用户输入信息生成用于表征所述第一任务以及所述至少一个第二任务之间运行时的依赖关系的有向无环图的描述数据。
一些实施例中，集群服务器可以为使用者提供如图15所示的展示界面。该界面为一级界面，在一级界面中，左侧所展示任务图标可以由使用者点击，并进入相应的二级界面，二级界面中，使用者可以通过提示输入相应的任务信息以及资源信息，以此完成任务的创建。
一级界面的右侧则用于为使用者提供任务之间依赖关系的创建。例如，使用者可以根据提前创建的任务模板，在创建界面上拖拽不同的任务并按照实际需求连接任务，指定任务的先后顺序，以此形成相应的有向无环图。例如，用户通过输入的选择和/或拖拽操作，在界面上生成有向无环图，例如包括表征所述第一任务和所述第二任务的两个第一图形化显示元素，以及所述两个第一图形化显示元素之间的用于表征任务间依赖关系的第二图形化显示元素。相应地，集群服务器可以根据用户输入的有向无环图生成该有向无环图的描述数据。
另一些实施例中，集群服务器可以直接为使用者提供参数输入界面，如此，使用者在提交作业或者任务时，直接在提交参数中按照指定的模版添加对应的任务参数，最后由集群服务器根据相应的任务参数生成对应的有向无环图。例如，用户通过在界面中输入的预设的描述有向无环图的模板中的至少一个参数的值，相应地，集群服务器可以根据用户输入的参数值生成有向无环图的描述数据。
集群服务器可以利用各种可行的方式来记录有向无环图，例如用文本、表格、数组等作为有向无环图的描述数据，这里不再赘述。
通过图形化模块拖拽方式或模板参数输入方式根据用户输入生成任务的有向无环图，可以提高任务提交系统的易用性，提高作业的生成效率。
一些实施例中，在集群服务器完成上述任务运行的操作，获得了第一任务的运行结果后，还可以继续执行如下操作，即：
存储第一任务的运行结果，并释放第一任务包括的至少一个任务实例占用的服务器资源。
当完成第一任务的运行后，集群服务器即可存储该第一任务的运行结果，并且，由于错误重试这一过程已然在任务实例这一层级完成，因此，在面对已然获取到了运行结果的第一任务时，无论该运行结果是表征了运行成功还是运行失败，集群服务器都可以结束该第一任务的运行，并且释放第一任务包括的至少一个任务实例占用的服务器资源。
以上分别介绍了本申请实施例提供的任务失败处理方法中各种可能的实施方式的具体实施过程，需要说明的是，在实际应用中，上述各种实施方式可以通过不同的组合形成不同的方案。为了便于理解该组合的含义，以下将通过一个示例，对该内容进行介绍。
参见图16，为本申请实施例提供的一种任务失败处理的方法的逻辑示意图，如图16所示，在集群环境下，当使用者需要集群服务器运行多个任务时，使用者可以预先创建作业资源，在作业资源中再按照如图15所示的方法，依次创建各个需要运行的任务，并最终创建多个任务之间的依赖关系，以此完成作业资源的创建，并将创建出的作业上传至集群服务器，以此作为向集群服务器发送的任务运行指令。
相应的，集群服务器在接收到任务运行指令后，就需要从任务运行指令中，首先获取作业包含的多个任务的任务信息、资源信息以及各个任务之间的依赖关系，然后根据任务信息中的指示，为具有预设运行环境的任务分配对应的服务器资源，为不具有预设运行环境的任务创建合适的服务器资源。
接着，集群服务器根据各个任务的任务信息，生成每个任务对应的任务实例，并基于各任务各自的资源信息，为每个任务实例从对应的服务器资源中，分配合适的第一服务器节点。同时，根据各个任务之间的依赖关系，集群服务器可以确认多个任务之间的运行顺序，并将此顺序延伸到各个任务实例上，使得各任务实例能够按照任务之间的依赖关系完成各自的运行。
与此同时，集群服务器可以查看每个服务器节点上任务实例的运行情况，每确定一个第一服务器节点对应的任务实例运行失败时，就在集群服务器中，为运行失败的任务实例重新分配对应的第二服务器节点，使得该第二服务器节点重新运行相应的任务失败的任务实例。
集群服务器需要持续执行这些对服务器节点的查看操作以及对应的重试操作，直到至少一个任务实例的运行情况满足预设的结束条件时，集群服务器即可获取第一任务的运行结果。
基于同一发明构思，本申请实施例还提供了一种任务失败处理的装置，参见图17，为本申请实施例提供的一种任务失败处理的装置的结构示意图，该装置应用于集群服务器，可以是上述服务器或者是其中的芯片或集成电路等，该装置包括用于执行上述方法实施例中由服务器执行的方法的模块/单元/技术手段。
示例性的，该装置1700包括：
接收模块1701，用于接收任务运行指令，任务运行指令至少包括：第一任务的任务信息，以及运行第一任务所需的资源信息；
分配模块1702，用于基于任务信息，获取第一任务对应的至少一个任务实例；基于资源信息，分别为至少一个任务实例分配集群服务器中对应的第一服务器节点，以使各第一服务器节点运行相应的任务实例；其中，第一服务器节点与任务实例一一对应；
处理模块1703，用于每确定一个第一服务器节点对应的任务实例运行失败时，在集群服务器中，为运行失败的任务实例重新分配对应的第二服务器节点，以使第二服务器节点重新运行相应的运行失败的任务实例，直到至少一个任务实例的运行情况满足预设的结束条件时，获得第一任务的运行结果。
一种可能的实施方式中，任务运行指令还包括：至少一个第二任务的任务信息，运行至少一个第二任务所需的资源信息，以及，第一任务以及至少一个第二任务之间运行时的依赖关系；分配模块1702用于基于任务信息，获取第一任务对应的至少一个任务实例时，具体用于：
基于第一任务的任务信息以及至少一个第二任务的任务信息，获取第一任务以及至少一个第二任务对应的至少两个任务实例；
则分配集群服务器中对应的第一服务器节点之后，分配模块1702还用于：
基于第一任务与至少一个第二任务之间运行时的依赖关系，获取第一任务与至少一个第二任务对应的至少两个任务实例的运行顺序；
基于运行顺序，依次运行第一任务以及至少一个第二任务对应的至少两个任务实例。
一种可能的实施方式中，分配模块1702用于基于任务信息，获取第一任务对应的至少一个任务实例之前时，具体用于：
基于第一任务以及至少一个第二任务对应的资源信息，分别为第一任务以及至少一个第二任务分配集群服务器中的服务器资源；
则分配模块1702用于基于资源信息，分别为至少一个任务实例分配集群服务器中对应的第一服务器节点时，具体用于：
获取至少一个任务实例对应的第一任务的服务器资源；
基于任务运行指令中的资源信息，分别为至少一个任务实例分配服务器资源中对应的第一服务器节点。
一种可能的实施方式中，分配模块1702用于基于第一任务以及至少一个第二任务对应的资源信息，分别为第一任务以及至少一个第二任务分配集群服务器中的服务器资源时，具体用于：
当第一任务以及至少一个第二任务对应的资源信息中，已指定预设运行环境时，分别为第一任务以及至少一个第二任务分配集群服务器中，预设运行环境对应的服务器资源；
当第一任务以及至少一个第二任务对应的资源信息中，未指定预设运行环境时，在集群服务器中创建对应的服务器资源，并为第一任务以及至少一个第二任务分配服务器资源。
一种可能的实施方式中，第一任务以及至少一个第二任务之间运行时的依赖关系通过有向无环图表征；
其中，有向无环图中包含：至少两个目标节点以及至少一条边；每个目标节点对应第一任务和至少一个第二任务中的一个任务，每条边对应第一任务和至少一个第二任务中的两个任务之间的依赖关系。
一种可能的实施方式中，处理模块1703用于直到至少一个任务实例的运行情况满足预设的结束条件时，获得第一任务的运行结果时，具体用于：
当存在一个任务实例的重新运行次数达到次数阈值时，将一个任务实例标记为运行失败，并获得表征第一任务运行失败的运行结果；
当至少一个任务实例均成功运行时，获得表征第一任务运行成功的运行结果。
一种可能的实施方式中，每次运行任务实例时，处理模块1703还用于：
当确定任务实例未能开始运行，则为任务实例分配第三服务器节点，以使第三服务器节点运行任务实例；其中，三服务器节点为集群服务器中除任务实例对应的第一服务器节点以外的服务器节点。
一种可能的实施方式中，获得第一任务的运行结果之后，处理模块1703还用于：
存储第一任务的运行结果；
释放第一任务包括的至少一个任务实例占用的服务器资源。
该装置可以用于执行本申请各实施例中所示的方法，因此，对于该装置的各功能模块所能够实现的功能等可参考前述实施例的描述，不多赘述。
请参见图18，基于同一技术构思，本申请实施例还提供了一种计算机设备。在一种实施例中，该计算机设备可以为图1所示的服务器，该计算机设备如图18所示，包括存储器1801，通讯模块1803以及一个或多个处理器1802。
存储器1801，用于存储处理器1802执行的计算机程序。存储器1801可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统，以及运行本申请实施例的功能所需的程序等；存储数据区可存储各种即时通讯信息和操作指令集等。
存储器1801可以是易失性存储器(volatile memory)，例如随机存取存储器(random-access memory，RAM)；存储器1801也可以是非易失性存储器(non-volatile memory)，例如只读存储器，快闪存储器(flash memory)，硬盘(hard disk drive，HDD)或固态硬盘(solid-state drive，SSD)；或者存储器1801是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器1801可以是上述存储器的组合。
处理器1802，可以包括一个或多个中央处理单元(central processing unit，CPU)或者为数字处理单元等等。处理器1802，用于调用存储器1801中存储的计算机程序时实现上述任务失败处理的方法。
通讯模块1803用于与终端设备和其他服务器进行通信。
本申请实施例中不限定上述存储器1801、通讯模块1803和处理器1802之间的具体连接介质。本申请实施例在图18中以存储器1801和处理器1802之间通过总线1804连接，总线1804在图18中以粗线描述，其它部件之间的连接方式，仅是进行示意性说明，并不引以为限。总线1804可以分为地址总线、数据总线、控制总线等。为便于描述，图18中仅用一条粗线描述，但并不描述仅有一根总线或一种类型的总线。
存储器1801中存储有计算机存储介质，计算机存储介质中存储有计算机可执行指令，计算机可执行指令用于实现本申请实施例的任务失败处理的方法，处理器1802用于执行上述各实施例的任务失败处理的方法。
在另一种实施例中，计算机设备也可以是终端设备，如图1所示的终端设备。在该实施例中，计算机设备的结构可以如图19所示，包括：通信组件1910、存储器1920、显示单元1930(例如显示屏1932、触摸屏1931)、摄像头1940、传感器1950(如加速度传感器1951、距离传感器1952、指纹传感器1953、温度传感器1954)、音频电路1960(例如与扬声器1961、传声器1962相连)、蓝牙模块1970、处理器1980等部件。
基于同一发明构思，本申请实施例还提供一种存储介质，该存储介质存储有计算机程序，当该计算机程序在计算机上运行时，使得计算机执行本说明书上述描述的根据本申请各种示例性实施方式的任务失败处理的方法中的步骤。
在一些可能的实施方式中，本申请提供的任务失败处理的方法的各个方面还可以实现为一种计算机程序产品的形式，其包括计算机程序，当程序产品在计算机设备上运行时，计算机程序用于使计算机设备执行本说明书上述描述的根据本申请各种示例性实施方式的任务失败处理的方法中的步骤，例如，计算机设备可以执行各实施例的步骤。
程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以是但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。
本申请的实施方式的程序产品可以采用便携式紧凑盘只读存储器(CD-ROM)并包括计算机程序，并可以在计算机设备上运行。然而，本申请的程序产品不限于此，在本申请件中，可读存储介质可以是任何包含或存储程序的有形介质，其包括的计算机程序可以被命令执行系统、装置或者器件使用或者与其结合使用。
可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读计算机程序。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由命令执行系统、装置或者器件使用或者与其结合使用的程序。
可读介质上包含的计算机程序可以用任何适当的介质传输，包括但不限于无线、有线、光缆、RF等等，或者上述的任意合适的组合。
可以以一种或多种程序设计语言的任意组合来编写用于执行本申请操作的计算机程序，程序设计语言包括面向对象的程序设计语言，诸如Java、C++等，还包括常规的过程式程序设计语言，诸如“C”语言或类似的程序设计语言。
应当注意，尽管在上文详细描述中提及了装置的若干单元或子单元，但是这种划分仅仅是示例性的并非强制性的。实际上，根据本申请的实施方式，上文描述的两个或更多单元的特征和功能可以在一个单元中具体化。反之，上文描述的一个单元的特征和功能可以进一步划分为由多个单元来具体化。
此外，尽管在附图中以特定顺序描述了本申请方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。
本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。
尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。
显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (19)

  1. 一种任务处理方法，由集群服务器执行，包括：
    接收任务运行指令，所述任务运行指令包括：第一任务的至少一个任务实例相关的任务信息，以及运行所述第一任务所需的资源信息；
    基于所述资源信息，分别为所述至少一个任务实例中的每个任务实例分配所述集群服务器中的一个第一服务器节点用于运行相应的任务实例；
    当确定所述至少一个任务实例中的第一任务实例运行失败时，为所述第一任务实例分配所述集群服务器中的第二服务器节点用于再次运行所述第一任务实例；
    当所述至少一个任务实例的运行情况满足预设的结束条件时，确定所述第一任务的运行结果。
  2. 如权利要求1所述的方法，其中，所述任务运行指令进一步包括：至少一个第二任务的任务信息，运行所述至少一个第二任务所需的资源信息，以及，所述第一任务与所述至少一个第二任务在运行时的依赖关系；
    所述方法进一步包括：
    基于所述依赖关系确定所述第一任务与所述至少一个第二任务的至少两个任务实例的运行顺序；
    基于所述运行顺序，依次运行所述至少两个任务实例。
  3. 如权利要求2所述的方法，进一步包括：
    基于所述第一任务对应的资源信息以及所述至少一个第二任务对应的资源信息，分别为所述第一任务以及所述至少一个第二任务分配所述集群服务器中相关联的服务器资源；
    则所述基于所述资源信息，分别为所述至少一个任务实例分配所述集群服务器中对应的第一服务器节点，包括：
    基于所述任务运行指令中的资源信息，从所述相关联的服务器资源中分别为所述至少一个任务实例分配第一服务器节点。
  4. 如权利要求2所述的方法，其中，进一步包括：
    当所述第一任务以及所述至少一个第二任务对应的资源信息中，已指定预设运行环境时，在所述集群服务器中分别为所述第一任务以及所述至少一个第二任务分配所述预设运行环境对应的服务器资源；
    当所述第一任务以及所述至少一个第二任务对应的资源信息中，未指定预设运行环境时，在所述集群服务器中创建对应的服务器资源，并为所述第一任务以及所述至少一个第二任务分配所述服务器资源。
  5. 如权利要求2所述的方法，进一步包括，
    根据用户输入信息生成用于表征所述第一任务以及所述至少一个第二任务之间运行时的依赖关系的有向无环图的描述数据；
    其中，所述有向无环图中包括：至少两个节点以及至少一条边；每个节点对应所述第一任务和所述至少一个第二任务中的一个任务，每条边对应所述第一任务和所述至少一个第二任务中的两个任务之间的依赖关系；
    其中，所述用户输入信息包括以下中的至少一个：
    表征所述第一任务和所述第二任务的两个第一图形化显示元素，以及所述两个第一图形化显示元素之间的用于表征任务间依赖关系的第二图形化显示元素；
    预设的描述有向无环图的模板中的至少一个参数的值。
  6. 如权利要求1-5任一项所述的方法，其中，所述直到所述至少一个任务实例的运行情况满足预设的结束条件时，获得第一任务的运行结果，包括：
    当存在一个任务实例的重新运行次数达到次数阈值时，将所述一个任务实例标记为运行失败，并获得表征所述第一任务运行失败的运行结果；
    当所述至少一个任务实例均成功运行时，获得表征所述第一任务运行成功的运行结果。
  7. 如权利要求6所述的方法，进一步包括：
    当确定第二任务实例未能开始运行，则为所述第二任务实例分配第三服务器节点用于运行所述任务实例；其中，所述三服务器节点为所述集群服务器中与所述第二任务实例对应的第一服务器节点不同的服务器节点。
  8. 如权利要求1-5任一项所述的方法，进一步包括：
    存储所述第一任务的运行结果；
    释放所述第一任务对应的至少一个任务实例占用的服务器资源。
  9. 一种任务处理装置，其中，应用于集群服务器，包括：
    接收模块，用于接收任务运行指令，所述任务运行指令包括：第一任务的至少一个任务实例相关的任务信息，以及运行所述第一任务所需的资源信息；
    分配模块，用于基于所述资源信息，分别为所述至少一个任务实例中的每个任务实例分配所述集群服务器中的一个第一服务器节点用于运行相应的任务实例；
    处理模块，用于当确定所述至少一个任务实例中的第一任务实例运行失败时，为运行所述第二任务实例分配所述集群服务器中的第二服务器节点用于运行所述第二任务实例；当所述至少一个任务实例的运行情况满足预设的结束条件时，确定所述第一任务的运行结果。
  10. 如权利要求9所述的装置，其中，所述任务运行指令进一步包括：至少一个第二任务的任务信息，运行所述至少一个第二任务所需的资源信息，以及，所述第一任务与所述至少一个第二任务在运行时的依赖关系；
    所述分配模块进一步用于：
    基于所述依赖关系确定所述第一任务与所述至少一个第二任务的至少两个任务实例的运行顺序；
    基于所述运行顺序，依次运行所述至少两个任务实例。
  11. 如权利要求10所述的装置，其中，所述分配模块进一步用于：
    基于所述第一任务对应的资源信息以及所述至少一个第二任务对应的资源信息，分别为所述第一任务以及所述至少一个第二任务分配所述集群服务器中相关联的服务器资源；
    则所述基于所述资源信息，分别为所述至少一个任务实例分配所述集群服务器中对应的第一服务器节点，包括：
    基于所述任务运行指令中的资源信息，从所述相关联的服务器资源中分别为所述至少一个任务实例分配第一服务器节点。
  12. 如权利要求10所述的装置，其中，所述分配模块进一步用于：
    当所述第一任务以及所述至少一个第二任务对应的资源信息中，已指定预设运行环境时，在所述集群服务器中分别为所述第一任务以及所述至少一个第二任务分配所述预设运行环境对应的服务器资源；
    当所述第一任务以及所述至少一个第二任务对应的资源信息中，未指定预设运行环境时，在所述集群服务器中创建对应的服务器资源，并为所述第一任务以及所述至少一个第二任务分配所述服务器资源。
  13. 如权利要求10所述的装置，其中，所述接收模块进一步用于：
    根据用户输入信息生成用于表征所述第一任务以及所述至少一个第二任务之间运行时的依赖关系的有向无环图的描述数据；
    其中，所述有向无环图中包括：至少两个节点以及至少一条边；每个节点对应所述第一任务和所述至少一个第二任务中的一个任务，每条边对应所述第一任务和所述至少一个第二任务中的两个任务之间的依赖关系；
    其中，所述用户输入信息包括以下中的至少一个：
    表征所述第一任务和所述第二任务的两个第一图形化显示元素，以及所述两个第一图形化显示元素之间的用于表征任务间依赖关系的第二图形化显示元素；
    预设的描述有向无环图的模板中的至少一个参数的值。
  14. 如权利要求9-13任一项所述的装置，其中，所述处理模块进一步用于：
    当存在一个任务实例的重新运行次数达到次数阈值时，将所述一个任务实例标记为运行失败，并获得表征所述第一任务运行失败的运行结果；
    当所述至少一个任务实例均成功运行时，获得表征所述第一任务运行成功的运行结果。
  15. 如权利要求14所述的装置，其中，所述处理模块进一步用于：
    当确定第二任务实例未能开始运行，则为所述第二任务实例分配第三服务器节点用于运行所述任务实例；其中，所述三服务器节点为所述集群服务器中与所述第二任务实例对应的第一服务器节点不同的服务器节点。
  16. 如权利要求9-13任一项所述的装置，其中，所述处理模块进一步用于：
    存储所述第一任务的运行结果；
    释放所述第一任务对应的至少一个任务实例占用的服务器资源。
  17. 一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述计算机程序时实现权利要求1-8中的任一项所述方法的步骤。
  18. 一种计算机存储介质，其上存储有计算机程序，其中，该计算机程序被处理器执行时实现权利要求1-8中的任一项所述方法的步骤。
  19. 一种计算机程序产品，包括计算机程序，其中，所述计算机程序被处理器执行时实现如权利要求1-8中的任一项所述的方法的步骤。
PCT/CN2025/089242 2024-06-12 2025-04-16 任务处理方法、装置和设备及计算机存储介质 Pending WO2025256261A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202410753804.2A CN118860703A (zh) 2024-06-12 2024-06-12 任务失败处理方法、装置和设备及计算机存储介质
CN202410753804.2 2024-06-12

Publications (1)

Publication Number Publication Date
WO2025256261A1 true WO2025256261A1 (zh) 2025-12-18

Family

ID=93163589

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2025/089242 Pending WO2025256261A1 (zh) 2024-06-12 2025-04-16 任务处理方法、装置和设备及计算机存储介质

Country Status (2)

Country Link
CN (1) CN118860703A (zh)
WO (1) WO2025256261A1 (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN118860703A (zh) * 2024-06-12 2024-10-29 腾讯云计算（北京）有限责任公司 任务失败处理方法、装置和设备及计算机存储介质
CN119835270A (zh) * 2024-12-11 2025-04-15 中电信智能网络科技有限公司 任务的执行方法、装置、电子设备及非易失性存储介质
CN120123066A (zh) * 2025-05-12 2025-06-10 中电云计算技术有限公司 数据同步方法、装置、电子设备和存储介质

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160098292A1 (en) * 2014-10-03 2016-04-07 Microsoft Corporation Job scheduling using expected server performance information
CN111078396A (zh) * 2019-11-22 2020-04-28 厦门安胜网络科技有限公司 一种基于多任务实例的分布式数据接入方法和系统
CN113032125A (zh) * 2021-04-02 2021-06-25 京东数字科技控股股份有限公司 作业调度方法、装置、计算机系统和计算机可读存储介质
WO2021227999A1 (zh) * 2020-05-11 2021-11-18 中兴通讯股份有限公司 云计算服务系统和方法
US20220027205A1 (en) * 2020-07-27 2022-01-27 International Business Machines Corporation Service retention in a computing environment
CN118860703A (zh) * 2024-06-12 2024-10-29 腾讯云计算（北京）有限责任公司 任务失败处理方法、装置和设备及计算机存储介质

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110941446B (zh) * 2019-11-06 2021-06-18 深圳市云网万店科技有限公司 基于多环境离线任务的版本发布方法及装置

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160098292A1 (en) * 2014-10-03 2016-04-07 Microsoft Corporation Job scheduling using expected server performance information
CN111078396A (zh) * 2019-11-22 2020-04-28 厦门安胜网络科技有限公司 一种基于多任务实例的分布式数据接入方法和系统
WO2021227999A1 (zh) * 2020-05-11 2021-11-18 中兴通讯股份有限公司 云计算服务系统和方法
US20220027205A1 (en) * 2020-07-27 2022-01-27 International Business Machines Corporation Service retention in a computing environment
CN113032125A (zh) * 2021-04-02 2021-06-25 京东数字科技控股股份有限公司 作业调度方法、装置、计算机系统和计算机可读存储介质
CN118860703A (zh) * 2024-06-12 2024-10-29 腾讯云计算（北京）有限责任公司 任务失败处理方法、装置和设备及计算机存储介质

Also Published As

Publication number Publication date
CN118860703A (zh) 2024-10-29

Similar Documents

Publication Publication Date Title
US11456914B2 (en) Implementing affinity and anti-affinity with KUBERNETES
US11271895B1 (en) Implementing advanced networking capabilities using helm charts
US9582312B1 (en) Execution context trace for asynchronous tasks
US8656387B2 (en) Method and system for workload distributing and processing across a network of replicated virtual machines
CN111061432B (zh) 一种业务迁移方法、装置、设备及可读存储介质
JP7241713B2 (ja) オペレータ管理装置、オペレータ管理方法及びオペレータ管理コンピュータープログラム
CN108572845B (zh) 分布式微服务集群的升级方法及相关系统
US12493486B2 (en) Device health driven migration of applications and its dependencies
US20190146847A1 (en) Dynamic distributed resource management
US8086900B2 (en) System, method and computer program product for testing a boot image
CN107025135B (zh) Docker容器内应用进程管理方法、装置和介质
US8205207B2 (en) Method of automated resource management in a partition migration capable environment
KR101751515B1 (ko) 테스트 실행 장치, 방법 및 컴퓨터 프로그램
CN114546644B (zh) 集群资源调度方法、装置、软件程序、电子设备及存储介质
CN114816662A (zh) 应用于Kubernetes的容器编排方法和系统
CN118860703A (zh) 任务失败处理方法、装置和设备及计算机存储介质
US20180113750A1 (en) Container-based distributed application management system and method
US20240152371A1 (en) Dynamic re-execution of parts of a containerized application pipeline
CN111857951A (zh) 容器化部署平台及部署方法
CN106126419A (zh) 一种应用程序的调试方法及装置
US20250365251A1 (en) Recovering an application stack from a primary region to a standby region using a recovery protection group
KR20250012112A (ko) 자원 할당 방법 및 장치와 인공지능 훈련 시스템
CN112148348A (zh) 任务处理方法、装置及存储介质
WO2025236543A1 (zh) 用于资源管理的方法、装置、设备和存储介质
US20250077365A1 (en) Recovering an application stack from a primary region to a standby region using a recovery protection group

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 25820941

Country of ref document: EP

Kind code of ref document: A1