Task scheduling method and device, and computer device

Abstract

This application relates to the technical field of resource scheduling, and in particular to a task scheduling method, apparatus, and computer device. The method is applied to a scheduler and includes: in response to a task acquisition request reported by a computing container, determining a target task instruction from an instruction queue; wherein the instruction queue contains task flows of received tasks to be executed, and each task flow includes at least one task instruction; the computing container includes multiple threads, and the task acquisition request is generated by the computing container in response to the determination of an idle thread, where the idle thread is a thread in an idle state; generating an allocation instruction containing the target task instruction, and feeding the allocation instruction back to the computing container; the allocation instruction is used to instruct the computing container to call an idle thread to execute the target task instruction. The solution of this application can improve hardware utilization.

Description

Technical Field

[0001] This application relates to the technical field of resource scheduling, and in particular to a task scheduling method, apparatus and computer equipment. Background Technology

[0002] In batch processing scenarios, distributed systems are typically used to process the data. In related technologies, the processing logic of a distributed system for batch tasks is to execute each task sequentially. The distributed system pre-creates multiple computing containers, each containing multiple threads. When executing a single task, the task data is fragmented, and different data fragments are processed separately by multiple computing containers, thereby improving task execution efficiency.

[0003] Furthermore, in related technologies, the number of computing containers in a distributed system is often determined based on the average processing time of each task or the execution time of the largest task. This results in all computing containers being invoked only when facing large batch processing tasks. However, when facing small tasks, some computing containers may have idle threads, and there may even be idle computing containers themselves. Since computing containers already occupy hardware resources such as threads when they are created, these hardware resources remain occupied even if the computing containers are not invoked. In other words, the task scheduling methods in related technologies lead to low utilization of hardware resources.

[0004] Therefore, how to improve the utilization rate of hardware resources is an urgent problem to be solved. Summary of the Invention

[0005] Therefore, it is necessary to provide a task scheduling method, apparatus, and computer equipment that can improve the utilization rate of hardware resources to address the above-mentioned technical problems.

[0006] In a first aspect, this application provides a task scheduling method applied to a coordinator in a scheduling system, the method comprising:

[0007] In response to a task retrieval request reported by the computing container, a target task instruction is determined from the instruction queue; wherein, the instruction queue contains task flows of each received task to be executed, and the task flow includes at least one task instruction; the computing container includes multiple threads, and the task retrieval request is generated by the computing container in response to the determination of an idle thread, wherein the idle thread is a thread in an idle state;

[0008] An allocation instruction containing the target task instruction is generated and fed back to the computing container; the allocation instruction is used to instruct the computing container to call the idle thread to execute the target task instruction.

[0009] In one embodiment, the method further includes:

[0010] In response to the execution request reported by the computing container, the parallel quantity corresponding to the parent task is obtained; wherein, the execution request includes the thread identifier of the idle thread and the target task instruction; the parent task is the task to be executed to which the target task instruction belongs; the execution request is generated by the idle thread when it determines that the self-check result of the target task instruction is a successful self-check; the parallel quantity is the number of task instructions in the parent task whose execution status is executing;

[0011] Obtain the parallel threshold corresponding to the parent task, compare the number of parallel processes with the parallel threshold to obtain the comparison result, and generate an execution feedback instruction based on the comparison result; the execution feedback instruction indicates whether execution is allowed or not; the parallel threshold indicates the maximum number of threads allowed to be occupied by the task to be executed.

[0012] The execution feedback instruction is fed back to the computing container based on the thread identifier of the idle thread.

[0013] In one embodiment, generating the execution feedback instruction based on the comparison result includes:

[0014] If the comparison result indicates that the number of parallel operations is less than the parallel threshold, an execution feedback instruction indicating that execution is allowed is generated, and the execution status of the target task instruction and the number of parallel operations are updated.

[0015] If the comparison result indicates that the number of parallel operations is equal to the parallel threshold, an execution feedback instruction indicating that execution is not allowed is generated.

[0016] In one embodiment, the method further includes:

[0017] Upon receiving the task flow for each of the tasks to be executed, each task instruction contained in the task flow is added to the instruction queue, and the number of instructions in the task flow is determined.

[0018] The parallel threshold corresponding to the task to be executed is determined based on the number of instructions; wherein the parallel threshold is positively correlated with the number of instructions.

[0019] Secondly, this application provides a task scheduling method applied to a computing container in a scheduling system, the method comprising:

[0020] For each thread, when it is determined that the thread is in an idle state, the thread is determined to be an idle thread, and a task acquisition request is generated based on the idle thread;

[0021] The task acquisition request is reported to the coordinator, and the allocation instruction fed back by the coordinator is received; wherein, the allocation instruction includes a target task instruction, which is determined by the coordinator from the instruction queue in response to the task acquisition request, and the instruction queue includes task flows of each task to be executed received by the coordinator, and the task flow includes at least one of the task instructions.

[0022] The idle thread is invoked to execute the target task instruction.

[0023] In one embodiment, the step of invoking the idle thread to execute the target task instruction includes:

[0024] The idle thread is invoked to perform a self-check on the target task instruction;

[0025] If the self-test result is successful, an execution request containing the target task instructions is generated and the execution request is reported to the coordinator.

[0026] The system receives execution feedback instructions from the coordinator and executes the target task instruction according to the execution feedback instructions; wherein the execution feedback instructions are generated by the coordinator based on the comparison results of the number of parallel tasks corresponding to the parent task and the parallel threshold, and the execution feedback instructions indicate whether execution is allowed or not.

