Task execution methods and apparatus, electronic devices, computer-readable storage media

Abstract

This disclosure relates to a task execution method and apparatus, electronic device, and computer-readable storage medium. The task execution method includes: retrieving tasks to be executed from a task queue; retrieving the number of heartbeat times in a status queue that are less than a predetermined time from the current time, wherein the status queue stores the heartbeat times of tasks that have already started execution and the heartbeat times are periodically updated according to the execution status of the tasks; and, if the number of heartbeat times is less than the maximum number of tasks that can be executed in parallel globally, invoking idle downstream resources to execute the tasks to be executed.

Description

Technical Field

[0001] This disclosure relates to the field of computers, and more particularly to a task execution method and apparatus, electronic device, and computer-readable storage medium. Background Technology

[0002] In backend services, a mismatch often arises between production and consumption capabilities. For example, a platform might need to transcode videos after upload to provide a smoother playback experience. In this case, uploading is the producer, and video transcoding is the consumer. A minute-long video can typically be uploaded in seconds, while video transcoding often takes minutes or even hours. In this situation, the producer and consumer capabilities are at different levels. To avoid limiting user uploads due to transcoding capacity lagging behind upload capacity, backend services generally use task queues to decouple production and consumption. In this scenario, the producer, after uploading, places the video transcoding request (i.e., the transcoding task for the uploaded video) into a task queue (such as a Kafka message queue). Additionally, a consumer service implementing video transcoding (i.e., the consumer) is deployed to process the tasks in the task queue, achieving decoupling and resolving the capability mismatch issue.

[0003] Currently, when deploying multiple servers for task processing (corresponding to consumer roles), the same concurrency control limit is set for each server, and downstream resources are pre-allocated evenly. However, this approach has two drawbacks. First, there are idle servers—servers that do not process tasks—leaving their allocated downstream resources idle and underutilized. Second, when a server abnormally exits, the other servers are unaware, and the downstream resources of the abnormally exiting server are not released, again resulting in underutilization of downstream resources. This leads to increased task queuing time, a deteriorated user experience, and increased costs. Summary of the Invention

[0004] This disclosure provides a task execution method and apparatus, electronic device, and computer-readable storage medium to at least solve the problem that downstream resources cannot be fully utilized due to related technologies.

[0005] According to a first aspect of the present disclosure, a task execution method is provided, comprising: obtaining a task to be executed from a task queue; obtaining the number of heartbeat times in a status queue that are less than a predetermined time away from the current time, wherein the status queue stores the heartbeat times of tasks that have already started execution and the heartbeat times are periodically updated according to the execution status of the tasks; and, if the number of heartbeat times is less than the maximum number of tasks to be executed globally in parallel, calling idle downstream resources to execute the task to be executed.

[0006] Optionally, if the number of heartbeat times equals the maximum number of tasks, continue to acquire the number of heartbeat times in the status queue that are less than the predetermined time from the current time until the number of heartbeat times is less than the maximum number of tasks, and then call idle downstream resources to execute the tasks to be executed.

[0007] Optionally, before obtaining the number of heartbeat times in the status queue that are less than a predetermined time away from the current time, the method further includes: periodically querying the execution status of tasks that have already started executing; if a task that has already started executing is currently executing, then updating the heartbeat time of the task that has already started executing in the status queue; if a task that has already started executing is not currently executing, then stopping the updating of the heartbeat time of the task that has already started executing in the status queue.

[0008] Optionally, after invoking idle downstream resources to execute the task to be executed, the method further includes:

[0009] The time when downstream resources begin executing pending tasks is used as the heartbeat time of the pending tasks and added to the status queue.

[0010] Optionally, after calling an idle downstream resource to execute the task to be executed, the method further includes: deleting the heartbeat time of the task to be executed from the status queue after the task to be executed has been completed.

[0011] Optionally, before retrieving the task to be executed from the task queue, the method further includes: determining the task to be executed corresponding to the uploaded data; and sending the task to be executed corresponding to the data to the task queue.