[0027] The parent task is the task to be executed to which the target task instruction belongs; the parallel quantity is the number of task instructions in the parent task that are in the execution state; and the parallel threshold represents the maximum number of threads allowed to be occupied by the task to be executed.

[0028] In one embodiment, the task instruction includes task data and a task function; the step of invoking the idle thread to perform a self-check on the target task instruction includes:

[0029] Invoke the idle thread to load the task data and / or the task function, and determine the loading result;

[0030] If the loading result indicates successful loading, a latency test script is executed to determine the latency between the computing container and the coordinator.

[0031] If the delay is determined to be less than the error threshold, the self-test result is determined to be a successful self-test.

[0032] Thirdly, this application also provides a task scheduling device, the device comprising a request-response module and an instruction generation module, wherein:

[0033] The request response module is used to determine the target task instruction from the instruction queue in response to a task acquisition request reported by the computing container; wherein, the instruction queue contains task flows of each received task to be executed, and the task flow includes at least one task instruction; the computing container includes multiple threads, and the task acquisition request is generated by the computing container in response to the determination of an idle thread, wherein the idle thread is a thread in an idle state;

[0034] The instruction generation module is used to generate an allocation instruction containing the target task instruction and to feed the allocation instruction back to the computing container; the allocation instruction is used to instruct the computing container to call the idle thread to execute the target task instruction.

[0035] Fourthly, this application also provides a task scheduling device, the device comprising a request module, an interaction module, and an execution module, wherein:

[0036] The request module is used to determine that a thread is an idle thread when it is determined that the thread is in an idle state, and to generate a task acquisition request based on the idle thread.

[0037] The interaction module is used to report the task acquisition request to the coordinator and receive the allocation instruction fed back by the coordinator; wherein, the allocation instruction includes a target task instruction, which is determined by the coordinator from the instruction queue in response to the task acquisition request, and the instruction queue includes the task flow of each task to be executed received by the coordinator, and the task flow includes at least one of the task instructions.

[0038] The execution module is used to call the idle thread to execute the target task instruction.

[0039] Fifthly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the task scheduling method as described in any one of the first and / or second aspects above.

[0040] Sixthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the task scheduling method as described in any one of the first and / or second aspects above.

[0041] The aforementioned task scheduling method, apparatus, and computer equipment, on the one hand, set the resource scheduling granularity to the thread level, scheduling and managing task instructions based on the state of each thread, enabling fine-grained task allocation and effectively scheduling occupied physical resources, thereby improving the utilization rate of physical resources; on the other hand, when the computing container determines that there are idle threads, it actively initiates a task acquisition request to the coordinator to obtain the target task instructions allocated by the coordinator, and further calls the idle thread to execute the target task instructions. Unlike the prior art in which the computing container's tasks are actively allocated by the coordinator, in the solution of this application, the computing container actively monitors the idle state of threads and actively requests tasks from the coordinator, which can further prevent threads from entering an idle state for a long time, thus further improving the utilization rate of hardware resources in the computing container. Attached Figure Description

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

[0043] Figure 1 This is a diagram illustrating the application environment of a task scheduling method in one embodiment;

[0044] Figure 2 This is a schematic diagram of the steps of a task scheduling method applied to a coordinator in one embodiment;

[0045] Figure 3 This is a schematic diagram illustrating the processing steps of the coordinator for an execution request in one embodiment;

[0046] Figure 4 This is a schematic diagram illustrating the steps for setting the parallel threshold corresponding to the task to be executed in one embodiment.

[0047] Figure 5 This is a schematic diagram of a task scheduling method applied to a computing container in another embodiment;

[0048] Figure 6 This is a schematic diagram illustrating the steps of an idle thread executing a target task instruction in one embodiment;

[0049] Figure 7 This is a flowchart illustrating the execution of a target task instruction by an idle thread in one embodiment.

[0050] Figure 8 This is a structural block diagram of a task scheduling device in one embodiment;

[0051] Figure 9 This is a structural block diagram of the task scheduling device in another embodiment;

[0052] Figure 10 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0053] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0054] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0055] The task scheduling method provided in this application embodiment can be applied to, for example, Figure 1 The application environment shown is illustrated. The distributed system for task scheduling consists of a controller, a scheduling platform, a coordinator, and at least one computing container. Each computing container includes multiple threads. The scheduling platform (DB) monitors the allocation and execution status of each task instruction from the coordinator and obtains the execution results.

[0056] The controller divides the tasks to be executed in the task queue according to the division rules, and obtains the subtasks corresponding to each task to be executed. Then, it generates an instruction queue of tasks to be executed based on each subtask. Each task instruction in the instruction queue corresponds to a subtask. The task instruction includes the task function corresponding to the subtask, the task data (or the address for storing the task data), and the cache address of the task result. The task instruction is used to instruct the task function to process the task data and write the processed result data to the storage address.

[0057] The instruction queue is stored in the scheduling platform (DB), and the coordinator schedules tasks based on the instruction queue. The data storage system stores the data that the distributed system needs to process. The data storage system can be integrated on a server, or it can be located in the cloud or on other network servers. The distributed system can be deployed on a single server or across multiple servers; for example, the controller, scheduling platform, coordinator, and at least two of the computing containers can be deployed on the same server. Here, "server" can refer to a server cluster or a cloud server.

[0058] In one exemplary embodiment, such as Figure 2 As shown, a task scheduling method is provided, which can be applied to... Figure 1 Taking the coordinator in the example, the explanation includes the following steps A10 and A20, wherein:

[0059] Step A10: In response to the task retrieval request reported by the computing container, determine the target task instruction from the instruction queue.

[0060] In the embodiments of this application, the instruction queue includes a task flow of each received task to be executed, and the task flow includes at least one task instruction; wherein, there is an execution order between the tasks to be executed, and there is also an execution order among the task instructions in the task flow of each task to be executed; wherein the execution order includes the sequential execution order and the parallel execution order. The specific logic for dividing the tasks to be executed into task instructions in the task flow is not specifically limited in the embodiments of this application.

[0061] The compute container comprises multiple threads and is used to manage these threads. It can monitor the call status of each thread to identify idle threads. Upon determining the existence of an idle thread, the compute container obtains its thread identifier and then generates a task retrieval request containing that thread identifier. The compute container proactively sends this request to the coordinator, requesting that the coordinator allocate task instructions to the idle thread.

[0062] In response to a task request, the coordinator determines the unassigned task instructions as the target task instructions to be assigned to the idle thread according to the execution order of the task instructions in the instruction queue.

[0063] Step A20: Generate an allocation instruction containing the target task instruction and feed the allocation instruction back to the computing container; the allocation instruction is used to instruct the computing container to call an idle thread to execute the target task instruction.

[0064] In one possible implementation of this application, after determining the target task instruction to be allocated to an idle thread, the coordinator generates an allocation instruction containing the target task instruction and the thread identifier of the idle thread, and then feeds the allocation instruction back to the computing container. When the computing container receives the allocation instruction, it parses the allocation instruction to obtain the target task instruction and the thread identifier; then, the computing container allocates the target task instruction to the idle thread corresponding to the thread identifier for execution.

[0065] In another possible implementation, after determining the target task instruction to be assigned to an idle thread, the coordinator generates an allocation instruction containing the target task instruction and then feeds the allocation instruction back to the computing container. When the computing container receives the allocation instruction, it parses the allocation instruction to obtain the target task instruction; the computing container then randomly assigns the target task instruction to one of the idle threads, or it assigns the target task instruction according to the order in which the idle threads were initially identified as not idle; that is, the idle thread that was identified as idle earlier is given priority in receiving the target task instruction.

[0066] In the aforementioned task scheduling method, on the one hand, setting the resource scheduling granularity to the thread level and scheduling and managing task instructions based on the state of each thread enables fine-grained task allocation, thereby effectively scheduling occupied physical resources and improving the utilization rate of physical resources. On the other hand, when the computing container determines that there are idle threads, it actively initiates a task acquisition request to the coordinator to obtain the target task instructions allocated by the coordinator, and further calls the idle thread to execute the target task instructions. Unlike the existing technology where the computing container's tasks are actively allocated by the coordinator, in the solution of this application, the computing container actively monitors the idle state of threads and actively requests tasks from the coordinator, which can further prevent threads from entering an idle state for a long time, thus further improving the utilization rate of hardware resources in the computing container.

[0067] In one embodiment, during the execution of the target task instruction by the idle thread, the idle thread performs a self-check on the target task instruction. If the self-check result of the idle thread on the target task instruction is successful, the computing container / idle thread generates an execution request for the target task instruction. The execution request includes the target task instruction (or its identifier) ​​and the thread identifier of the idle thread. The following further elaborates on the coordinator's processing of the execution request.

[0068] In one embodiment, such as Figure 3 As shown, the coordinator's processing steps for the execution request may specifically include steps A31-A33, wherein:

[0069] Step A31: In response to the execution request reported by the computing container, obtain the number of parallel tasks corresponding to the parent task.

[0070] Specifically, after receiving an execution request, the coordinator parses the request to obtain the thread identifier of the idle thread and the target task instruction. Further, the coordinator determines the parent task of the target task instruction and obtains the parallel execution count corresponding to that parent task. Here, the parent task is the pending task to which the target task instruction belongs; the parallel execution count is the number of task instructions in the parent task that are currently executing; and the parallel execution count is also the number of threads occupied by that parent task.

[0071] The coordinator constructs a state table to maintain the parallel thresholds corresponding to each task to be executed. If the coordinator's execution feedback instruction for the execution request indicates that execution is allowed, then when the computation container / idle thread receives the execution feedback, the idle thread executes the target task instruction. At the same time, the idle thread directly feeds back to the coordinator the first response status indicating that the target task is being executed. The coordinator receives the first response status, extracts the target task instruction contained in the first response status, and updates the parallel threshold of the parent task corresponding to the target task instruction in the state table. That is, the coordinator increments the number of tasks corresponding to the target task instruction in the state table by 1.

[0072] Step A32: Obtain the parallel threshold corresponding to the parent task, compare the number of parallel tasks with the parallel threshold to obtain the comparison result, and generate an execution feedback instruction based on the comparison result; wherein, the execution feedback instruction indicates whether execution is allowed or not.

[0073] Specifically, the coordinator has a threshold table containing the parallel thresholds for each task to be executed. The coordinator queries the threshold table based on the parent task corresponding to the target task instruction to determine the parallel threshold for the parent task; further, the coordinator compares the number of parallel tasks of the parent task with the parallel thresholds to obtain the comparison result.

[0074] In this embodiment, at least two tasks are allowed to execute concurrently. This necessitates avoiding a situation where the instructions of a single task occupy all threads in the computation container. Therefore, in this embodiment, a parallel threshold is set for each task, representing the maximum number of threads that the task can utilize. The coordinator constructs a threshold table based on the parallel threshold corresponding to each task. The method for determining the parallel threshold for each task will be detailed in subsequent embodiments and will not be elaborated upon here.