[0012] According to a second aspect of the present disclosure, a task execution apparatus is provided, comprising: a task acquisition unit configured to acquire tasks to be executed from a task queue; a task quantity acquisition unit configured to acquire the number of heartbeat times in a status queue that are less than a predetermined time from the current time, wherein the status queue stores the heartbeat times of tasks that have already started execution and the heartbeat times are periodically updated according to the execution status of the tasks; and an execution unit configured to invoke idle downstream resources to execute the tasks to be executed when the number of heartbeat times is less than the maximum number of tasks to be executed in parallel globally.

[0013] Optionally, the execution unit is also configured to continue acquiring the number of heartbeat times in the status queue that are less than a predetermined time away from the current time, provided that the number of heartbeat times is equal to the maximum number of tasks, until the number of heartbeat times is less than the maximum number of tasks, and then call idle downstream resources to execute the tasks to be executed.

[0014] Optionally, the task count acquisition unit is further configured to periodically query the execution status of tasks that have already started executing before acquiring the number of heartbeat times in the status queue that are less than a predetermined time away from the current time; if a task that has already started executing is currently executing, then update the heartbeat time of the task that has already started executing in the status queue; if a task that has already started executing is not currently executing, then stop updating the heartbeat time of the task that has already started executing in the status queue.

[0015] Optionally, the execution unit is also configured to add the time when the downstream resource starts executing the task to be executed as the heartbeat time of the task to be executed to the status queue after calling an idle downstream resource to execute the task to be executed.

[0016] Optionally, the execution unit is also configured to remove the heartbeat time of the pending task from the status queue after the pending task has been executed, following the invocation of idle downstream resources to execute the pending task.

[0017] Optionally, the task acquisition unit is configured to determine the task to be executed corresponding to the uploaded data based on the uploaded data before acquiring the task to be executed from the task queue; and to send the task to be executed corresponding to the data to the task queue.

[0018] According to a third aspect of the present disclosure, an electronic device is provided, comprising: a processor; and a memory for storing processor-executable instructions; wherein the processor is configured to execute instructions to implement a task execution method according to the present disclosure.

[0019] According to a fourth aspect of the present disclosure, a computer-readable storage medium is provided that, when instructions in the computer-readable storage medium are executed by at least one processor, causes at least one processor to perform the task execution method as described above according to the present disclosure.

[0020] According to a fifth aspect of the present disclosure, a computer program product is provided, including computer instructions that, when executed by a processor, implement a task execution method according to the present disclosure.

[0021] The technical solutions provided by the embodiments of this disclosure bring at least the following beneficial effects:

[0022] According to the task execution method, apparatus, electronic device, and computer-readable storage medium disclosed herein, a state queue is added to store the heartbeat time of tasks that have started execution. The heartbeat time is periodically updated based on the task execution status. This allows the number of globally executing valid tasks to be obtained from the state queue. Based on this number of valid tasks and the maximum number of tasks that can be processed in parallel globally, it is determined whether there are idle downstream resources available to execute pending tasks. This enables full utilization of downstream resources, improves downstream resource utilization, reduces task queuing time, lowers user waiting time, and enhances user experience. Therefore, this disclosure solves the problem of insufficient utilization of downstream resources caused by related technologies.

[0023] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

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

[0025] Figure 1 This is a schematic diagram illustrating an implementation scenario of a task execution method according to an exemplary embodiment of the present disclosure;

[0026] Figure 2 This is a flowchart illustrating a task execution method according to an exemplary embodiment;

[0027] Figure 3 This is a schematic diagram of the overall flow of a task execution method according to an exemplary embodiment;

[0028] Figure 4 This is a block diagram illustrating a task execution device according to an exemplary embodiment;

[0029] Figure 5 This is a block diagram of an electronic device 500 according to an embodiment of the present disclosure. Detailed Implementation

[0030] To enable those skilled in the art to better understand the technical solutions of this disclosure, the technical solutions in the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings.

[0031] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following examples do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0032] It should be noted that the phrase "at least one of several items" in this disclosure refers to three parallel cases: "any one of the several items", "a combination of any number of the several items", and "all of the several items". For example, "including at least one of A and B" includes the following three parallel cases: (1) including A; (2) including B; (3) including A and B. As another example, "performing at least one of step one and step two" indicates the following three parallel cases: (1) performing step one; (2) performing step two; (3) performing both step one and step two.