[0075] Furthermore, generating execution feedback instructions based on the comparison results may specifically include: if the comparison result indicates that the number of parallel operations is less than the parallel threshold, generating execution feedback instructions that indicate that execution is allowed, and updating the execution status and number of parallel operations of the target task instructions; if the comparison result indicates that the number of parallel operations is equal to the parallel threshold, generating execution feedback instructions that indicate that execution is not allowed.

[0076] Step A33: Based on the thread identifier of the idle thread, send the execution feedback instruction back to the computing container.

[0077] Specifically, the execution feedback instruction includes the thread identifier of the idle thread carried in the execution request; the coordinator sends the execution feedback instruction to the compute container / idle thread. The compute container / idle thread determines whether to begin executing the target task instruction based on the execution feedback instruction. If the execution feedback instruction indicates that execution is permitted, the idle thread executes the target task instruction; furthermore, the idle thread / compute container generates a first response state containing the target task instruction and feeds this first response state back to the coordinator; the first response state indicates that the target task instruction is being executed.

[0078] If the execution feedback instruction indicates that execution is not allowed, the idle thread abandons the execution of the target task instruction; and the idle thread changes back to the idle state; the idle thread / computing container generates a second response state containing the target task instruction and feeds the second response state back to the coordinator; the second response state indicates that the target task instruction has not been executed.

[0079] The above describes the coordinator's handling process for execution requests initiated by the computing container / idle thread. The following section further elaborates on the process of determining the parallel threshold for each task to be executed.

[0080] In one embodiment, the task scheduling method further includes a step of determining a parallel threshold corresponding to each task to be executed, such as... Figure 4 As shown, it specifically includes steps A01 and A02, wherein:

[0081] Step A01: Upon receiving the task flow for each task to be executed, add each task instruction contained in the task flow to the instruction queue and determine the number of task instructions contained in the task flow.

[0082] Step A02: Determine the parallel threshold corresponding to the task to be executed based on the number of instructions; wherein, the parallel threshold is positively correlated with the number of instructions.

[0083] Specifically, for each task to be executed, when the coordinator receives the task flow corresponding to the task, it adds each task instruction in the task flow to the instruction queue according to the execution order of each task instruction in the task flow; and the coordinator counts the number of task instructions in the task flow.

[0084] For large tasks to be executed, there are many task instructions in the task flow. If a small parallel threshold is set, only a small number of threads are allowed to execute the task in parallel at the same time. This would cause the task to take a long time from start to finish. To avoid the execution of a single large task taking too long, this embodiment of the application pre-sets a correspondence between the number of instructions and the parallel threshold; wherein, the parallel threshold is positively correlated with the number of instructions. That is, the more task instructions in the task flow of a task to be executed, the higher the parallel threshold corresponding to that task.

[0085] The coordinator determines the parallel threshold for each task based on the number of instructions for each task to be executed and the correspondence between the parallel threshold and the number of instructions. Then, the coordinator constructs a threshold table for storage based on the parallel threshold for each task to be executed.

[0086] The above embodiments illustrate the process of a task scheduling method from the perspective of a coordinator in a task scheduling system. The following embodiments further illustrate the process of a task scheduling method from the perspective of a computing container in a task scheduling system.

[0087] In one exemplary embodiment, a task scheduling method is also disclosed, which is applied to a computing container; such as Figure 5 As shown, the task scheduling method may specifically include steps B10-B30, wherein:

[0088] Step B10: For each thread, when it is determined that the thread is in an idle state, determine that the thread is an idle thread, and generate a task acquisition request based on the idle thread.

[0089] In one possible implementation of this application, for each thread in the computing container, the computing container can be equipped with a separate monitoring module to query the status of each thread in real time or at preset intervals, thereby determining the idle threads. That is, the idle status of each thread in the computing container can be determined by monitoring by the monitoring module in the computing container, or it can be actively reported to the computing container by each thread.

[0090] Furthermore, each thread within the computing container possesses a unique thread identifier that represents its identity. In one possible implementation, after identifying an idle thread, the computing container generates a task acquisition request containing the idle thread's thread identifier. In another possible implementation, after identifying an idle thread, the computing container directly generates a task acquisition request. This acquisition request instructs the coordinator to allocate a task instruction to the computing container so that the idle thread within the container can execute that task instruction.

[0091] Step B20: Report the task acquisition request to the coordinator and receive the allocation instructions from the coordinator.

[0092] In this embodiment of the application, the computing container reports a task acquisition request to the coordinator; in response to the task request, the coordinator determines the unassigned task instructions as target task instructions to be assigned to the idle thread according to the execution order of the task instructions in the instruction queue. The instruction queue contains task flows of each task to be executed received by the coordinator, and each task flow includes at least one task instruction.

[0093] Step B30: Call the idle thread to execute the target task instruction.

[0094] In the embodiments of this application, when the task acquisition request includes a thread identifier for an idle thread: after determining the target task instruction to be assigned to an idle thread, the coordinator generates an allocation instruction containing the target task instruction and the thread identifier of the idle thread, and then feeds the allocation instruction back to the computing container. When the computing container receives the allocation instruction, it parses the allocation instruction to obtain the target task instruction and the thread identifier; thus, the computing container allocates the target task instruction to the idle thread corresponding to the thread identifier for execution.