[0033] To address the aforementioned issues, this disclosure provides a task execution method that can fully utilize downstream resources. The following example illustrates this method using video upload and transcoding as an example.

[0034] Figure 1 This is a schematic diagram illustrating an implementation scenario of a task execution method according to an exemplary embodiment of the present disclosure, such as... Figure 1 The implementation scenario includes server 100, user terminal 110 and user terminal 120. The number of user terminals is not limited to two, and includes but is not limited to mobile phones, personal computers and other devices. The user terminals may be equipped with cameras that can acquire video. The server may be a single server, a server cluster composed of several servers, or a cloud computing platform or virtualization center.

[0035] User terminal 110 or 120 acquires a video via camera, intending to upload it to a platform for playback. First, the video needs to be uploaded to server 100 for transcoding before being forwarded to the platform. Upon receiving the uploaded video, server 100 places the transcoding task into a task queue (such as a Kafka message queue) to await execution. When the transcoding task is queued, server 100 retrieves it from the task queue and also retrieves the number of heartbeats in the status queue that are less than a predetermined time from the current time. If the number of heartbeats is less than the maximum number of tasks that can be executed in parallel globally, server 100 uses available downstream resources to execute the transcoding task. If the number of heartbeats is greater than or equal to the maximum number of tasks, server 100 continues to retrieve the number of heartbeats in the status queue that are less than a predetermined time from the current time until the number of heartbeats is less than the maximum number of tasks, at which point it uses available downstream resources to execute the transcoding task.

[0036] Below, we will refer to Figures 2 to 4 A task execution method and apparatus according to exemplary embodiments of the present disclosure are described in detail.

[0037] Figure 2 This is a flowchart illustrating a task execution method according to an exemplary embodiment, such as... Figure 2 As shown, the task execution method includes the following steps:

[0038] In step S201, tasks to be executed are retrieved from the task queue.

[0039] According to an exemplary embodiment of this disclosure, before retrieving the task to be executed from the task queue, the method further includes: determining the task to be executed corresponding to the uploaded data; and sending the task to be executed corresponding to the data to the task queue. According to this embodiment, timely addition of new tasks to be executed to the task queue ensures that new tasks can be queued in the task queue and await execution.

[0040] For example, taking a video upload scenario as an example, the task queue can be a Kafka message queue. When a video is uploaded to the server, the corresponding transcoding task can be put into the message queue and wait to be executed. When it is the turn of the transcoding task, the server can retrieve the transcoding task from the task queue.

[0041] return Figure 2 In step S202, the number of heartbeat times in the status queue that are less than a predetermined time away from the current time is obtained. The status queue stores the heartbeat times of tasks that have started execution and the heartbeat times are updated periodically according to the execution status of the tasks.

[0042] For example, based on heartbeat times, the number of currently executing valid tasks can be retrieved from a state queue (such as a Redis queue). Specifically, heartbeat times in the state queue that are more than five minutes from the current time can be filtered out. Since each task has its own heartbeat time, this effectively filters out tasks whose last heartbeat time is more than five minutes from the current time, thus filtering out tasks that haven't had a heartbeat for a long time. Because task heartbeat times are updated every minute, a heartbeat time greater than five minutes from the current time indicates that the task corresponding to that heartbeat time has not had a heartbeat for a long time, meaning it is no longer an executing task and should be removed from the valid task count. Even if a server abnormally exits, the tasks processed by those servers will no longer update their heartbeat times. When other servers retrieve the global valid concurrency count from the Redis queue, they can filter out these tasks that haven't reported heartbeat times due to abnormal server exits, thus avoiding the problem of resources being held up due to abnormal service exits.

[0043] According to an exemplary embodiment of this disclosure, before obtaining the number of heartbeats in the status queue that are less than a predetermined time away from the current time, the method further includes: periodically querying the execution status of tasks that have already started execution; if a task that has already started execution is currently being executed, then updating the heartbeat time of the task that has already started execution in the status queue; if a task that has already started execution is not currently being executed, then stopping the updating of the heartbeat time of the task that has already started execution in the status queue. According to this embodiment, periodically detecting the execution status of tasks that have already started execution ensures that the heartbeat time in the status queue can accurately indicate whether a task is currently being executed, thus ensuring the accuracy of the status queue.