[0095] When the task acquisition request does not contain a thread identifier for an idle thread: After determining the target task instruction to be assigned to an idle thread, the coordinator generates an allocation instruction containing the target task instruction and then feeds the allocation instruction back to the computing container. When the computing container receives the allocation instruction, it parses the allocation instruction to obtain the target task instruction; the computing container randomly assigns the target task instruction to one of the idle threads, or the computing container allocates the target task instruction according to the order in which the idle threads were initially identified as not idle; that is, the idle thread that was identified as idle earlier has priority in receiving the target task instruction.

[0096] Furthermore, for an idle thread allocated for the target task instruction, the computing container calls the idle thread to execute the target task instruction; at the same time, the computing container changes the idle state of the idle thread to the called state.

[0097] In the aforementioned task scheduling method, on the one hand, setting the resource scheduling granularity to the thread level and scheduling and managing task instructions based on the state of each thread enables fine-grained task allocation, thereby effectively scheduling occupied physical resources and improving the utilization rate of physical resources. On the other hand, when the computing container determines that there are idle threads, it actively initiates a task acquisition request to the coordinator to obtain the target task instructions allocated by the coordinator, and further calls the idle thread to execute the target task instructions. Unlike the existing technology where the computing container's tasks are actively allocated by the coordinator, in the solution of this application, the computing container actively monitors the idle state of threads and actively requests tasks from the coordinator, which can further prevent threads from entering an idle state for a long time, thus further improving the utilization rate of hardware resources in the computing container.

[0098] In one embodiment, such as Figure 6 As shown, in step B30, the process of the idle thread executing the target task instruction may specifically include steps B31-B33, wherein:

[0099] Step B31: Call the idle thread to perform a self-check on the target task instructions.

[0100] In this embodiment, each task instruction includes the task function of the corresponding subtask and task data, as well as the storage address corresponding to the result data. The self-check of the idle thread on the target task instruction includes two dimensions: a self-check for loading and a self-check for latency.

[0101] Step B32: If the self-check result is successful, generate an execution request containing the target task instructions and report the execution request to the coordinator.

[0102] Specifically, if the idle thread successfully loads the target task instruction and the latency between the idle thread (computation container) and the coordinator is determined to be less than the error threshold, the self-check result of the idle thread for the target task instruction is determined to be a successful self-check. Successful loading of the target task instruction by the idle thread includes: the idle thread successfully calling the task function, successfully loading task data, and successfully accessing the storage address.

[0103] Furthermore, when the idle thread successfully performs a self-check for the assigned target task instruction, the idle thread (computing container) generates an execution request for the target task instruction based on the idle thread's thread identifier and the target task instruction; wherein, the execution request is used to request the coordinator whether the idle thread is allowed to start executing the target task instruction.

[0104] Step B33: Receive the execution feedback instruction from the coordinator and execute the target task instruction according to the execution feedback instruction.

[0105] Specifically, the execution feedback instruction is generated by the coordinator based on a comparison between the parallelism count of the parent task and the parallelism threshold. The execution feedback instruction indicates whether execution is allowed or not. The parent task is the pending task to which the target task instruction belongs; the parallelism count is the number of task instructions in the parent task that are currently executing; and the parallelism threshold represents the maximum number of threads allowed to be used by the pending task.

[0106] In this embodiment, at least two tasks to be executed are allowed to run in parallel. This requires avoiding a situation where the instructions of a single task to be executed occupy all the threads in the computing container. Therefore, in this embodiment, a parallel threshold is set for each task to be executed. The parallel threshold represents the maximum number of threads that the task can occupy.

[0107] After receiving an execution request, the coordinator parses it to obtain the thread identifier of the idle thread and the target task instruction. Further, the coordinator determines the parent task of the target task instruction and obtains the parallel execution count corresponding to that parent task. Here, the parent task is the pending task to which the target task instruction belongs; the parallel execution count is the number of task instructions in the parent task that are currently executing; and the parallel execution count is also the number of threads occupied by that parent task.

[0108] The coordinator stores a state table to maintain the parallelism thresholds for each task to be executed. The coordinator looks up the threshold table based on the parent task corresponding to the target task instruction to determine the parallelism threshold for the parent task. Further, the coordinator compares the parallelism count of the parent task with the parallelism threshold to obtain a comparison result. If the comparison result indicates that the parallelism count is less than the parallelism threshold, an execution feedback instruction indicating that execution is allowed is generated, and the execution status and parallelism count of the target task instruction are updated. If the comparison result indicates that the parallelism count is equal to the parallelism threshold, an execution feedback instruction indicating that execution is not allowed is generated.

[0109] If the coordinator's execution feedback instruction for the execution request indicates that execution is allowed, then when the computing container / idle thread receives the execution feedback, the idle thread executes the target task instruction. At the same time, the idle thread directly feeds back to the coordinator the first response status indicating that the target task is being executed. The coordinator receives the first response status, extracts the target task instruction contained in the first response status, and updates the parallel threshold of the parent task corresponding to the target task instruction in the status table. That is, the coordinator increments the number of tasks corresponding to the target task instruction by 1 in the status table.

[0110] Specifically, the execution feedback instruction includes the thread identifier of the idle thread carried in the execution request; the coordinator sends the execution feedback instruction to the compute container / idle thread. The compute container / idle thread determines whether to begin executing the target task instruction based on the execution feedback instruction. If the execution feedback instruction indicates that execution is permitted, the idle thread executes the target task instruction; furthermore, the idle thread / compute container generates a first response state containing the target task instruction and feeds this first response state back to the coordinator; the first response state indicates that the target task instruction is being executed.

[0111] If the execution feedback instruction indicates that execution is not allowed, the idle thread abandons the execution of the target task instruction; and the idle thread changes back to the idle state; the idle thread / computing container generates a second response state containing the target task instruction and feeds the second response state back to the coordinator; the second response state indicates that the target task instruction has not been executed.

[0112] In one embodiment, step B31, which involves calling an idle thread to perform a self-check on the target task instruction, specifically includes: calling the idle thread to load task data and / or task functions, and determining the loading result; if the loading result indicates successful loading, executing a latency test script to determine the latency between the computing container and the coordinator; and if the latency is determined to be less than the error threshold, determining the self-check result as a successful self-check.

[0113] Specifically, the idle thread is invoked to load the task functions and task data contained in the target task instruction, and the loading result is determined. Further, the idle thread accesses the access address corresponding to the result data and determines the access result. If both the loading and access results indicate success, the self-check for the loading dimension of the target task instruction is confirmed to be successful.

[0114] A pre-written latency test script is invoked and executed. This script indicates the latency between the test computation container (idle thread) and the coordinator. If the latency is less than an error threshold, the self-test for the latency dimension of the target task is considered successful. The specific duration of the error threshold is not specifically limited in this embodiment.

[0115] In one possible scenario, the latency test script can be constructed using the Christian's Algorithm or the Network Time Protocol (NTP). In this embodiment, the specific logic of the latency test script is not limited, as long as it can accurately measure the latency between the computing container (idle thread) and the coordinator.

[0116] The above content describes a task scheduling method from the perspectives of a coordinator and a computing container, respectively. The following content elaborates on the implementation of the task scheduling method from the perspective of a distributed system that includes a coordinator and computing containers.

[0117] The core idea of ​​the task scheduling method provided in this application is to integrate the resources in each computing container into a batch task processing thread resource pool, and control the execution scheduling of batch processing tasks through the thread resource pool. A batch task processing application is deployed in the computing container, and the batch task processing application runs as a JVM process. Within the JVM process, there are different threads, and each thread executes different fragments (task instructions) of the task.

[0118] Task scheduling methods include:

[0119] 1. At the controller layer, the execution control instructions (task instructions) of each task to be executed are segmented and queued, and the execution grouping level of the task instructions is controlled to build a task queue.

[0120] 2. When the coordinator allocates tasks to resource pools based on task retrieval requests reported by the resource pools, it distributes the task instructions in the task queue to each resource pool according to conditions (including but not limited to the correspondence between attributes such as application, tenant, data center, unit, cluster, and specified node and the task to be executed). Task instructions that fail to be distributed are retried until the maximum number of retries is reached.

[0121] 3. Based on the received execution command (target task instruction), the resource pool dynamically loads the corresponding task class instance (storage address of task function + task data and result data) of the target task instruction. If loading is successful, a latency self-check is performed to determine the latency between the resource pool and the coordinator. If the latency is less than the error threshold, the self-check is considered successful. After completing the self-check of the target task instruction, the resource pool reports to the coordinator that this resource pool (idle thread) can execute the target task instruction. If loading / self-check fails, it directly returns to the coordinator that this resource pool (idle thread) cannot execute the target task instruction.

[0122] When the resource pool is capable of executing the target task instruction, the task batch instruction progresses to the task queue, and then triggers the idle thread to run. Before starting a task, the idle thread requests a check from the coordinator to determine whether the number of available parallel threads already occupied by the parent task of the target task, as recorded in the coordinator's status table, has reached the maximum number of threads limited by the parallel threshold. When the number of parallel threads equals the parallel threshold, the coordinator returns the current idle thread and abandons the execution of the current target task instruction; the coordinator allocates other task instructions corresponding to pending tasks to the idle thread as target task instructions. When the number of parallel threads is less than the parallel threshold, the coordinator instructs the current idle thread to execute the current target task instruction, updates the parallel threshold of the parent task to which the target task instruction belongs, and performs cumulative counting of the threads already occupied by each pending task.

[0123] Furthermore, such as Figure 7 As shown, during task execution, each thread reports information such as the start, normal end, and abnormal end of the execution of the task slice data (target task instruction) to the coordinator. The coordinator records the execution process of each slice (target task instruction) and each step, and provides the data to the controller so that the controller can calculate the next batch processing task to be executed.

[0124] 4. During the overall task execution control process, the configuration of the batch task processing application deployed in each computing container is the same. The thread resources of the JVM nodes in all computing containers are uniformly classified into a thread resource pool. The thread resource pool receives instructions from the coordinator, picks up tasks, and accepts unified allocation and control from the coordinator. The coordinator performs unified task scheduling, allocation and management based on the task running status, and completes batch task processing with higher efficiency while ensuring that the use of hardware resources (threads) in each resource pool is constant.

[0125] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0126] Based on the same inventive concept, this application also provides a task scheduling apparatus for implementing the task scheduling method described above. The solution provided by this apparatus is similar to the implementation scheme described in the above method; therefore, the specific limitations in one or more task scheduling apparatus embodiments provided below can be found in the limitations of the task scheduling method described above, and will not be repeated here.

[0127] In one exemplary embodiment, such as Figure 8 As shown, a task scheduling device 800 is provided, applied to a coordinator. The device 800 includes a request-response module 801 and an instruction generation module 802, wherein:

[0128] The request-response module 801 is used to determine the target task instruction from the instruction queue in response to the task retrieval request reported by the computing container; wherein, the instruction queue contains the task flow of each task to be executed, and the task flow includes at least one task instruction; the computing container includes multiple threads, and the task retrieval request is generated by the computing container in response to the determination of an idle thread, and the idle thread is a thread in an idle state.