[0044] For example, before starting to process tasks in the Kafka message queue, a scheduled task can be deployed. The server continuously polls (e.g., every minute) the tasks that have already started executing locally. Based on the status of the tasks, it determines whether the heartbeat time of each task in the status queue (Redis) needs to be updated. Taking the transcoding task as an example, if the video is still transcoding when polling, that is, the transcoding task is still being processed and is in the process of execution, then the heartbeat time of each task in the status queue (Redis) is updated to the current time, such as the query time. However, if the video has already completed transcoding when polling, then the transcoding task is no longer in the process of execution, and the heartbeat time of each task in the status queue (Redis) is no longer updated.

[0045] return Figure 2In step S203, if the number of heartbeat times is less than the maximum number of tasks that can be executed in parallel globally, idle downstream resources are invoked to execute the task to be executed. The maximum number of tasks that can be executed in parallel globally can be preset, such as in a database, or it can be set temporarily; this disclosure does not impose any limitations on this. For example, if the number of selected heartbeat times is less than the maximum number of tasks that can be executed in parallel globally, that is, if the number of effective tasks is less than the maximum number of tasks that can be executed in parallel globally, it means that there are still idle downstream resources available, and at this time, the idle downstream resources can be invoked to execute the task to be executed.

[0046] According to an exemplary embodiment of this disclosure, after invoking an idle downstream resource to execute the task to be executed, the method further includes: using the time when the downstream resource starts executing the task to be executed as the heartbeat time of the task to be executed, and adding it to a status queue. According to this embodiment, storing the heartbeat time of the task to be executed in a status queue facilitates the next task to be executed in determining whether there are idle downstream resources available. For example, after a transcoding task starts executing, the start time can be used as the first heartbeat time and stored in the status queue. Subsequently, the execution status of the task to be executed can be periodically checked to update the heartbeat time.

[0047] According to an exemplary embodiment of this disclosure, after invoking idle downstream resources to execute the task to be executed, the method further includes: deleting the heartbeat time of the task to be executed from the status queue after the task to be executed has been completed. According to this embodiment, deleting the heartbeat time of completed tasks from the status queue can further ensure the accuracy of the status queue. For example, once video transcoding is completed, i.e., after the transcoding task has been executed, the information of the transcoding task can be deleted from the Redis queue, ensuring the accuracy of the number of tasks running in the Redis queue.

[0048] According to an exemplary embodiment of this disclosure, when the number of heartbeat times equals the maximum number of tasks, the system continues to acquire the number of heartbeat times in the status queue that are less than a predetermined time from the current time until the number of heartbeat times is less than the maximum number of tasks. Then, idle downstream resources are invoked to execute the task to be executed. In this embodiment, when the number of selected heartbeat times equals the maximum number of tasks, it is equivalent to the number of tasks currently being executed equaling the maximum number of tasks, meaning that global resources are already full. At this point, the system can continuously compare the number of selected heartbeat times with the maximum number of tasks until the number of heartbeat times is less than the maximum number of tasks. Then, downstream resources are invoked to execute the corresponding task, thus resolving the issue of resource saturation.

[0049] For example, if the selected heartbeat time (i.e. the number of valid tasks) is less than the maximum number of tasks that can be executed in parallel globally, it means that the number of tasks being executed has reached the maximum number of tasks that can be executed in parallel globally, and there are no idle downstream resources to process the task to be executed. At this time, it is necessary to return to step S202 to retrieve the number of heartbeat times in the status queue that have not exceeded the predetermined time since the current time, and continue to compare the number of selected heartbeat times with the maximum number of tasks until the number of selected heartbeat times is less than the maximum number of tasks. Then, idle downstream resources are called to execute the task to be executed.

[0050] To facilitate understanding of the above embodiments, the following example uses a Kafka message queue as the task queue and a Redis queue as the state queue. Figure 3 The system manual is hereby published. Figure 3 This is a schematic diagram illustrating the overall flow of a task execution method according to an exemplary embodiment, such as... Figure 3 As shown, the process mainly includes the following parts:

[0051] S1. Before starting to process tasks in the Kafka message queue, deploy a timed heartbeat task. The Kafka consumer service (located on the server) continuously polls (e.g., every minute) the tasks that have started executing locally. Based on the status of the tasks, it determines whether the heartbeat time of each task in the status queue (Redis) needs to be updated. If the polled task is still in the process of being processed, the heartbeat time of each task in the status queue (Redis) is updated to the current time. If the task is no longer in the process of being processed when polling, the heartbeat time of each task in the status queue (Redis) is stopped from being updated.

[0052] S2. Continuously retrieve tasks from the Kafka message queue, such as retrieving a Kafka task.

[0053] S3. Retrieve the number of heartbeat times of currently executing valid tasks from the Redis queue, and record the number as now. At this point, tasks that have not had a heartbeat for a long time, such as tasks whose last heartbeat time is more than five minutes away from the current time, can be filtered out.

[0054] S4. Read the maximum number of tasks that can be executed in parallel globally, and denote the number as sum.

[0055] S5. Compare the number of valid task heartbeat times (now) obtained in step S3 with the maximum number of globally parallel tasks (sum) obtained in step S4 to determine if there are currently any idle downstream resources available to concurrently execute Kafka tasks. If sum is greater than now, it means the number of valid task heartbeat times is less than the maximum number of globally parallel tasks, indicating that there are still idle downstream resources available, and the Kafka task can be executed. In this case, continue to step S6. If sum is less than or equal to now, it means the number of valid task heartbeat times has reached the maximum number of globally parallel tasks, and there are no idle downstream resources available to execute the Kafka task. In this case, return to step S3 and continuously poll and compare sum and now until sum is greater than now, then execute step S6.

[0056] S6. Execute the Kafka task by calling available downstream resources.

[0057] After an S7 Kafka task finishes execution, its heartbeat time can be removed from the Redis queue to ensure the accuracy of the number of valid tasks in the Redis queue.

[0058] In summary, when deploying multiple servers for executing Kafka tasks, the above embodiments can precisely control task concurrency while ensuring robustness, fully utilize downstream resources, improve downstream resource utilization, reduce task queuing time, reduce user waiting time, and enhance user experience.

[0059] Figure 4 This is a block diagram illustrating a task execution apparatus according to an exemplary embodiment. (Refer to...) Figure 4 The device includes:

[0060] The task acquisition unit 40 is configured to acquire tasks to be executed from the task queue; the task quantity acquisition unit 42 is configured to acquire the number of heartbeat times in the status queue that are less than a predetermined time away from the current time, wherein the status queue stores the heartbeat times of tasks that have already started execution and the heartbeat times are updated periodically according to the execution status of the tasks; the execution unit 44 is configured to execute the tasks to be executed by calling idle downstream resources when the number of heartbeat times is less than the maximum number of tasks to be executed globally in parallel.

[0061] According to an exemplary embodiment of this disclosure, the execution unit 44 is further configured to continue acquiring the number of heartbeat times in the status queue that are less than a predetermined time away from the current time when the number of heartbeat times is equal to the maximum number of tasks, until the number of heartbeat times is less than the maximum number of tasks, and then call idle downstream resources to execute the task to be executed.

[0062] According to an exemplary embodiment of this disclosure, the task quantity acquisition unit 42 is further configured to periodically query the execution status of tasks that have already started execution before acquiring the number of heartbeat times in the status queue that are less than a predetermined time away from the current time; if a task that has already started execution is currently being executed, then the heartbeat time of the task that has already started execution in the status queue is updated; if a task that has already started execution is not currently being executed, then the updating of the heartbeat time of the task that has already started execution in the status queue is stopped.

[0063] According to an exemplary embodiment of this disclosure, the execution unit 44 is further configured to, after calling an idle downstream resource to execute the task to be executed, add the time when the downstream resource starts executing the task to be executed as the heartbeat time of the task to be executed to the status queue.

[0064] According to an exemplary embodiment of this disclosure, the execution unit 44 is further configured to delete the heartbeat time of the pending task from the status queue after the pending task has been executed, following the invocation of idle downstream resources to execute the pending task.

[0065] According to an exemplary embodiment of this disclosure, the task acquisition unit 40 is configured to determine the task to be executed corresponding to the uploaded data based on the uploaded data before acquiring the task to be executed from the task queue; and to send the task to be executed corresponding to the data to the task queue.

[0066] According to embodiments of this disclosure, an electronic device may be provided. Figure 5 This is a block diagram of an electronic device 500 according to an embodiment of the present disclosure. The electronic device includes at least one memory 501 and at least one processor 502. The at least one memory stores a set of computer-executable instructions. When the set of computer-executable instructions is executed by the at least one processor, a task execution method according to an embodiment of the present disclosure is performed.

[0067] As an example, electronic device 500 may be a PC, tablet, personal digital assistant, smartphone, or other device capable of executing the aforementioned set of instructions. Here, electronic device 1000 is not necessarily a single electronic device, but may be a collection of any devices or circuits capable of executing the aforementioned instructions (or instruction sets) individually or in combination. Electronic device 500 may also be part of an integrated control system or system manager, or may be configured to interconnect with a portable electronic device locally or remotely (e.g., via wireless transmission) through an interface.

[0068] In electronic device 500, processor 502 may include a central processing unit (CPU), a graphics processing unit (GPU), a programmable logic device, a dedicated processor system, a microcontroller, or a microprocessor. By way of example and not limitation, processor 502 may also include analog processors, digital processors, microprocessors, multi-core processors, processor arrays, network processors, etc.

[0069] The processor 502 can execute instructions or code stored in memory, and the memory 501 can also store data. Instructions and data can also be sent and received over a network via a network interface device, wherein the network interface device can employ any known transmission protocol.

[0070] The memory 501 may be integrated with the processor 502, for example, by placing RAM or flash memory within an integrated circuit microprocessor. Alternatively, the memory 501 may include a separate device, such as an external disk drive, a storage array, or other storage device usable by any database system. The memory 501 and the processor 502 may be operatively coupled, or may communicate with each other, for example, via I / O ports, network connections, etc., enabling the processor 502 to read files stored in the memory 501.

[0071] In addition, the electronic device 500 may also include a video display (such as a liquid crystal display) and a user interaction interface (such as a keyboard, mouse, touch input device, etc.). All components of the electronic device can be interconnected via a bus and / or network.

[0072] According to embodiments of this disclosure, a computer-readable storage medium may also be provided, wherein when instructions in the computer-readable storage medium are executed by at least one processor, the at least one processor causes to perform a task execution method according to embodiments of this disclosure. Examples of computer-readable storage media include: read-only memory (ROM), random access programmable read-only memory (PROM), electrically erasable programmable read-only memory (EEPROM), random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), flash memory, non-volatile memory, CD-ROM, CD-R, CD+R, CD-RW, CD+RW, DVD-ROM, DVD-R, DVD+R, DVD-RW, DVD+RW, DVD-RAM, BD-ROM, BD-R, BD-R LTH, BD-RE, Blu-ray or optical disc storage, hard disk drive (HDD), solid-state drive (SSD), card storage (such as multimedia cards, secure digital (SD) cards, or ultra-fast digital (XD) cards), magnetic tape, floppy disk, magneto-optical data storage device, optical data storage device, hard disk, solid-state drive, and any other device configured to store a computer program and any associated data, data files, and data structures in a non-transitory manner and to provide the computer program and any associated data, data files, and data structures to a processor or computer so that the processor or computer can execute the computer program. The computer program in the aforementioned computer-readable storage medium can run in an environment deployed in computer devices such as clients, hosts, agent devices, servers, etc. Furthermore, in one example, the computer program and any associated data, data files, and data structures are distributed across a networked computer system, such that the computer program and any associated data, data files, and data structures are stored, accessed, and executed in a distributed manner through one or more processors or computers.

[0073] According to an embodiment of this disclosure, a computer program product is provided, including computer instructions, which, when executed by a processor, implement the task execution method of the embodiment of this disclosure.

[0074] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This disclosure is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the following claims.

[0075] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.