[0129] The instruction generation module 802 is used to generate allocation instructions containing target task instructions and feed the allocation instructions back to the computing container; the allocation instructions are used to instruct the computing container to call an idle thread to execute the target task instructions.

[0130] In the aforementioned task scheduling device 800, on the one hand, the resource scheduling granularity is set to the thread level, and task instructions are scheduled and managed according to the state of each thread. This enables fine-grained allocation of tasks, thereby effectively scheduling occupied physical resources and improving the utilization rate of physical resources. On the other hand, when the computing container determines that there are idle threads, it actively initiates a task acquisition request to the coordinator to obtain the target task instructions allocated by the coordinator, and further calls the idle threads to execute the target task instructions. Unlike the prior art in which the computing container's tasks are actively allocated by the coordinator, in the solution of this application, the computing container actively monitors the idle state of threads and actively requests tasks from the coordinator, which can further prevent threads from entering an idle state for a long time. Thus, the utilization rate of hardware resources in the computing container is further improved.

[0131] In one embodiment, the request response module 801 is further configured to:

[0132] In response to the execution request reported by the computing container, obtain the parallel quantity corresponding to the parent task; wherein, the execution request includes the thread identifier of the idle thread and the target task instruction; the parent task is the pending task to which the target task instruction belongs; the execution request is generated by the idle thread when it determines that the self-check result of the target task instruction is successful; the parallel quantity is the number of task instructions in the parent task whose execution status is executing.

[0133] Obtain the parallel threshold corresponding to the parent task, compare the number of parallel tasks with the parallel threshold, obtain the comparison result, and generate an execution feedback instruction based on the comparison result; the execution feedback instruction indicates whether execution is allowed or not; the parallel threshold indicates the maximum number of threads allowed to be occupied by the task to be executed.

[0134] Based on the thread identifier of the idle thread, the execution feedback instruction is fed back to the computing container.

[0135] In one embodiment, the request response module 801 is further configured to:

[0136] If the comparison result indicates that the number of parallel operations is less than the parallel threshold, generate execution feedback instructions that indicate that execution is allowed, and update the execution status and number of parallel operations of the target task instructions.

[0137] If the comparison result indicates that the number of parallel operations is equal to the parallel threshold, then generate an execution feedback instruction that indicates that execution is not allowed.

[0138] In one embodiment, the task scheduling device 800 further includes a threshold determination module, which is specifically used for:

[0139] Upon receiving the task flow for each task to be executed, the task instructions contained in the task flow are added to the instruction queue, and the number of task instructions contained in the task flow is determined.

[0140] The parallel threshold corresponding to the task to be executed is determined based on the number of instructions; whereby the parallel threshold is positively correlated with the number of instructions.

[0141] In one exemplary embodiment, such as Figure 9 As shown, a task scheduling device 900 is provided for use in a computing container. The device includes a request module 901, an interaction module 902, and an execution module 903, wherein:

[0142] Request module 901 is used to determine that a thread is an idle thread when it is determined that the thread is in an idle state, and to generate a task acquisition request based on the idle thread.

[0143] The interaction module 902 is used to report the task acquisition request to the coordinator and receive the allocation instruction fed back by the coordinator; wherein, the allocation instruction includes the target task instruction, which is determined by the coordinator from the instruction queue in response to the task acquisition request, and the instruction queue contains the task flow of each task to be executed received by the coordinator, and the task flow includes at least one task instruction.

[0144] Execution module 903 is used to call an idle thread to execute the target task instruction.

[0145] In one embodiment, the execution module 903 is specifically used for:

[0146] If the self-check result is successful, an execution request containing the target task instructions is generated and the execution request is reported to the coordinator.

[0147] It receives execution feedback instructions from the coordinator and executes the target task instructions according to the execution feedback instructions; wherein, the execution feedback instructions are generated by the coordinator based on the comparison results of the number of parallel tasks corresponding to the parent task and the parallel threshold, and the execution feedback instructions indicate whether execution is allowed or not.

[0148] The parent task is the task to be executed to which the target task instruction belongs; the parallel quantity is the number of task instructions in the parent task that are in the execution state; and the parallel threshold represents the maximum number of threads allowed to be occupied by the task to be executed.

[0149] In one embodiment, the execution module 903 is specifically used for:

[0150] Call the idle thread to load task data and / or task functions, and determine the loading result;

[0151] If the loading result indicates successful loading, execute the latency test script to determine the latency between the computing container and the coordinator.

[0152] If the delay is less than the error threshold, the self-test result is considered a successful self-test.

[0153] Each module in the aforementioned task scheduling device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0154] In one exemplary embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 10As shown, the computer device includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, Near Field Communication (NFC), or other technologies. When the computer program is executed by the processor, it implements a task scheduling method. The display unit is used to form a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0155] Those skilled in the art will understand that Figure 10 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0156] In one exemplary embodiment, a computer device is provided, including a memory and a processor, the memory storing a computer program, the processor executing the computer program to implement any of the steps described above in the embodiments of the task scheduling method applied to a coordinator and / or applied to a computing container.

[0157] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements any of the steps described above in the task scheduling method embodiments applied to a coordinator and / or applied to a computing container. In another embodiment, a computer program product is provided, comprising a computer program that, when executed by a processor, implements any of the steps described above in the task scheduling method embodiments applied to a coordinator and / or applied to a computing container.