Claims

1. A task execution method, characterized in that, include: Retrieve tasks to be executed from the task queue; Get the number of heartbeat times in the status queue that are less than a predetermined time away from the current time, wherein the status queue stores the heartbeat times of tasks that have started execution and the heartbeat times are updated periodically according to the execution status of the tasks; If the number of heartbeat times is less than the maximum number of tasks that can be executed in parallel globally, idle downstream resources are invoked to execute the task to be executed. Before obtaining the number of heartbeat times in the status queue that are less than a predetermined time from the current time, the process also includes: Periodically check the execution status of tasks that have already started; If the task that has already started execution is currently in the execution state, then update the heartbeat time of the task that has already started execution in the status queue; If the task that has already started execution is not currently being executed, then stop updating the heartbeat time of the task that has already started execution in the status queue; The process includes, after calling an idle downstream resource to execute the task to be executed, adding the time when the downstream resource starts executing the task to be executed as the heartbeat time of the task to be executed to the status queue.

2. The task execution method as described in claim 1, characterized in that, Also includes: If the number of heartbeat times equals the maximum number of tasks, continue to acquire the number of heartbeat times in the status queue that are less than the predetermined time from the current time until the number of heartbeat times is less than the maximum number of tasks, and then call idle downstream resources to execute the task to be executed.

3. The task execution method as described in claim 1, characterized in that, After invoking idle downstream resources to execute the task to be executed, the process also includes: After the pending task is completed, the heartbeat time of the pending task is deleted from the status queue.

4. The task execution method as described in claim 1, characterized in that, Before retrieving tasks from the task queue, the process also includes: Based on the uploaded data, determine the tasks to be executed for the data; The task to be executed corresponding to the data is sent to the task queue.

5. A task execution device, characterized in that, include: The task retrieval unit is configured to retrieve tasks to be executed from the task queue; The task quantity acquisition unit is configured to acquire the number of heartbeat times in the status queue that have not exceeded a predetermined time since the current time, wherein the status queue stores the heartbeat times of tasks that have started execution and the heartbeat times are updated periodically according to the execution status of the tasks. The execution unit is configured to invoke idle downstream resources to execute the task to be executed when the number of heartbeat times is less than the maximum number of tasks to be executed globally in parallel. The task quantity acquisition unit is further configured to periodically query the execution status of tasks that have already started execution before acquiring the number of heartbeat times in the status queue that are less than a predetermined time away from the current time; if the tasks that have already started execution are currently being executed, then the heartbeat time of the tasks that have already started execution in the status queue is updated; if the tasks that have already started execution are not currently being executed, then the updating of the heartbeat time of the tasks that have already started execution in the status queue is stopped. The execution unit is further configured to, after calling an idle downstream resource to execute the task to be executed, add the time when the downstream resource starts executing the task to be executed as the heartbeat time of the task to be executed to the status queue.

6. The task execution device as described in claim 5, characterized in that, The execution unit is further configured to, when the number of heartbeat times is equal to the maximum number of tasks, continue to acquire the number of heartbeat times in the status queue that are less than the predetermined time from the current time, until the number of heartbeat times is less than the maximum number of tasks, and then call idle downstream resources to execute the task to be executed.

7. The task execution device as described in claim 5, characterized in that, The execution unit is further configured to, after calling idle downstream resources to execute the task to be executed, delete the heartbeat time of the task to be executed from the status queue after the task to be executed has been completed.

8. The task execution device as described in claim 5, characterized in that, The task acquisition unit is configured to determine the task to be executed corresponding to the uploaded data based on the uploaded data before acquiring the task to be executed from the task queue; and to send the task to be executed corresponding to the data to the task queue.

9. An electronic device, characterized in that, include: processor; Memory used to store the processor's executable instructions; The processor is configured to execute the instructions to implement the task execution method as described in any one of claims 1 to 4.

10. A computer-readable storage medium, characterized in that, When the instructions in the computer-readable storage medium are executed by at least one processor, the at least one processor causes the at least one processor to perform the task execution method as described in any one of claims 1 to 4.

11. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by the processor, they implement the task execution method as described in any one of claims 1 to 4.

Images