[0158] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0159] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0160] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0161] The above embodiments are merely illustrative of several implementation methods of this application, and their descriptions are relatively specific and detailed. However, they should not be construed as limiting the scope of this application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A task scheduling method, characterized in that, The method, applied to a coordinator in a scheduling system, includes: In response to a task retrieval request reported by the computing container, a target task instruction is determined from the instruction queue; wherein, the instruction queue contains task flows of each received task to be executed, and the task flow includes at least one task instruction; the computing container includes multiple threads, and the task retrieval request is generated by the computing container in response to the determination of an idle thread, wherein the idle thread is a thread in an idle state; An allocation instruction containing the target task instruction is generated and fed back to the computing container; the allocation instruction is used to instruct the computing container to call the idle thread to execute the target task instruction.

2. The method according to claim 1, characterized in that, The method further includes: In response to the execution request reported by the computing container, the parallel quantity corresponding to the parent task is obtained; wherein, the execution request includes the thread identifier of the idle thread and the target task instruction; the parent task is the task to be executed to which the target task instruction belongs; the execution request is generated by the idle thread when it determines that the self-check result of the target task instruction is a successful self-check; the parallel quantity is the number of task instructions in the parent task whose execution status is executing; Obtain the parallel threshold corresponding to the parent task, compare the number of parallel processes with the parallel threshold to obtain the comparison result, and generate an execution feedback instruction based on the comparison result; the execution feedback instruction indicates whether execution is allowed or not; the parallel threshold indicates the maximum number of threads allowed to be occupied by the task to be executed. The execution feedback instruction is fed back to the computing container based on the thread identifier of the idle thread.

3. The method according to claim 2, characterized in that, The step of generating execution feedback instructions based on the comparison result includes: If the comparison result indicates that the number of parallel operations is less than the parallel threshold, an execution feedback instruction indicating that execution is allowed is generated, and the execution status of the target task instruction and the number of parallel operations are updated. If the comparison result indicates that the number of parallel operations is equal to the parallel threshold, an execution feedback instruction indicating that execution is not allowed is generated.

4. The method according to claim 2 or 3, characterized in that, The method further includes: Upon receiving the task flow for each of the tasks to be executed, each task instruction contained in the task flow is added to the instruction queue, and the number of instructions in the task flow is determined. The parallel threshold corresponding to the task to be executed is determined based on the number of instructions; wherein the parallel threshold is positively correlated with the number of instructions.

5. A task scheduling method, characterized in that, The method, applied to a computing container containing multiple threads in a scheduling platform, includes: For each thread, when it is determined that the thread is in an idle state, the thread is determined to be an idle thread, and a task acquisition request is generated based on the idle thread; The task acquisition request is reported to the coordinator, and the allocation instruction fed back by the coordinator is received; wherein, the allocation instruction includes a target task instruction, which is determined by the coordinator from the instruction queue in response to the task acquisition request, and the instruction queue includes task flows of each task to be executed received by the coordinator, and the task flow includes at least one of the task instructions. The idle thread is invoked to execute the target task instruction.

6. The method according to claim 5, characterized in that, The step of invoking the idle thread to execute the target task instruction includes: The idle thread is invoked to perform a self-check on the target task instruction; If the self-test result is successful, an execution request containing the target task instructions is generated and the execution request is reported to the coordinator. The system receives execution feedback instructions from the coordinator and executes the target task instruction according to the execution feedback instructions; wherein the execution feedback instructions are generated by the coordinator based on the comparison results of the number of parallel tasks corresponding to the parent task and the parallel threshold, and the execution feedback instructions indicate whether execution is allowed or not. The parent task is the task to be executed to which the target task instruction belongs; the parallel quantity is the number of task instructions in the parent task that are in the execution state; and the parallel threshold represents the maximum number of threads allowed to be occupied by the task to be executed.

7. The method according to claim 6, characterized in that, The task instruction includes task data and a task function; the step of calling the idle thread to perform a self-check on the target task instruction includes: Invoke the idle thread to load the task data and / or the task function, and determine the loading result; If the loading result indicates successful loading, a latency test script is executed to determine the latency between the computing container and the coordinator. If the delay is determined to be less than the error threshold, the self-test result is determined to be a successful self-test.

8. A task scheduling device, characterized in that, The device includes a request-response module and an instruction generation module, wherein: The request response module is used to determine the target task instruction from the instruction queue in response to a task acquisition request reported by the computing container; wherein, the instruction queue contains task flows of each received task to be executed, and the task flow includes at least one task instruction; the computing container includes multiple threads, and the task acquisition request is generated by the computing container in response to the determination of an idle thread, wherein the idle thread is a thread in an idle state; The instruction generation module is used to generate an allocation instruction containing the target task instruction and to feed the allocation instruction back to the computing container; the allocation instruction is used to instruct the computing container to call the idle thread to execute the target task instruction.

9. A task scheduling device, characterized in that, The device includes a request module, an interaction module, and an execution module, wherein: The request module is used to determine that a thread is an idle thread when it is determined that the thread is in an idle state, and to generate a task acquisition request based on the idle thread. The interaction module is used to report the task acquisition request to the coordinator and receive the allocation instruction fed back by the coordinator; wherein, the allocation instruction includes a target task instruction, which is determined by the coordinator from the instruction queue in response to the task acquisition request, and the instruction queue includes the task flow of each task to be executed received by the coordinator, and the task flow includes at least one of the task instructions. The execution module is used to call the idle thread to execute the target task instruction.

10. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the task scheduling method according to any one of claims 1 to 4, and / or the steps of the task scheduling method according to any one of claims 5 to 7.

Images